`
`
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`APPLE INC.,
`Petitioner
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Mail Stop “PATENT BOARD”
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`
`
`
`
`
`
`Case IPR2019-00820
`Patent No. 7,937,581
`
`
`
`
`
`DECLARATION OF DAVID GOLDSCHLAG, PH.D., IN SUPPORT OF
`PETITIONER’S REPLY TO THE PATENT OWNER RESPONSE
`
`
`
`
`
`Apple EX1022
`Apple v. MPH
`IPR2019-00820
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`
`TABLE OF CONTENTS
`Introduction ...................................................................................................... 1
`
`Claim Construction .......................................................................................... 2
`
`I.
`
`II.
`
`III. The Combination of Ishiyama and Murakawa Discloses the Claimed
`“Security Gateway.” ........................................................................................ 6
`
`A.
`
`B.
`
`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. ...................... 7
`
`Ishiyama’s use of tunnel mode suggests that its correspondent host
`can be a security gateway. ........................................................................ 12
`
`C. A POSITA Would Have Sought Out References Such as
`Murakawa for its Teaching of a Tunnel Mode Implementation. ............. 15
`
`IV. Nothing in the Prior Art Precludes Ishiyama’s “Correspondent Host”
`from Operating as a “Security Gateway.” ..................................................... 19
`
`V.
`
`VI.
`
`The Combination of Ishiyama and Murakawa Teaches the “Other
`Terminal.” ...................................................................................................... 24
`
`Ishiyama Teaches the Mobile Terminal Transmitting a Message While
`at a Second Address to Change the Definition of a Security
`Association. ................................................................................................... 30
`
`VII. The Combination of Ishiyama and Murakawa Teaches the
`“Request”/“Reply” Messages Being Encrypted. ........................................... 33
`
`VIII. The Combination of Ishiyama, Murakawa, and Ahonen Renders
`Claims 3 and 5 Obvious. ................................................................................ 34
`
`IX. Dependent Claim 7 is Unpatentable. ............................................................. 40
`
`X.
`
`
`
`
`Conclusion ..................................................................................................... 42
`
`- i -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`
`I, David Goldschlag, Ph.D., hereby declare as follows:
`I.
`
`Introduction
`
`1.
`
`
`I am the same David Goldschlag, Ph.D. who submitted a prior
`
`declaration (EX1002) in this matter, which I understand was filed on March 27,
`
`2019. I have been retained on behalf of Apple Inc. (“Petitioner”) for the above-
`
`captioned inter partes review proceeding.
`
`
`
` My background and qualifications were provided in paragraphs 6-12 2.
`
`of my prior declaration, and my CV was provided as EX1016. My statements in
`
`paragraphs 2-5 of my prior declaration regarding my review of U.S. Patent No.
`
`7,937,581 (“the ’581 patent”) and related materials remain unchanged, as do my
`
`understandings of the relevant legal principles stated in paragraphs 13-21.
`
`3.
`
`
`Since my prior declaration, I have reviewed and considered the
`
`following additional materials:
`
`Paper
`
`Description
`
`10
`
`Decision Granting Institution, IPR2019-00820 (“DI”)
`
`23
`
`Exhibit
`
`1021
`
`2009
`
`
`
`Replacement Patent Owner’s Response
`
`Description
`Deposition Transcript of George N. Rouskas, Ph.D., dated
`March 20, 2020.
`
`Declaration of Professor George N. Rouskas, Ph.D.
`
`- 1 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`I have also considered all other materials cited herein. My work on
`
`4.
`
`
`this case is being billed at my normal hourly rate, with reimbursement for actual
`
`expenses. My compensation is not contingent upon the outcome of this inter partes
`
`review proceeding.
`
`II. Claim Construction
`5.
`Dr. Rouskas contends that the term “security gateway” should be
`
`
`construed as a “gateway that provides additional security functionality, such as
`
`firewall functionality.” EX2009, Rouskas Decl., ¶64. Dr. Rouskas further contends
`
`that a “gateway” is “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.” Id. I disagree that the term “security
`
`gateway” needs additional construction, and I further disagree with the definition
`
`provided by Dr. Rouskas.
`
`6.
`
`
`Dr. Rouskas appears to propose this construction in an attempt to
`
`distinguish a “security gateway” from a “host.” But as admitted by Dr. Rouskas
`
`and well-known in the art, “[p]ersons of ordinary skill in the art [POSITA]
`
`recognize that devices can perform multiple functions.” Id., ¶69. Dr. Rouskas
`
`further acknowledges that “the same device that otherwise performs a security
`
`gateway function may in some cases be the end destination for traffic…” Id., ¶70.
`
`- 2 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`This understanding is consistent with my own and indicates the artificial
`
`distinction between the words “security gateway” and “host.”
`
`7.
`
`
`I agree with Dr. Rouskas, as he admitted during his deposition, that
`
`the ’810 patent (and therefore the ’581 patent) uses the term “security gateway” in
`
`its common form as well-understood in the art and as described in RFC 2401—the
`
`IPSec specification. EX1021, Rouskas Depo., 165:17-166:5; 168:9-20. There is
`
`thus no dispute that the ’581 patent uses the term “security gateway” in its well-
`
`known and conventional manner. Accordingly, in view of the ’581 patent, a
`
`POSITA would not have needed to construe the term “security gateway” because
`
`the ’581 patent does not use the term in any atypical or special manner.
`
`8.
`
`
`The ’581 patent itself also supports this interpretation. For example,
`
`Dr. Rouskas quotes the following passage from the ’581 patent, which I have
`
`further extended and emphasized below:
`
`Typically, transport mode is used for end-to-end communication
`between two hosts…[T]unnel mode may also be used for end-to-end
`communication between two hosts. 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
`
`- 3 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`network. The SGW or the like filters all outgoing packets to determine
`the need for IPSec processing. If this packet from the first host to
`another host requires IPSec, the firewall performs IPSec processing
`and encapsulates the packet in an outer IP header….This packet is
`now routed to the other hosts firewall with intermediate routers
`examining only the outer IP header. At the other host firewall, the
`outer IP header is stripped off and the inner packet is delivered to the
`other host.
`
`EX1001, ’581 patent, 3:14-62.
`
`9.
`
`
`A POSITA viewing this description, however, would have understood
`
`that this passage refers to a conventional and well-known security gateway. This
`
`passage does not suggest any special definition or requirements. This passage does
`
`not define or limit the term “security gateway.” In particular, this passage does not
`
`require that the security gateway be an “intermediate system” or that it have “two
`
`or more communication interfaces” or that it “interconnects different networks and
`
`can forward packets.”
`
`
`
` Rather, this passage describes the operation of IPSec in tunnel mode. 10.
`
`A POSITA would have viewed this language as permissive and simply explains
`
`that security gateways “implement IPSec” in a conventional manner. The security
`
`gateway described in the ’581 patent is not required to have firewall functionality
`
`because this passage states that the security can also be a “router.” See id.
`
`- 4 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`
`
` The other portions of the ’581 patent also do not limit the term in this 11.
`
`manner. For example, columns 8 and 9 as well as Figure 1 and Figure 2 of the ’581
`
`patent do not support such a restrictive construction. The words “interface” or
`
`“intermediate system,” in particular, do not appear in these portions. As the ’581
`
`patent explains, Figures 1 and 2 are simply “example[s]” and therefore do not add
`
`explicit requirements to the term “security gateway.” See id., 8:37-40. The ’581
`
`patent also uses permissive language such as “[c]omputer 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:55-60. In
`
`this manner, the security gateway in the ’581 patent is described permissively.
`
`
`
` For example, a POSITA would have understood that computer 2 12.
`
`might be a security gateway or might not. A POSITA would have also understood
`
`that several computers might have been connected to “computer 2” or not. The
`
`’581 patent does not explicitly require a specific configuration in view of this
`
`language. In this manner, the ’581 patent again here does not describe any
`
`requirements or a special definition for “security gateway,” The ’581 patent instead
`
`describes an example that the “security gateway can be a common security
`
`gateway for e.g. a company LAN.” See id., 8:51-60.
`
`
`
` The extrinsic references and prior art documents cited by Dr. Rouskas 13.
`
`also do not support the construction. See EX2009, ¶¶71-90. Rather than supporting
`
`- 5 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`a definition for “security gateway,” Dr. Rouskas cites to these references
`
`attempting to distinguish a “security gateway” from a “host.” This distinction,
`
`however, does not limit the term “security gateway” or change the admission from
`
`Dr. Rouskas that, like the ’810 patent, the ’581 patent uses the term “security
`
`gateway” in a conventional manner—such as under RFC 2401. EX1021, 165:17-
`
`166:5; 168:9-20. For example, RFC 2401 simply states that “[t]he term ‘security
`
`gateway’ is used throughout the IPsec documents to refer to an intermediate
`
`system that implements IPsec protocols. For example, a router or a firewall
`
`implementing IPsec is a security gateway.” EX1011, RFC 2401, 6. The ’581 patent
`
`does not provide any special definition that differs from the well-known security
`
`gateway recited in RFC 2401, and therefore, a construction is not needed.
`
`III. The Combination of Ishiyama and Murakawa Discloses the Claimed
`“Security Gateway.”
`
`14.
`
`
`I understand that Dr. Rouskas contends that the combination of
`
`Ishiyama and Murakawa does not teach the claimed “security gateway” because
`
`Ishiyama uses the term “correspondent host” and this device cannot be the claimed
`
`“security gateway.” See EX2009, ¶¶110-38. I disagree.
`
`
`
` The combination of Ishiyama and Murakawa teaches the claimed 15.
`
`security gateway for multiple reasons. First, Ishiyama’s use of the IPSec protocol
`
`would have made it obvious to a POSITA to use a “security gateway” in view of
`
`Ishiyama’s disclosure of a “correspondent host.” Second, Ishiyama’s disclosure of
`
`- 6 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`IPSec tunnel mode would have even further made it obvious to a POSITA to
`
`modify Ishiyama’s “correspondent host” to be a “security gateway” because tunnel
`
`mode is most often used with security gateways. Third, if a POSITA did not
`
`already know how to implement IPSec tunnel mode, he would have sought out
`
`references such as Murakawa, which teach implementing tunnel mode in a
`
`“security gateway.”
`
`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.
`
`
`
` A POSITA would have understood that IPSec connections only have 16.
`
`three combinations of network devices and only two types of endpoints: a host or a
`
`security gateway. See EX1008, Frankel, FIGs. 1.1(a)-1.1(c); EX1011, 6.
`
`Specifically, RFC 2401 explains that “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.” EX1011, 6. As explained in my previous declaration,
`
`Frankel depicts these three common scenarios and further illustrates the endpoints
`
`being “host-to-host,” “gateway-to-gateway,” and “host-to-gateway.” EX1002,
`
`Goldschlag Decl., ¶34; EX1008, 3-4.
`
`- 7 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`
`EX1008, FIGs. 1.1(a)-(c).
`
`
`
`
`
` As seen in Figure 1.1(a), “two hosts [are] communicating with each 17.
`
`other.” EX1008, 3. Figure 1.1(b) depicts a “small-scale VPN: two separate
`
`networks, each protected from the outside by a security gateway that screens all
`
`communications to and from its associated network.” Id. Most relevant to the ’581
`
`patent is Figure 1.1(c). In this figure, “a single host [is] communicating with
`
`another host that resides on a network protected by a security gateway. This
`
`- 8 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`commonly occurs when an employee dials into a business network from home or
`
`when on a business trip.” Id.
`
`
`
` As seen from this description as well as from the IPSec specification 18.
`
`(RFC 2401), there are only two choices of endpoints for an IPSec connection: a
`
`host or a security gateway. I understand that Dr. Rouskas does not dispute this
`
`understanding. See EX2009, ¶¶128-31.
`
`
`
` Turning to Ishiyama, in my opinion, a POSITA would have found it 19.
`
`obvious to apply Ishiyama’s teachings to situations where its “correspondent host”
`
`would indeed be a “security gateway.” As previously explained, RFC 2401 and
`
`Frankel all indicate that there are only two choices of endpoints for IPSec
`
`connections: a host or a security gateway. In this respect, using either endpoint
`
`would only depend on the context in which a POSITA was working and would
`
`have been a well-known design choice.
`
`
`
` For example, a common context for using IPSec is a Virtual Private 20.
`
`Network (VPN). RFC 2401 describes this well-known example and provides
`
`context for using IPSec. In particular, RFC 2401 explains that “a company could
`
`create a Virtual Private Network (VPN) using IPsec in security gateways at several
`
`sites… [T]he security gateway might selectively protect traffic to and from other
`
`sites within the organization… A similar argument might apply to use of IPsec
`
`entirely within an organization for a small number of hosts and/or gateways.”
`
`- 9 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`EX1011, 27. In this manner, a POSITA would have known that implementing
`
`IPSec in hosts and gateways would have been merely a design choice depending
`
`on the context.
`
`21.
`
`
`Indeed, both RFC 2401 and the ’581 patent explain that a common
`
`use case for IPSec is in the context of Virtual Private Networks (VPNs). See id.;
`
`EX1001, 1:62-66. In the context of VPNs, a POSITA would have implemented
`
`IPSec functionality in security gateways as explained in RFC 2401. See EX1011,
`
`27. Specifically, a POSITA would have implemented IPSec functionality in a
`
`security gateway to provide protection to a company network.
`
`22.
`
`
`In this context, a POSITA viewing Ishiyama and seeking to
`
`implement Ishiyama’s teachings in the VPN context would have already known
`
`that a security gateway would have been needed. I understand that Dr. Rouskas
`
`explained that at the time of the ’581 patent, using IPSec with VPNs was
`
`ubiquitous. EX1021, 33:13-15. I agree with this assessment. Even when forming
`
`the IPSec standard as explained in RFC 2401, the VPN context was a common use
`
`case. See EX1011, 27. I also understand that Dr. Rouskas explained that “typically,
`
`yes, one end of the VPN is a security gateway.” EX1021, 101:1-4. I agree with this
`
`assessment as well, but would further note that using a VPN almost always uses a
`
`security gateway.
`
`- 10 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`
`
` Again, referring to RFC 2401, the IPSec standard illustrates a 23.
`
`connection between two “simple virtual private networks.” EX1011, 25.
`
`EX1011, 25.
`
`
`
`
`
` Here, “SG1” is a security gateway that provides VPN functionality for 24.
`
`the left-most “Local Intranet” while “SG2” is a security gateway that provides
`
`VPN functionality for the right-most “Local Intranet.” As seen from RFC 2401,
`
`using a VPN to protect a local intranet nearly always uses a security gateway.
`
`
`
` Accordingly, if a POSITA were implementing Ishiyama in the well-25.
`
`known IPSec VPN context, the POSITA would have understood to use a security
`
`gateway. The fact that there are only two types of endpoints in the IPSec and VPN
`
`contexts further illustrates that a POSITA would have found it obvious to
`
`implement Ishiyama’s secure connection to be between a host and a security
`
`gateway. As Frankel explains, a VPN and IPsec connection “commonly occurs
`
`when an employee dials into a business network from home or when on a business
`
`trip.” EX1008, 3. A POSITA implementing Ishiyama in this well-known context
`
`- 11 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`would have thus known and found it obvious to implement Ishiyama’s teachings in
`
`a security gateway.
`
`B.
`
`Ishiyama’s use of tunnel mode suggests that its correspondent
`host can be a security gateway.
`
`26.
`
`
`Ishiyama’s use of tunnel mode would have further suggested the use
`
`of a security gateway. As explained in my previous declaration even the ’581
`
`patent recognized that, “[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.”
`
`EX1001, 3:22-24 (emphasis added); see also id., 2:8-12, 5:54-57, citing RFC2401:
`
`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.
`EX1011, 9; EX1002, ¶33.
`
`
`
` Dr. Rouskas also concedes that using tunnel mode with a security 27.
`
`gateway is the most common use case and is most often used when one or both
`
`endpoints of an IPSec connection is a security gateway. EX1021, 109:22-110:10;
`
`113:7-9. I also understand that during his entire career, Dr. Rouskas has never used
`
`tunnel mode between two hosts:
`
`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?
`
`- 12 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`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.
`
`Q: And you have never used IPSec tunnel mode between two hosts, at
`least personally?
`
`A: Personally, I have not used tunnel mode.
`
`EX1021, 111:21-112:9.
`
`
`
` As stated in my previous declaration, I agree that using tunnel mode 28.
`
`with one endpoint being a security gateway is the most often use case. See
`
`EX1002, ¶¶33-36. The ’581 patent confirms this understanding in stating that
`
`“[t]unnel mode is often used when one or both ends of a SA is a security gateway.”
`
`EX1001, 3:22-24. RFC 2401 also states that “[w]henever either end of a security
`
`association is a security gateway, the SA MUST be tunnel mode.” EX1011, 9. In
`
`this manner, while tunnel mode may be used between hosts, a POSITA would have
`
`known that the most common scenario, and often times required scenario, is that
`
`tunnel mode is used with a security gateway.
`
`
`
` Turning to Ishiyama, Ishiyama describes the use of tunnel mode as a 29.
`
`connection between its two devices. I understand that Dr. Rouskas argues that
`
`Ishiyama’s disclosure is related to a host-to-host scenario. EX2009, ¶¶132-33. I
`
`disagree. Ishiyama is not limited to only that scenario. As explained above and in
`
`- 13 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`my previous declaration, Ishiyama’s disclosure of tunnel mode would have
`
`suggested and made it obvious to a POSITA that Ishiyama’s correspondent host
`
`would be a “security gateway” because it is the most common scenario for using
`
`tunnel mode. See EX1002, ¶¶33-36, 61.
`
`30.
`
`
`I understand that Dr. Rouskas argues that Ishiyama’s use of tunnel
`
`mode is limited to host-to-host communications because “Ishiyama seeks to
`
`transmit packets from [an] original home address of the mobile terminal without
`
`revealing that address (Haddr) until the packet reaches its final destination . . .”
`
`EX2009, ¶133. I disagree. While Ishiyama describes the encapsulation of packets,
`
`Ishiyama does not describe a design objective being expressly limited to hiding a
`
`home address. Rather, the portions of Ishiyama cited by Dr. Rouskas reveal that
`
`Ishiyama contemplates the usage of a security gateway with respect to tunnel
`
`mode.
`
`
`
` For example, Ishiyama states: “the IP address (CoA) assigned to the 31.
`
`communication interface 21 will be used as an address (gateway address)
`
`indicating one endpoint (termination endpoint) of the tunnel.” EX1004, Ishiyama,
`
`8:2-4; see also id., 8:43-49, 11:39-47, 12:50-59, 14:11-16. Ishiyama also explains
`
`that as the mobile computer carries out communications using a Care-of address as
`
`a “gateway address,” the mobile computer “transmits an encapsulated packet in
`
`which the outer packet has the source address=‘CoA1’” or “CoA2” if the mobile
`
`- 14 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`computer has moved to a new address. Id., 8:42-65. This description explains that
`
`the outer packet uses an IP address in its IPSec tunnel as a “gateway address.” In
`
`view of this description, a POSITA would have readily understood that Ishiyama
`
`describes an endpoint of its IPSec tunnel as being a gateway or security gateway.
`
`
`
` To further illustrate this understanding, Ishiyama’s mobile computer 32.
`
`also performs an “SA Gateway Update” which includes sending a “[r]equest for
`
`changing the security association to the correspondent [host].” Id., 11:39-40. The
`
`“communication path to the correspondent [node] is secured by utilizing the tunnel
`
`mode of the IPSEC which is the standard protocol. Then, the maintenance of the
`
`session at a time-of moving is guaranteed by enabling the change of the
`
`termination endpoint of the tunnel by [applying] the SA Gateway Update
`
`[operation].” Id., 14:11-16. A POSITA would have understood this operation
`
`demonstrates that the IPsec tunnel is updated at a gateway when the mobile
`
`computer changes addresses and further illustrates that Ishiyama’s host is a
`
`gateway. See EX1002, ¶45.
`
`C. A POSITA Would Have Sought Out References Such as
`Murakawa for its Teaching of a Tunnel Mode Implementation.
`
`
`
` Dr. Rouskas appears to mischaracterize the obviousness combination 33.
`
`of Ishiyama and Murakawa and instead seems to argue that Ishiyama solely does
`
`not teach a security gateway. EX2009, ¶¶113-38. As explained in my previous
`
`declaration and acknowledged by the Board in its Institution Decision, however,
`
`- 15 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`the combination of Ishiyama and Murakawa is the proposed ground of
`
`unpatentability based on obviousness—not Ishiyama alone. See EX1002, ¶¶56-61,
`
`64-69, 83-90; see also DI, 34-35.
`
`
`
` Specifically, I explained that a “POSITA reading Ishiyama would 34.
`
`have understood that Ishiyama renders obvious the claims of the ’581 patent…
`
`Ishiyama’s description of operating the correspondent host in IPSec tunnel mode
`
`implies the security gateway functionality of the correspondent host.” Goldschlag
`
`Dec., ¶56. “If a POSITA reading Ishiyama had not immediately understood the
`
`implications of Ishiyama’s IPSec tunnel mode and the tunneling of messages from
`
`a mobile terminal to an ‘other terminal,’ a POSITA would likely have sought out
`
`other references that describe how to implement tunnel mode. Murakawa provides
`
`this description and further mirrors the understanding of a POSITA.” Id., ¶58.
`
`35.
`
`
`In particular, Murakawa provides details for implementing tunnel
`
`mode in a virtual private network (VPN). 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.” EX1005, 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.” Id., 1:50-51; see also EX1002, ¶¶59-60.
`
`- 16 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`
`EX1005, FIG. 5 (annotated).
`
`
`
`36.
`
`
`“[S]ecurity gateway 103 includes server terminal 105 and client PCs
`
`106, 107.” EX1005, 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-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.”
`
`- 17 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`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.
`
`
`
` As I explained in my previous declaration, a POSITA would have 37.
`
`been motivated to combine Ishiyama and Murakawa to maintain communications
`
`while a mobile host roams to different networks. See EX1002, ¶68. I explained that
`
`“a POSITA would have understood that implementing Ishiyama’s correspondent
`
`host functionality with the security gateway described in Murakawa would be
`
`highly desirable in the telecommunication context. As Ishiyama explains,
`
`implementing its IPsec address updating algorithm allows a mobile terminal and a
`
`security gateway to maintain communication ‘without interrupting the session’
`
`initially established even when the mobile terminal changes to another address.”
`
`Id., ¶¶67-68 (citing Ishiyama, 6:54-60). Specifically, Ishiyama states that its
`
`address-changing techniques would “guarantee [] mobility without interrupting the
`
`session by notifying the changed IPSEC tunnel terminal endpoint… and changing
`
`the tunnel termination address in a security related database.” EX1004, 6:54-60.
`
`38.
`
`
`In this manner, Ishiyama implemented with the teachings of
`
`Murakawa would have provided a way to use the well-known VPN scheme
`
`described in Murakawa to facilitate and maintain communications for mobile
`
`- 18 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`terminals. Murakawa additionally notes that when a mobile terminal attempts to
`
`establish a VPN connection, there is an “inconvenience” and that several “security
`
`problems” arise. EX1005, 3:29-36. Murakawa thus suggests that it would be
`
`desirable to receive improvements for a “VPN communication method in a security
`
`gateway apparatus that connects … between a LAN and a WAN.” Id., 3:66-4:2. A
`
`POSITA would have known how to improve Murakawa’s VPN configuration as
`
`depicted in Figure 5 with the functionality described in Ishiyama to provide
`
`uninterrupted communication session and minimize session interruptions with
`
`networked systems. See EX1002, ¶¶62-69. As I previously explained, this
`
`combination would have been predictable to create a secure connection between a
`
`mobile terminal and a security gateway. See id.
`
`IV. Nothing in the Prior Art Precludes Ishiyama’s “Correspondent Host”
`from Operating as a “Security Gateway.”
`
`39.
`
`
`I understand that Dr. Rouskas makes two arguments arguing that
`
`Ishiyama’s “correspondent host” cannot be a security gateway. First, Dr. Rouskas
`
`contends that Ishiyama’s correspondent host has only a single communication
`
`interface and therefore cannot be a security gateway. EX2009, ¶¶117-19. Second,
`
`Dr. Rouskas contends that Ishiyama’s description of Security Databases and a
`
`“correspondent node” (CN) address teaches the Ishiyama’s correspondent host is
`
`not a security gateway. Id., ¶¶120-23. I disagree with each of these arguments
`
`because (1) Ishiyama refers to its correspondent host as a “gateway;” and (2) the
`
`- 19 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`combination of Ishiyama and Murakawa addresses the explicit scenario where a
`
`security gateway forwards packets to other terminals.
`
`
`
` First, as explained above, Ishiyama refers to its correspondent host as 40.
`
`a “gateway” in several instances. See EX1004, 8:1-6, 8:43-49, 11:39-47, 12:50-59,
`
`14:11-16; see Section III.B. In view of these several descriptions, Ishiyama
`
`describes updating its correspondent host as updating the “SA Gateway” and
`
`further demonstrates that the correspondent host is a security gateway. I understand
`
`that Dr. Rouskas characterizes Ishiyama’s correspondent host as having only a
`
`single interface and therefore it is not a security gateway. EX2009, ¶¶117-19. I
`
`disagree for several reasons. I first disagree with the construction provided by Dr.
`
`Rouskas as I have explained above. See Section II. The ’581 patent does not
`
`provide any special definition for “security gateway” and therefore does not
`
`require multiple interfaces. Rather, as conceded by Dr. Rouskas, the term “security
`
`gateway” in the ’581 patent is used in its conventional and well-known manner.
`
`See Section II; see also EX1021, 165:17-166:5; 168:9-20.
`
`
`
` Second, Dr. Rouskas’s construction does not address the combination 41.
`
`of Ishiyama and Murakawa that I described in my previous declaration. See
`
`EX1002, ¶¶62-69. As previously explained, Ishiyama in view of Murakawa would
`
`have taught that Ishiyama’s correspondent host would have likely operated as a
`
`security gateway because security gateways are commonly used with IPsec. See
`
`- 20 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`Section III.A. Further, the use of tunnel mode would have suggested that an
`
`endpoint of the IPsec tunnel would have likely been a security gateway. See
`
`Section III.B. The IPSec standard as recited in RFC 2401, the ’581 patent, as well
`
`as Dr. Rouskas all acknowledge that tunnel mode is most often used when one of
`
`the endpoints is a security gateway. See id. Thus, the “security gateway” suggested
`
`in Ishiyama would have the same functionality and features proposed by Dr.
`
`Rouskas because both are based on the common usage of the term “security
`
`gateway” as recited in the IPSec standard.
`
`
`
` With respect to Ishiyama’s “security databases,” Dr. Rouskas argues 42.
`
`that this description indicates that the correspondent host is not a security gateway.
`
`EX2009, ¶¶120-23. Dr. Rouskas points to Ishiyama’s description of a destination
`
`address potentially being “CN” in arguing that this description precludes Ishiyama
`
`from operating as a security gateway. Id. Specifically, Dr. Rouskas states that “[i]f
`
`either of MN or CN in Figures 8A-9D was a security gateway, the selectors would
`
`use multiple addresses (e.g., a range, a wildcard, a subnet mask or the like
`
`representing multiple addresses for either CN or MN) for at least one of the IPSec
`
`endpoints.” Id., ¶123. I disagree because Dr. Rouskas incorrectly focuses on
`
`narrow embodiments of Ishiyama. Nothing in Ishiyama limits its configuration
`
`from being applicable to a security gateway. Further, a POSITA would have
`
`- 21 -
`
`

`

`Case IPR2019-00820
`U.S. Patent No. 7,937,581
`understood that Ishiyama’s description suggests the use of a security gateway as I
`
`have previously explained