`Patent 7,620,810
`
`
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner.
`____________
`
`Case IPR2019-00819
`Patent 7,620,810
`____________
`
`REPLACEMENT PATENT OWNER’S RESPONSE
`PURSUANT TO 37 C.F.R. § 42.120
`
`
`
`TABLE OF CONTENTS
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`Page
`
`I.
`
`II.
`
`INTRODUCTION ........................................................................................ 1
`
`OVERVIEW OF THE ’810 PATENT AND THE STATE OF THE
`ART ................................................................................................................ 4
`
`A. Technical Background ........................................................................ 4
`
`B. The Mobility Problem Addressed by the ’810 Patent ...................... 6
`
`C. The ’810 Patent’s Solution to the Mobility Problem ....................... 7
`
`III. CLAIM CONSTRUCTION ...................................................................... 10
`
`A. Claim Language ................................................................................. 12
`
`B.
`
`Specification ....................................................................................... 12
`
`C. Prosecution History ........................................................................... 15
`
`D. Disclosure of Security Gateway in Documents from the
`Prosecution History or Relied Upon by Petitioner ........................ 16
`
`1. Murakawa ................................................................................ 17
`
`2.
`
`3.
`
`4.
`
`5.
`
`Ahonen ..................................................................................... 18
`
`Frankel ..................................................................................... 19
`
`RFC 1122 ................................................................................. 22
`
`RFC 2401 ................................................................................. 23
`
`IV. GROUND 1: CLAIMS 1, 4-5 AND 7 ARE PATENTABLE OVER THE
`COMBINATION OF ISHIYAMA AND MURAKAWA ....................... 24
`
`A. Claim 1 is Patentable Over the Combination of Ishiyama and
`Murakawa ........................................................................................... 27
`
`i
`
`
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`1. The Petition Fails to Establish that the Prior Art Teaches
`the “Security Gateway” in “At Least One Mobile
`Terminal and Another Terminal and a Security Gateway
`Therebetween” and Other Limitations ................................... 27
`
`(a) Multiple Publications from the Relevant
`Timeframe Confirm that a Correspondent Host as
`in Ishiyama is Not a Security Gateway as Claimed .... 31
`
`(b)
`
`(c)
`
`Ishiyama’s Correspondent Host is Demonstrably
`Not a Security Gateway Because it is the Final
`Destination for the Packets It Receives ........................ 33
`
`Ishiyama’s Description of IPSec Processing Using
`the Security Databases Proves that the
`Correspondent Host is Not a Security Gateway ......... 34
`
`(d) Petitioner’s Theory, that the Correspondent Host
`Must be a Security Gateway Because IPSec Tunnel
`Mode is Used, is Incorrect ............................................. 36
`
`1.
`
`2.
`
`The Use of Tunnel Mode Does Not Mean that
`a Security Gateway is Present .............................. 37
`
`The Use of Tunnel Mode Does not “Suggest”
`that a Correspondent Host is Actually a
`Security Gateway .................................................. 41
`
`(e)
`
`Petitioner’s Argument in this Proceeding that the
`Correspondent Host is a Security Gateway is
`Contradicted by the Position Taken in IPR2019-
`00821 ................................................................................ 43
`
`2. The Petition Also Fails to Establish that the Prior Art
`Discloses the “Other Terminal” in “At Least One Mobile
`Terminal and Another Terminal and a Security Gateway
`Therebetween” and Other Limitations ................................... 45
`
`3. The Petition Also Fails to Establish that the Prior Art
`Teaches “While at the Second Address, the Mobile
`
`ii
`
`
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`Terminal Sending a Request Message to the Address of
`the Security Gateway to Change the Secure Connection to
`Be Defined Between the Second Address and the Address
`of the Security Gateway” .......................................................... 54
`
`4. The Petition Also Fails to Establish that the Prior Art
`Teaches the “Mobile Terminal Sending a Secure
`Message . . . From the Second Address of the Mobile
`Terminal to the Other Terminal via the Security
`Gateway” .................................................................................... 56
`
`5. The Petition Also Fails to Establish that the Prior Art
`Teaches the “Request Message and/or a Reply Message
`Being Encrypted and/or Authenticated by Using the
`Same SA Already Established” ................................................ 61
`
`B. Claims 4-5 Are Patentable over the Combination of Ishiyama
`and Murakawa ................................................................................... 63
`
`C. Claim 7 is Patentable Over the Combination of Ishiyama and
`Murakawa .......................................................................................... 64
`
`V.
`
`GROUND 2: CLAIMS 2-3 ARE PATENTABLE OVER THE
`COMBINATION OF ISHIYAMA, MURAKAWA AND AHONEN .... 69
`
`A. Overview of Ahonen .......................................................................... 69
`
`B. The Combination of Ishiyama, Murakawa and Ahonen Fails
`to Teach Sending a “Reply Back to the Mobile Terminal . . .
`From the Security Gateway” (Claim 2) or a “Reply Message
`to the Mobile Terminal at the Second Address to Confirm the
`Address Change” (Claim 3) .............................................................. 70
`
`VI. GROUND 3: CLAIM 6 IS PATENTABLE OVER THE
`COMBINATION OF ISHIYAMA, MURAKAWA AND FORSLOW . 73
`
`VII. CONCLUSION ........................................................................................... 73
`
`
`
`iii
`
`
`
`TABLE OF AUTHORITIES
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`Page(s)
`
`CASES
`
`Continental Can Co. v. Monsanto Co.,
`948 F.2d 1264 (Fed. Cir. 1991) .......................................................................... 37
`
`David Netzer Consulting Eng’r LLC v. Shell Oil Co.,
`824 F.3d 989 (Fed. Cir. 2016) ............................................................................ 11
`
`Graham v. John Deere Co.,
`383 U.S. 1 (1966) ................................................................................................ 24
`
`In re Robertson,
`169 F.3d 743 (Fed. Cir. 1999) ..................................................................... 37, 43
`
`InTouch Techs., Inc. v. VGO Commc’ns, Inc.,
`751 F.3d 1327 (Fed. Cir. 2014) .......................................................................... 53
`
`KSR Int’l Co. v. Teleflex Inc.,
`127 S.Ct. 1727 (2007) ......................................................................................... 25
`
`Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co.,
`851 F.3d 1270 (Fed. Cir. 2017) ................................................................... 43, 46
`
`Personal Web Techs., LLC v. Apple, Inc.,
`848 F.3d 987 (Fed. Cir. 2017) ............................................................... 52, 53, 54
`
`Pfizer, Inc. v. Apotex, Inc.,
`480 F.3d 1348 (Fed. Cir. 2007) .......................................................................... 25
`
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) .......................................................................... 11
`
`Regents of Univ. of California v. Broad Institute, Inc.,
`903 F.3d 1286 (Fed. Cir. 2018) .......................................................................... 25
`
`iv
`
`
`
`Rosco, Inc. v. Mirror Lite Co.,
`304 F.3d 1373 (Fed. Cir. 2002) .......................................................................... 37
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`TQ Delta, LLC v. CISCO Systems, Inc.,
`942 F.3d 1352 (Fed. Cir. 2019) ................................................................... 52, 53
`
`Wright Medical Tech., Inc. v. Osteonics Corp.,
`122 F.3d 1440 (Fed. Cir. 1997) .......................................................................... 11
`
`
`
`STATUTES
`
`35 U.S.C. § 103 ........................................................................................................ 24
`
`
`
`REGULATIONS
`
`37 C.F.R. § 42.100(b) .............................................................................................. 10
`
`v
`
`
`
`
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`EXHIBIT LIST
`
`2001 Network Working Group Request for Comments: 2002 (C. Perkins, ed.)
`(Oct. 1996) (“RFC 2002”).
`
`2002 Declaration of Richard B. Megley, Jr. (“Megley Decl.”).
`
`2003 Declaration of George N. Rouskas
`
`2004 CV of George N. Rouskas
`
`2005 Network Working Group Request for Comments: 1122 (R. Braden, ed.)
`(Oct. 1989), “Requirements for Internet Hosts -- Communication Layers”
`(RFC 1122)
`
`2006 Declaration of Stephen T. Schreiner (“Schreiner dec.”)
`
`2007 Ex. 1003 (Declaration of Dr. Goldschlag) from Apple v. MPH Techs. Oy
`IPR2019-00821
`
`2008 Deposition Transcript of Dr. Goldschlag (12-17-2019)
`
`vi
`
`
`
`I.
`
` INTRODUCTION
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`At the time of the invention communication over the Internet and other
`
`networks was well established. For example, a first user of a desktop computer
`
`could communicate messages made up of packets to a second user at his/her
`
`desktop computer. The security of communications between computers (and other
`
`devices such as mobile phones) was a significant issue in that timeframe. For
`
`example, users wanted to prevent third parties from accessing or altering the
`
`content of their communications.
`
`One approach to providing security was to deliver packets using a secure
`
`connection using the “Internet Protocol Security” (IPSec) protocols. IPSec allows
`
`user devices to securely communicate packets over networks in a manner that
`
`prevented third parties from accessing the content and tampering with the content,
`
`and that could even protect the anonymity of the users. An IPSec secure
`
`connection could extend through multiple networks and could pass through
`
`intermediary devices connecting networks such as routers or gateways.
`
`An IPSec connection is created using a “Security Association” (SA) that
`
`defines the nature of the secure connection, such as the encryption/decryption keys,
`
`encryption/decryption algorithms, authentication algorithms, and other security
`
`parameters. SAs are also tied to a specific destination network address (IP
`
`address). Therefore, a first terminal seeking to establish an IPSec secure
`
`1
`
`
`
`connection with a second terminal at address X would need an SA specifying
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`address X as the destination.
`
`At the time of the invention, the existence of mobile terminals—terminals
`
`that could change networks and acquire new IP addresses—was well known. This
`
`presented an obstacle to using IPSec secure connections because they were tied to
`
`a specific IP address. If a mobile terminal communicating with a second terminal
`
`over an IPSec connection changed its IP address from X to Y the existing SA could
`
`no longer be used. This could lead to an interruption in the secure communication
`
`because a new SA tied to address Y would have to be created. The challenge of
`
`using IPSec where terminals change IP addresses was sometimes referred to as the
`
`“mobility problem.”
`
`The invention provides a solution that allows a mobile terminal to continue
`
`communicating over an IPSec connection with a second terminal through a
`
`security gateway even as the mobile terminal changes IP addresses. A secure
`
`connection is established between a first network address of the mobile terminal
`
`and the address of the security gateway. After the mobile address changes to a
`
`second network address, it sends a request message for the security gateway to
`
`redefine the secure connection to be between the second network address and the
`
`security gateway. The security gateway makes the requested change which permits
`
`the mobile terminal and second terminal to continue to securely communicate.
`
`2
`
`
`
`The Petition asserts in Ground 1 that independent claim 1 and independent
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`claim 7 are obvious based on Ishiyama (Ex. 1004) combined with Murakawa (Ex.
`
`1005). However, Ishiyama and Murakawa fail to disclose the limitation of a
`
`“security gateway” between a mobile terminal and another terminal that allows the
`
`terminals to communicate using a secure connection. The Petition implausibly
`
`asserts that a correspondent host in Ishiyama is the claimed “security gateway.”
`
`However, the ’810 Patent and multiple prior art references define a security
`
`gateway as being a different system that performs a different function from a
`
`correspondent host. The former is an intermediary system that interconnects
`
`networks and can forward packets it receives on to other systems using multiple
`
`interfaces, while the latter is an end system that sends or receives packets using a
`
`single interface. Ishiyama’s correspondent host does not have the function and
`
`does not perform the operations of a security gateway.
`
`The Petition’s prior art combination not only fails to disclose the security
`
`gateway, but it also fails to disclose the “other terminal” set forth in the claim
`
`limitation that requires an end-to-end communication from a “mobile terminal” to
`
`the “other terminal” through the “security gateway.” The prior art fails to teach or
`
`disclose several other limitations of the independent claims. Furthermore, the
`
`Petition never explains how the prior art of Ishiyama and Murakawa are being
`
`combined and how the combined system would operate. That defect means that the
`
`3
`
`
`
`Petition never provides a plausible motivation to combine because the proposed
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`combination is never identified in the first instance.
`
`For the reasons set forth below, the Petition fails to demonstrate by a
`
`preponderance of the evidence that any of the challenged claims 1-7 are
`
`unpatentable.
`
`II.
`
`OVERVIEW OF THE ’810 PATENT AND THE STATE OF THE ART
`A. Technical Background
`
` At the time of the invention, there was a technique for message protection in
`
`computer networks that was described in an Internet specification document,
`
`“Security Architecture for the Internet Protocol,” that was issued by the Internet
`
`Engineering Task Force (IETF) Network Working Group as RFC 2401. See Ex.
`
`1011 [Security Architecture for the Internet Protocol] (November 1998). This
`
`document refers to a technology for message protection known as “IPsec.” The
`
`’810 Patent provides a detailed explanation of the features of IPSec. Addressing
`
`the need for secure messaging, the ’810 Patent discloses that IPSec secure
`
`connections provide “confidentiality[,] integrity, authentication, . . . limited
`
`identity protection, and access control based on authenticated identities.” Ex. 1001
`
`[’810 Patent] 0008 (1:64-2:1); Ex. 2003 [Rouskas dec.] (¶¶ 37-49).
`
`The ’810 Patent describes fundamental concepts of IPSec secure
`
`connections. For example, Security Associations (SAs) are data structures that are
`
`4
`
`
`
`fundamental to IPSec processing. Ex. 1001 [’810 Patent] 0008 (2:21-32). The ’810
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`Patent explains that an SA defines a one-way security relationship that protects the
`
`message traffic sent from sender to a receiver. If a two-way secure connection
`
`between the sender and receiver is desired, then two SA definitions are required. In
`
`some cases, multiple SAs are used for message traffic between two host devices
`
`(terminals). Ex. 1001 [’810 Patent] 0008 (2:21-40); Ex. 2003 [Rouskas dec.]
`
`(¶¶ 44-45).
`
`The ’810 Patent discloses that an SA is uniquely defined by three
`
`parameters: (1) the Security Parameters Index (SPI), (2) the IP destination address
`
`(Dst), and (3) the IPSec security protocol type (AH/ESP). For each IPSec
`
`connection a Security Association Database (SADB) stores the information for
`
`each SA, including items (1)-(3) above, as well as information defining the
`
`authentication algorithms, encryption algorithms, keys and related parameters that
`
`are used to cryptographically protect the message traffic over the IPSec secure
`
`connection. Ex. 1001 [’810 Patent] 0008 (2:41-67); Ex. 2003 [Rouskas dec.]
`
`(¶ 46).
`
`The ’810 Patent explains that IPSec secure connections support two modes:
`
`transport mode and tunnel mode. Tunnel mode provides more complete protection
`
`by creating an outer packet with a new IP header that protects everything within it,
`
`which is effectively treated as a payload of the outer packet. Notably, the IP header
`
`5
`
`
`
`of the outer packet can have source and destination addresses that are completely
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`different from the source and destination addresses of the encapsulated inner
`
`packet. For example, if the outer packet source is A and its destination is B, the
`
`inner packet travels within a tunnel from A to B without its contents being exposed
`
`along the way by intervening routers that eventually forward the packet to its outer
`
`packet destination of B. Ex. 1001 [’810 Patent] 0009 (3:8-43); Ex. 2003 [Rouskas
`
`dec.] (¶¶ 47-48).
`
`B.
`
`The Mobility Problem Addressed by the ’810 Patent
`
`One drawback of conventional IPSec security processing is that it is
`
`intended to work with “static network topology,” where the IPSec secure
`
`connection has fixed endpoints, i.e., fixed IP addresses, as defined by the SAs.
`
`Indeed, an SA that defines a secure connection is tied to specific IP addresses, and,
`
`if an address of one endpoint changes, a new SA must be negotiated. Ex. 1001
`
`[’810 Patent] 0009 (4:9-17); Ex. 2003 [Rouskas dec.] (¶ 50).
`
`This “mobility problem” most often arises when one endpoint is a mobile
`
`host (also referred to as “mobile terminal” or “mobile node”) that leaves one
`
`network and attaches to a second network with a new IP address. In that case, the
`
`mobile host can no longer sustain its IPSec secure connection because the
`
`previously used SA is no longer valid. Ex. 1001 [’810 Patent] 0009 (4:9-35); Ex.
`
`2003 [Rouskas dec.] (¶ 51). In that instance, the mobile host changing addresses
`
`6
`
`
`
`would require the negotiation of a new SA for the IPSec connection, a process
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`which is both time-consuming and computationally demanding.
`
`For example, the negotiation of a new SA to support a new mobile host IP
`
`address would require six to nine messages using IPSec’s Internet Key Exchange
`
`(IKE) protocol, as illustrated in steps 1b-9b of annotated Figure 4 of the ’810
`
`Patent and described in the accompanying passages in the specification.
`
`Ex. 1001 [’810 Patent] 0006 (Fig. 4, annotated), 0012 (9:12-39); Ex. 2003
`
`[Rouskas dec.] (¶¶ 52-53).
`
`C. The ’810 Patent’s Solution to the Mobility Problem
`
`
`
`7
`
`
`
`The ’810 Patent provides a solution to the mobility problem that allows
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`mobile hosts to change from one network to another and acquire a new IP address
`
`without having to negotiate a new SA defining the secure connection between the
`
`mobile host and the other IPSec endpoint. Ex. 1001 [’810 Patent] 0012 (10:14-16)
`
`(“The SA that existed between addresses A and X has now been changed to be
`
`between addresses B and X and is now complete.”); Ex. 2003 [Rouskas dec.]
`
`(¶ 55).
`
`The ’810 Patent thus provides for changing an existing SA tied to a mobile
`
`host address A into a modified SA that is tied to the new mobile host address B.
`
`The modification of the existing SA is accomplished through the use of signaling.
`
`The signaling includes a request sent from the mobile host from its new address B
`
`to the other IPSec endpoint X (step 10a in annotated Figure 5 below). Figure 5
`
`below also illustrates the optional reply (11a) that may be sent from endpoint X to
`
`the mobile terminal at its new address B.
`
`8
`
`
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`
`
`Ex. 1001 [’810 Patent] 0007 (Fig. 5) (annotated); Ex. 2003 [Rouskas dec.] (¶ 56).
`
`As described in the ’810 Patent, the invention’s application of request/reply
`
`signals overcomes problems in the prior art because it “allows an existing IPSec
`
`security association . . . to be moved from one network to another.” In other
`
`words, “an existing IPSec tunnel endpoint can be moved in the invention from
`
`one point of attachment to another” which would allow “an IPSec tunnel
`
`established between addresses A and X [to] be changed to be between addresses B
`
`and X using only a single round trip for signalling (2 messages), or half a round
`
`trip (1 message, if a reply message is not used) for signalling.” The solution
`
`requires minimal computational overhead compared to other approaches. Ex. 1001
`
`[’810 Patent] 0011 (7:28-42) (emphasis added); Ex. 2003 [Rouskas dec.] (¶ 57).
`
`9
`
`
`
`Relevant to the claims of the ’810 Patent, Figure 1 illustrates a first terminal
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`1 communicating over an IPSec tunnel connection with other terminal 3 via
`
`security gateway (SG) 2. Ex. 1001 [’810 Patent] 0011 (8:53-64). Figure 1
`
`(annotated) is depicted below:
`
`Ex. 1001 [’810 Patent] 0003 (Fig. 1) (annotated); Ex. 2003 [Rouskas dec.] (¶¶ 61-
`
`
`
`62).
`
`III.
`
`CLAIM CONSTRUCTION
`In accordance with 37 C.F.R. § 42.100(b), the PTAB construes the claims
`
`according to the same claim construction standard that would be used to construe
`
`the claims in district court. The claims should be construed starting with the
`
`ordinary and customary meaning as understood by the person of ordinary skill in
`
`10
`
`
`
`the art (POSITA) and considering the intrinsic evidence consisting of (1) the claim
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`language, (2) the specification and (3) the prosecution history. David Netzer
`
`Consulting Eng’r LLC v. Shell Oil Co., 824 F.3d 989, 993-94 (Fed. Cir. 2016);
`
`Phillips v. AWH Corp., 415 F.3d 1303, 1312-15 (Fed. Cir. 2005).
`
`Often, the specification is dispositive; it is the single best guide to the
`
`meaning of the disputed claim term and provides a “concordance for the claims.”
`
`Wright Medical Tech., Inc. v. Osteonics Corp., 122 F.3d 1440, 1443 (Fed. Cir.
`
`1997); Phillips v. AWH Corp., 415 F.3d 1303, 1315 (Fed. Cir. 2005). The
`
`specification acts as a dictionary when it expressly defines terms used in the claims
`
`or when it defines terms by implication. Phillips, 415 F.3d at 1321.
`
`The meaning of the claim term “security gateway” is in dispute in this
`
`proceeding. Instn., Paper 10, 25 (“In addition, Petitioner argues that one of
`
`ordinary skill in the art would have understood that Ishiyama’s ‘correspondent
`
`[host]’ would be a security gateway . . .”), 33 (“We find, based on the current
`
`record, that there is sufficient support in the record that Ishiyama’s correspondent
`
`host is a security gateway.”). Thus, the claim construction dispute in this
`
`proceeding is whether a correspondent host is a “security gateway.”
`
`Patent Owner respectfully submits 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
`
`11
`
`
`
`network.” A “security gateway” is a gateway that provides additional security
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`functionality, such as firewall functionality. Ex. 2003 [Rouskas dec.] (¶ 64).
`
`A. Claim Language
`
`Starting with the claim language, claim 1 of the ’810 Patent clearly
`
`differentiates between a “security gateway,” on the one hand, and “terminals” on
`
`the other hand. The preamble recites a network with “at least one mobile terminal
`
`and another terminal and a security gateway therebetween.” Ex. 1001 [’810
`
`Patent] 0012 (10:48-51) (emph. added). The structure of the claim provides that the
`
`terminals are the ultimate recipients and consumers of a message sent from one to
`
`the other, whereas the security gateway is an intermediary or conduit between the
`
`terminals: “[T]he mobile terminal sending a secure message . . . from the second
`
`address of the mobile terminal to the other terminal via the security gateway.”
`
`See Ex. 1001 [’810 Patent] 0012-0013 (10:67-11:3) (emph. added); Ex. 2003
`
`[Rouskas dec.] (¶ 65).
`
`Therefore, the claim language explicitly distinguishes a security gateway
`
`from hosts such as a mobile terminal or other terminal.
`
`B.
`
`Specification
`
`The specification of the ’810 Patent also supports the construction that a
`
`security gateway is an intermediary system with two or more communication
`
`interfaces that interconnects networks and can forward packets received from one
`
`12
`
`
`
`network to another network, as distinct from a host or terminal. The specification
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`uses “terminal” and “host” interchangeably, which is consistent with ordinary
`
`usage at the time of the invention. Ex. 2003 [Rouskas dec.] (¶ 66). For example,
`
`the specification refers to a “mobile terminal” (Ex. 1001 [’810 Patent] 0008 (1:16-
`
`22)) and later a “mobile host” (Ex. 1001 [’810 Patent] 0009 (4:15)).
`
`However, the specification assigns “security gateway” a different meaning
`
`from a host. For example, the specification distinguishes hosts and security
`
`gateways in its discussion of secure connections using the IPSec transport mode
`
`versus the IPSec tunnel mode. It describes security gateways as systems for
`
`interconnecting different networks and forwarding packets received from a host on
`
`one network to a host on another network:
`
`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 most often
`used when one or both ends of a SA is a security gateway, such as a
`firewall or 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. The SGW or the like filters all outgoing packets to
`determine the need for IPSec processing. If this packet from the first
`
`13
`
`
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`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.
`Ex. 1001 [’810 Patent] 0009 (3:8-59) (all emph. and underscore added); Ex. 2003
`
`[Rouskas dec.] (¶ 66). Nowhere does the specification remotely suggest that a host
`
`is a security gateway.
`
`
`
`Elsewhere, the specification describes a security gateway as having
`
`multiple communication interfaces for interconnecting networks and forwarding
`
`messages received from one network to another network. Ex. 1001 [’810 Patent]
`
`0011 (8:58-9:7) (e.g., computer 1 is a security gateway protecting a first LAN and
`
`computer 2 is a security gateway protecting a second LAN), 0003-0004 (Figs. 1-2)
`
`(e.g., each of security gateway 1 and security gateway 2 has two interfaces).
`
`A person of ordinary skill in the art would understand the specification to
`
`support the construction that a security gateway acts as an intermediary system
`
`with multiple interfaces that interconnects different networks and can forward
`
`received packets from one network on to another network and that provides
`
`security functionality. A person of ordinary skill in the art would readily recognize
`
`14
`
`
`
`that while a security gateway may interface between hosts, a host is not a security
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`gateway. Ex. 2003 [Rouskas dec.] (¶ 67).
`
`C.
`
`Prosecution History
`
`The prosecution history confirms that the claimed “security gateway” is not
`
`meant to cover the correspondent host of Ishiyama.
`
`During prosecution, the Applicant amended independent claim 1 to add the
`
`limitation of a “security gateway therebetween” the mobile terminal and the other
`
`terminal. Ex. 1003 [Prosecution History] 0227-0230. The Applicant distinguished
`
`the applied reference based on the added security gateway limitation: “Ishiyama
`
`merely teaches an updating of the mobile computer address and there is no
`
`teaching or suggestion of the correspondent being a security gateway for
`
`another computer.” Ex. 1003 [Prosecution History] 0232-0233 (emph. added). In
`
`the same response the Applicant further argued that “Ishiyama merely teaches an
`
`end-to-end connection between two computers (mobile computer and
`
`correspondent)” in contrast to the limitation requiring “the mobile terminal sending
`
`a secure message in the secure connection to the other terminal via the security
`
`gateway.” Ex. 1003 [Prosecution History] 0233 (underscore in original).
`
`In response, the Examiner withdrew the rejection based on Ishiyama. The
`
`Examiner issued a new rejection based on new references. Ex. 1003 [Prosecution
`
`History] 0243-0250. In sum, the Applicant distinguished and overcame the
`
`15
`
`
`
`Ishiyama-based rejection by, inter alia, amending the claims to add the “security
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`gateway” to all claims and successfully arguing that Ishiyama’s correspondent host
`
`does not disclose a “security gateway.”
`
`D. Disclosure of Security Gateway in Documents from the
`Prosecution History or Relied Upon by Petitioner
`
`The Board states in its Institution Decision that “Patent Owner incorrectly
`
`focuses on the names of the network devices.” Pet., 36. The Board also states that
`
`“the correct focus is how the cited devices are deployed and function . . .” Instn.,
`
`Paper 10, 36-37.
`
`Dr. Rouskas addresses the issue of terminology and functionality at length in
`
`his declaration. Ex. 2003 [Rouskas dec.] (¶¶ 67-90). As to terminology, he explains
`
`that a person of ordinary skill in the art at the time of the invention would not
`
`consider a “correspondent host” to be a “security gateway.” As to function, a
`
`“security gateway” is defined as a system functioning as an intermediary with
`
`multiple interfaces and that interconnects networks and can forward received
`
`packets from one network on to another.1 Ex. 2003 [Rouskas] (¶ 69).
`
`
`
`1 Dr. Rouskas recognizes that the same system can perform different
`
`functions. For example, a security gateway can occasionally function as a host
`
`16
`
`
`
`Case IPR2019-00819
`Patent 7,620,810
`
`Dr. Rouskas examines a number of documents, some of which are part of the
`
`prosecution history, which confirm that a gateway functions as an intermediary
`
`system with two or more communication interfaces that interconnects networks
`
`and can forward received packets between networks, in contrast to a host which is
`
`an end system with a single communication interface that sends or receives
`
`packets.
`
`1. Murakawa
`Petitioner’s asserted reference Murakawa has a disclosure confirming that a
`
`security gateway has at least two communication interfaces and interconnects
`
`networks and forwards received packets from one network to another. Figure 5
`
`illustrates security gateway 103 as having two interfaces and interconnecting
`
`networks LAN 104 and WAN 102. The security gateway 103 receives packets
`
`from LAN 104 and forwards them to WAN PC 101 using a VPN connection. Ex.
`
`1005 [Murakawa] 0006 (Fig. 5) (annotated), 0009 (Fig. 8), 0010-0011 (1:50-2:4,
`
`2:66-3:28); Ex. 1003 [Rouskas dec.] (¶ 72). On the other hand, PC hosts 106 and
`
`
`
`when it processes certain commands. Ex. 2003 [Rouskas dec.] (¶ 70). The converse
`
`is not true: A host with a single interface cannot provide a security gateway
`
`functionality.
`
`17
`
`
`
`107 are end systems with a single interface that send and receive packets. The
`
`Case IPR2019-00819
`Patent 7,620,810
`
`
`security gateway 103 is distinct from host devices 106 and 107 in