Case IPR2019-00819
`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
`
`
`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
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
