Case IPR2019-00820
`Patent 7,937,581
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner.
`____________
`
`Case IPR2019-00820
`Patent 7,937,581
`____________
`
`
`
`REPLACEMENT PATENT OWNER’S RESPONSE
`PURSUANT TO 37 C.F.R. § 42.120
`
`
`
`Patent 7,937,581
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner.
`____________
`
`Case IPR2019-00820
`Patent 7,937,581
`____________
`
`
`
`REPLACEMENT PATENT OWNER’S RESPONSE
`PURSUANT TO 37 C.F.R. § 42.120
`
`
`
`
`TABLE OF CONTENTS
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`Page
`
`I.
`
`II.
`
`INTRODUCTION ........................................................................................ 1
`
`OVERVIEW OF THE ’581 PATENT AND THE STATE OF THE
`ART ................................................................................................................ 4
`
`A. Technical Background ....................................................................... 4
`
`B. The Mobility Problem Addressed by the ’581 Patent .................... 5
`
`C. The ’581 Patent’s Solution to the Mobility Problem ...................... 7
`
`III. CLAIM CONSTRUCTION ...................................................................... 10
`
`A. Claim Language ................................................................................. 11
`
`B.
`
`Specification ....................................................................................... 12
`
`C. Prosecution History ........................................................................... 14
`
`D. Disclosure of Security Gateway in Documents from the
`Prosecution History or Relied Upon by Petitioner ........................ 15
`
`1. Murakawa ................................................................................ 17
`
`2.
`
`3.
`
`4.
`
`5.
`
`Ahonen ..................................................................................... 18
`
`Frankel ..................................................................................... 19
`
`RFC 1122 ................................................................................. 22
`
`RFC 2401 ................................................................................. 23
`
`IV. GROUND 1: CLAIMS 1-2, 4, 6-7 AND 9 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-00820
`Patent 7,937,581
`
`
`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 ........................ 34
`
`Ishiyama’s Description of IPSec Processing Using
`the Security Databases Proves that the
`Correspondent Host is Not a Security Gateway ......... 35
`
`(d) Petitioner’s Theory that the Correspondent Host
`Must be a Security Gateway Because IPSec Tunnel
`Mode is Used is Incorrect .............................................. 37
`
`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 ................................................. 42
`
`(e)
`
`Petitioner’s Argument in this Proceeding that the
`Correspondent Host is a Security Gateway is
`Contradicted by the Position Taken in IPR2019-
`00821 .............................................................................. 44
`
`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-00820
`Patent 7,937,581
`
`
`Terminal Sending a Request Message to the Gateway
`Address of the Security Gateway to Request the Security
`Gateway to Change the Secure Connection to Be Defined
`Between the Second Address and the Gateway Address
`of the Security Gateway” ......................................................... 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
`
`B. Claim 4 is Patentable Over the Combination of Ishiyama and
`Murakawa Because the Petition Fails to Establish that the
`Prior Art Teaches the “Request Message And/Or a Reply
`Message is Encrypted And/Or Authenticated” ............................... 61
`
`C. Claims 6-7 are Patentable Over the Combination of Ishiyama
`and Murakawa .................................................................................... 63
`
`D. Claim 9 is Patentable Over the Combination of Ishiyama and
`Murakawa ........................................................................................... 65
`
`V.
`
`GROUND 2: CLAIMS 3 AND 5 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 3) or a “Reply Message
`to the Mobile Terminal at the Second Address to Confirm the
`Address Change” (Claim 5) .............................................................. 70
`
`VI. GROUND 3: CLAIM 8 IS PATENTABLE OVER THE
`COMBINATION OF ISHIYAMA, MURAKAWA AND FORSLOW . 73
`
`VII. CONCLUSION ........................................................................................... 73
`
`
`
`iii
`
`
`
`TABLE OF AUTHORITIES
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`Page(s)
`
`CASES
`
`Continental Can Co. v. Monsanto Co.,
`948 F.2d 1264 (Fed. Cir. 1991) .......................................................................... 39
`
`David Netzer Consulting Eng’r LLC v. Shell Oil Co.,
`824 F.3d 989 (Fed. Cir. 2016) ............................................................................ 10
`
`Graham v. John Deere Co.,
`383 U.S. 1 (1966) ......................................................................................... 25, 26
`
`In re Robertson,
`169 F.3d 743 (Fed.Cir.1999) ....................................................................... 39, 45
`
`InTouch Techs., Inc. v. VGO Commc’ns, Inc.,
`751 F.3d 1327 (Fed. Cir. 2014) .......................................................................... 55
`
`KSR Int’l Co. v. Teleflex Inc.,
`127 S.Ct. 1727 (2007) ......................................................................................... 26
`
`Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co.,
`851 F.3d 1270 (Fed. Cir. 2017) ................................................................... 45, 48
`
`Personal Web Techs., LLC v. Apple, Inc.,
`848 F.3d 987 (Fed. Cir. 2017) ............................................................... 53, 54, 56
`
`Pfizer, Inc. v. Apotex, Inc.,
`480 F.3d 1348 (Fed. Cir. 2007) .......................................................................... 26
`
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) ................................................................... 10, 11
`
`Regents of Univ. of California v. Broad Institute, Inc.,
`903 F.3d 1286 (Fed. Cir. 2018) .......................................................................... 26
`
`iv
`
`
`
`Rosco, Inc. v. Mirror Lite Co.,
`304 F.3d 1373 (Fed. Cir. 2002) .......................................................................... 39
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`TQ Delta, LLC v. CISCO Systems, Inc.,
`942 F.3d 1352 (Fed. Cir. 2019) ................................................................... 54, 55
`
`Wright Medical Tech., Inc. v. Osteonics Corp.,
`122 F.3d 1440 (Fed. Cir. 1997) .......................................................................... 10
`
`
`
`STATUTES
`
`35 U.S.C. § 103 ........................................................................................................ 25
`
`
`
`REGULATIONS
`
`37 C.F.R. § 42.10 ..................................................................................................... 10
`
`v
`
`
`
`
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`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 Petition in IPR2019-00819
`
`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)
`
`2009 Declaration of George N. Rouskas
`
`vi
`
`
`
`I.
`
`INTRODUCTION
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`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.
`
`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 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).
`
`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
`
`1
`
`
`
`Case IPR2019-00820
`Patent 7,937,581
`
`over an IPSec connection changed its IP address from X to Y the existing SA could
`
`no longer be used.
`
`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.
`
`The Petition asserts in Ground 1 that independent claim 1 and independent
`
`claim 9 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 ’581 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
`
`2
`
`
`
`networks and can forward packets it receives on to other systems using multiple
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`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 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 Petition never provides a plausible motivation to combine
`
`because the proposed 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-9 are
`
`unpatentable.
`
`
`
`
`
`3
`
`
`
`Case IPR2019-00820
`Patent 7,937,581
`
`II. OVERVIEW OF THE ’581 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.” Ex.
`
`2009 [Rouskas dec.] (¶¶ 37-43).
`
`The ’581 Patent describes fundamental concepts of IPSec secure
`
`connections. For example, Security Associations (SAs) are data structures that are
`
`fundamental to IPSec processing. Ex. 1001 [’581 Patent] 0007 (2:23-34). The ’581
`
`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 [’581 Patent] 0007 (2:23-42); Ex. 2009 [Rouskas dec.]
`
`(¶¶ 44-45).
`
`The ’581 Patent discloses that an SA is uniquely defined by three
`
`parameters: (1) the Security Parameters Index (SPI), (2) the IP destination address
`
`4
`
`
`
`(Dst), and (3) the IPSec security protocol type (AH/ESP). For each IPSec
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`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 [’581 Patent] 0007 (2:43-3:2); Ex. 2009 [Rouskas dec.]
`
`(¶ 46).
`
`The ’581 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
`
`of the outer packet can have source and destination addresses that are completely
`
`different from the source and destination addresses of the encapsulated inner
`
`packet. Ex. 1001 [’581 Patent] 0008 (3:10-46); Ex. 2009 [Rouskas dec.] (¶ 47).
`
`B.
`
`The Mobility Problem Addressed by the ’581 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,
`
`5
`
`
`
`if an address of one endpoint changes, a new SA must be negotiated. Ex. 1001
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`[’581 Patent] 0008 (4:12-20); Ex. 2009 [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 [’581 Patent] 0008 (Col. 4:12-39);
`
`Ex. 2009 [Rouskas dec.] (¶ 51)
`
`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 ’581
`
`Patent and described in the accompanying passages in the specification.
`
`6
`
`
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`
`
`Ex. 1001 [’581 Patent] 0005 (Fig. 4, annotated), 0012 (9:1-28); Ex. 2009 [Rouskas
`
`dec.] (¶ 52).
`
`C. The ’581 Patent’s Solution to the Mobility Problem
`
`The ’581 Patent provides a solution to the mobility problem that allows
`
`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 [’581 Patent] 0011 (10:11-13)
`
`(“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. 2009 [Rouskas dec.]
`
`(¶ 55).
`
`7
`
`
`
`The ’581 Patent thus provides for changing an existing SA tied to a mobile
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`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 using 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.
`
`
`
`Ex. 1001 [’581 Patent] 0006 (Fig. 5) (annotated); Ex. 2009 [Rouskas dec.] (¶ 56).
`
`As described in the ’581 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
`
`8
`
`
`
`words, “an existing IPSec tunnel endpoint can be moved in the invention from
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`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
`
`[’581 Patent] 0010 (7:23-37) (emphasis added); Ex. 2009 [Rouskas dec.] (¶ 57).
`
`Relevant to the claims of the ’581 Patent, Figure 1 illustrates a first terminal
`
`1 communicating over an IPSec tunnel connection with other terminal 3 via
`
`security gateway (SG) 2. Ex. 1001 [’581 Patent] 0010 (8:50-61). Figure 1
`
`(annotated) is depicted below:
`
`
`
`9
`
`
`
`Ex. 1001 [’581 Patent] 0002 (Fig. 1) (annotated); Ex. 2009 [Rouskas dec.] (¶ 61).
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`III. CLAIM CONSTRUCTION
`In accordance with 37 C.F.R. § 42.10, 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
`
`the art (POSITA) and considering the intrinsic evidence consisting of (1) the claim
`
`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-1315 (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, 415 F.3d at 1315. 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, 26 (“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 . . .), 34 (“We find, based on the current
`
`10
`
`
`
`record, that there is sufficient support in the record that Ishiyama’s correspondent
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`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
`
`network.” A “security gateway” is a gateway that provides additional security
`
`functionality, such as firewall functionality. Ex. 2009 [Rouskas dec.] (¶ 64).
`
`A. Claim Language
`
`Starting with the claim language, claim 1 of the ’581 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 [’581
`
`Patent] 0011 (10:50-53) (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 [’581 Patent] 0012 (11:1-3) (emph. added); Ex. 2009 [Rouskas dec.]
`
`(¶ 65).
`
`11
`
`
`
`Therefore, the claim language explicitly distinguishes a security gateway
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`from hosts such as a mobile terminal or other terminal.
`
`B.
`
`Specification
`
`The specification of the ’581 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
`
`network to another network, as distinct from a host or terminal. The specification
`
`uses “terminal” and “host” interchangeably, which is consistent with ordinary
`
`usage at the time of the invention. Ex. 2009 [Rouskas dec.] (¶ 66). For example,
`
`the specification refers to a “mobile terminal” (Ex. 1001 [’581 Patent] 0007 (1:18-
`
`25)) and later a “mobile host” (Ex. 1001 [’581 Patent] 0009 (4:19-21)).
`
`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
`
`12
`
`
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`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 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 [’581 Patent] 0008 (3:14-62) (all emph. added); Ex. 2009 [Rouskas
`
`dec.] (¶ 66). Nowhere does the specification state 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 [’581 Patent] 0010 (8:55-
`
`63) (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
`
`13
`
`
`
`with multiple interfaces that interconnects different networks and can forward
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`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
`
`that while a security gateway may interface between hosts, a host is not a security
`
`gateway. Ex. 2009 [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 of the parent application leading to U.S. Pat. No.
`
`7,620,810 (’810 Patent), the Applicant amended independent claim 1 to add the
`
`limitation of a “security gateway therebetween” the mobile terminal 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
`
`14
`
`
`
`a secure message in the secure connection to the other terminal via the security
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`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
`
`Ishiyama-based rejection by, inter alia, amending the claims to add the “security
`
`gateway” to all claims and successfully arguing that Ishiyama’s correspondent host
`
`does not disclose a “security gateway.”
`
`This prosecution history directly bears on the understanding of the “security
`
`gateway” term because the independent claims of the ’581 Patent share the same
`
`limitations as the ’810 Patent (e.g., “a telecommunication network, having at least
`
`one mobile terminal and another terminal and a security gateway therebetween;”
`
`“the mobile terminal sending a secure message in the secure connection . . . to the
`
`other terminal via the 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, 37.
`
`15
`
`
`
`Case IPR2019-00820
`Patent 7,937,581
`
`Dr. Rouskas addresses the issue of terminology and functionality at length in
`
`his declaration. Ex. 2009 [Rouskas dec.] (¶¶ 68-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
`
`Dr. Rouskas examines a number of documents that 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 Dr. Rouskas recognizes that the same system can perform different
`
`functions. For example, a security gateway can occasionally function as a host
`
`when it processes certain commands. Ex. 2009 [Rouskas dec.] (¶ 70). The converse
`
`is not true: A host with a single interface cannot provide a security gateway
`
`functionality.
`
`16
`
`
`
`1. Murakawa
`Petitioner’s asserted reference Murakawa has a disclosure confirming that a
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`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
`
`107 are end systems with a single interface that send and receive packets. The
`
`security gateway 103 is distinct from host devices 106 and 107 in Figures 5 and 8
`
`of Murakawa.
`
`17
`
`
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`
`
`2.
`Ahonen
`The Ahonen reference is cited on the face of the patent. Ex. 1001 [’581
`
`Patent] 0001. Ahonen, which is applied by Petitioner in this proceeding, illustrates
`
`a security gateway (firewall) 3 as having multiple interfaces interconnecting
`
`multiple networks: a first interface to Internet 2, a second interface to core network
`
`7 and a third interface to LAN 5. Ex. 1006 [Ahonen] 0003 (Fig. 1) (annotated
`
`below), 0007 (3:57-4:1). Security gateway 3 is shown to be distinct from
`
`correspondent host 4, which is an end system having a single communication
`
`18
`
`
`
`Case IPR2019-00820
`Patent 7,937,581
`
`interface. Ahonen confirms that a correspondent host is not a security gateway. Ex.
`
`2009 [Rouskas dec.] (¶¶ 73-74).
`
`
`
`
`
`Ex. 1006 [Ahonen] 0003 (Fig. 1) (annotated), 0007 (3:57-4:1).
`
`3.
`Frankel
`Petitioner’s expert, Dr. Goldschlag, relies upon Ex. 1008, which is a 2001
`
`book authored by Sheila Frankel entitled “Demystifying the IPsec Puzzle.” Ex.
`
`1002 [Goldschlag dec.] at 2. Dr. Goldschlag cites to Frankel eleven times in his
`
`declaration. As one example, Dr. Goldschlag cites to Figures 1.1(b) and 1.1(c) of
`
`Frankel (Ex. 1002 [Goldschlag dec.] 17-18 (¶ 34)), as shown below:
`
`19
`
`
`
`Case IPR2019-00820
`Patent 7,937,581
`
`
`
`
`The figures cited by Dr. Goldschlag support the construction that a security
`
`g
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
