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

`

`TABLE OF CONTENTS
`Qualifications ................................................................................................... 4
`
`I.
`
`II. My Understanding of Claim Construction ...................................................... 7
`
`III. My Understanding of Obviousness ................................................................. 7
`
`IV. Level of Ordinary Skill in the Art ................................................................. 10
`
`V. Overview of the ’581 Patent .......................................................................... 10
`
`VI. Overview of the State of the Art at the Time of Filing ................................. 14
`
`A.
`
`B.
`
`C.
`
`D.
`
`Internet Protocol Security (IPSec) and Security Associations (SAs) . 14
`
`IPSec Transport Mode vs. Tunnel Mode ............................................ 16
`
`The IPSec Mobility Problem ............................................................... 19
`
`Prior Art Solutions to the IPSec Mobility Problem ............................ 21
`
`VII. Claims 1-2, 4, 6-7, and 9 are Obvious Over Ishiyama and Murakawa. ........ 24
`
`A. Overview of Ishiyama ......................................................................... 24
`
`B.
`
`C.
`
`Overview of the Combination of Ishiyama and Murakawa ................ 30
`
`The Combination of Ishiyama and Murakawa Renders Claim 1
`Obvious. .............................................................................................. 34
`
`1.
`
`2.
`
`Ishiyama in view of Murakawa discloses “A method for
`ensuring secure forwarding of a message in a
`telecommunication network, having at least one mobile
`terminal and another terminal and a security gateway
`therebetween” [1-pre]. .............................................................. 34
`
`Ishiyama discloses “a) establishing a secure connection having
`a first address of the mobile terminal as a first end-point and a
`gateway address of the security gateway as a second end-point,”
`[1A]. .......................................................................................... 39
`
`- i -
`
`

`

`3.
`
`4.
`
`5.
`
`6.
`
`Ishiyama discloses “b) the mobile terminal changing from the
`first address to a second address,” [1B]. ................................... 43
`
`Ishiyama discloses “c) while at the second address, the mobile
`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,” [1C]. ......... 44
`
`Ishiyama discloses “in response to the request message from the
`mobile terminal, the security gateway changing an address
`definition of the secure connection from the first address to the
`second address,” [1D]. .............................................................. 47
`
`Ishiyama in view of Murakawa discloses “the mobile terminal
`sending a secure message in the secure connection from the
`second address of the mobile terminal to the other terminal via
`the security gateway.” [1E]. ...................................................... 49
`
`D.
`
`E.
`
`F.
`
`G.
`
`H.
`
`The Combination of Ishiyama and Murakawa Renders Claim 9
`Obvious. .............................................................................................. 54
`
`The Combination of Ishiyama and Murakawa Renders Claim 2
`Obvious. .............................................................................................. 62
`
`The Combination of Ishiyama and Murakawa Renders Claim 4
`Obvious. .............................................................................................. 64
`
`The Combination of Ishiyama and Murakawa Renders Claim 6
`Obvious. .............................................................................................. 65
`
`The Combination of Ishiyama and Murakawa Renders Claim 7
`Obvious. .............................................................................................. 71
`
`VIII. Claims 3 and 5 are Obvious Over Ishiyama, Murakawa, and Ahonen. ........ 71
`
`A. Overview of the Combination of Ishiyama, Murakwa, and U.S. Patent
`6,976,177 (Ahonen) ............................................................................. 71
`
`B.
`
`The Combination of Ishiyama, Murakwa, and Ahonen Renders
`Claims 3 and 5 Obvious. ..................................................................... 77
`
`- ii -
`
`

`

`IX. Claim 8 is Obvious Over Ishiyama, Murakawa, and Forslöw. ..................... 79
`
`X.
`
`Conclusion ..................................................................................................... 84
`
`- iii -
`
`

`

`I, Dr. David Goldschlag, declare as follows:
`
`1.
`
`I have been retained on behalf of Apple Inc. for the above-captioned
`
`inter partes review proceeding. I understand this proceeding involves U.S. Patent
`
`No. 7,937,581 (“’581 patent”), titled “Method and Network For Ensuring Secure
`
`Forwarding of Messages,” and that the ’581 patent is currently assigned to MPH
`
`Technologies OY.
`
`2.
`
`I have reviewed and am familiar with the specification of the ’581
`
`patent, issued on May 3, 2011. I understand the ’581 patent has been provided as
`
`Ex. 1001. I will cite to the specification using the following format: Ex. 1001, ’581
`
`patent, 1:1-10. This example citation points to the ’581 patent specification at
`
`column 1, lines 1-10.
`
`3.
`
`I have reviewed and am familiar with the following prior art used in
`
`the Petition for Inter Partes Review of the ’581 patent:
`
`• U.S. Patent No. 6,904,466 to Ishiyama et al. was filed on May 19,
`
`2000, more than one year before the earliest possible priority date of
`
`the ’581 patent. I understand Ishiyama has been provided as Ex. 1004.
`
`• U.S. Patent No. 7,028,337 to Murakawa was filed on December 1,
`
`2000 and published September 6, 2001, both dates being before the
`
`earliest priority date of the ’581 patent. I understand Murakawa has
`
`been provided as Ex. 1005.
`
`- 1 -
`
`

`

`• U.S. Patent No. 6,976,177 to Ahonen was filed on January 18, 2001
`
`and published on July 19, 2001, both dates being before the earliest
`
`priority date of the ’581 patent. I understand Ahonen has been
`
`provided as Ex. 1006.
`
`• U.S. Patent No. 6,954,790 to Forslöw was filed on December 5,
`
`2000, more than one year before the PCT priority date of the ’581
`
`patent. I understand Forslöw has been provided as Ex. 1007.
`
`4.
`
`I have also reviewed the following other documents:
`
`• Demystifying the IPsec Puzzle, Sheila Franklel, Published 2001. I
`
`understand Frankel has been provided as Ex. 1008.
`
`• IP Security - The Internet Protocol Journal – Volume 3, No. 1,
`
`William Stallings, Published March 2000. I understand Stallings has
`
`been provided as Ex. 1009.
`
`• Mobility-aware IPsec ESP tunnels, Francis Dupont, IETF Draft
`
`Posted February 22, 2001. I understand Dupont has been provided as
`
`Ex. 1010.
`
`• RFC2401 – Security Architecture for the Internet Protocol, S. Kent
`
`and R. Atkinson, November 1998. I understand RFC2401 has been
`
`provided as Ex. 1011.
`
`- 2 -
`
`

`

`• RFC793 – Transmission Control Protocol: DARPA Internet Program
`
`Protocol Specification, Information Sciences Institute, University of
`
`Southern California, September 1981. I understand RFC793 has been
`
`provided as Ex. 1012.
`
`• Declaration of Sandy Ginoza for IETF provided as Ex. 1017. I am
`
`familiar with the Request for Comments (RFC) process based on my
`
`experience. As Ms. Sandy Ginoza explains, RFC2401 was indexed
`
`and made publicly available no later than November 1998. Ex. 1017,
`
`Ginoza Decl., ¶10. RFC793 was indexed and made publicly available
`
`no later than October 1992. Id., ¶11.
`
`• Declaration of Alexa Morris provided as Ex. 1018. I am familiar with
`
`the IETF draft process based on my experience. As Ms. Alexa Morris
`
`explains, the “Mobility-aware IPsec ESP tunnels” reference by
`
`Dupont provided as Ex. 1010 was made available to the public by
`
`February 2001. Ex. 1018, Morris Decl., ¶9.
`
`• U.S. Patent No. 7,079,499 to Akhtar et al. was filed on
`
`September 7, 2000, more than one year before the earliest
`
`priority date of the ’581 patent. I understand Akhtar has been
`
`provided as Ex. 1013.
`
`- 3 -
`
`

`

`• U.S. Pat. No. 7,174,018 to Patil et al. was filed on June 16,
`
`2000, more than one year before the earliest priority date of the
`
`’581 patent. I understand Patil has been provided as Ex. 1014.
`
`• U.S. Patent No. 6,418,130 to Cheng et al. was filed on January
`
`21, 1999, more than one year before the earliest priority date of
`
`the ’581 patent. I understand Cheng has been provided as Ex.
`
`1015.
`
`• U.S. Patent No. 7,620,810 to Vaarala et al., the parent
`
`application of the ’581 patent. I understand the ’810 patent has
`
`been provided as Ex. 1019.
`
`• The Inter Partes Review Petition filed in this case.
`
`5.
`
`I am familiar with the technology described in the ’581 patent as of its
`
`earliest possible priority date of September 28, 2001. I have been asked to provide
`
`my technical review, analysis, insights, and opinions regarding the ’581 patent. I
`
`have used my experience and insight along with the above-noted references as the
`
`basis for my opinions, which support the grounds of unpatentability set forth in the
`
`Petition for Inter Partes Review of the ’581 Patent.
`
`I.
`
`Qualifications
`
`6. My qualifications are stated more fully in my curriculum vitae,
`
`attached as Exhibit 1016. Here, I provide a brief summary of my qualifications:
`
`- 4 -
`
`

`

`7.
`
`I have extensive education and work experience in the field of
`
`computer security. I received a B.S. degree in Computer Science from Wayne State
`
`University in 1985, then received a Ph.D. degree in Computer Science from the
`
`University of Texas at Austin in 1992. In my Ph.D. program, I studied formal
`
`methods and automated
`
`theorem proving. My Ph.D.
`
`thesis focused on
`
`methodologies for increasing the confidence one may have that computer systems
`
`behave as desired in terms of functionality, security, and safety.
`
`8.
`
`I have conducted significant research and published numerous papers
`
`in the field of computer security. Specifically, I have published 34 papers in the
`
`field of computer security, including papers on verification of computer programs,
`
`verification of computer hardware, novel techniques for smartcard security for
`
`cable and satellite TV systems, techniques for privacy in electronic transactions,
`
`techniques for secure lotteries that do not depend on the trustworthiness of the
`
`lottery operator, and Onion Routing. Onion Routing, now called Tor, is a system
`
`used for protecting privacy and anonymity on the internet. I and my co-inventors
`
`of Onion Routing were awarded the Alan S. Berman Award at the Naval Research
`
`Laboratory in 1999.
`
`9. My research and work in computer security has resulted in my being a
`
`joint inventor on 12 issued patents related to computer security, including a patent
`
`- 5 -
`
`

`

`on Onion Routing, patents related to security for paid video content, and patents
`
`related to security and compliance of devices accessing enterprise systems.
`
`10. Since 1987, I have continuously worked for government agencies and
`
`private companies within the field of computer security. For example, from 1993
`
`to 1997 I worked for the Naval Research Laboratory researching computer security
`
`and privacy solutions, developing security architectures, and developing
`
`technologies
`
`to
`
`increase computer security and privacy for e-commerce
`
`applications. It was at the Naval Research Laboratory that I co-invented Onion
`
`Routing. From 1997 to 1999, I worked at Divx developing a cost-effective way to
`
`secure digital entertainment content for movie rental distribution via protected
`
`DVDs. These positions, along with my education, all of which were completed
`
`before the relevant time for assessing validity of the ’581 patent, more than qualify
`
`me as a person of ordinary skill in the art of the ’581 patent at the relevant time. In
`
`addition, I worked with people with the same experience as a person of ordinary
`
`skill in the art. From my personal experience working on computer security
`
`solutions and from my interactions with others, I understand the types of problems
`
`and the knowledge a person of ordinary skill in the art would have confronted and
`
`possessed at the relevant time.
`
`11.
`
`I have continued my work in computer security after the relevant time
`
`as well, from 1999 to the present. I have held several top-level executive positions
`
`- 6 -
`
`

`

`with companies focused on computer security, including KeySec software, Trusted
`
`Edge, Inc., Trust Digital, Inc., McAfee, Inc., MobileSpaces (Cellsec, Inc.), Pulse
`
`Secure, LLC, and New Edge Labs, Inc. In view of my education and experience
`
`both before and after the relevant time, I am an expert in computer security, with
`
`knowledge and skill in the art of the ’581 patent that is well beyond the level of
`
`knowledge and skill of a person of ordinary skill in the art of the ’581 patent.
`
`12. My Curriculum Vitae is attached as Ex. 1016, which contains further
`
`details on my education, experience, publications, and other qualifications to
`
`render an expert option. My work on this case is being billed at my normal hourly
`
`rate, with reimbursement for actual expenses. My compensation is not contingent
`
`upon the outcome of this inter partes review.
`
`II. My Understanding of Claim Construction
`
`13.
`
`I understand that, before the PTAB, claims are to be given their
`
`ordinary and customary meaning in light of the specification as would have been
`
`read by a person having ordinary skill in the relevant art (also referred to herein as
`
`a “POSITA”).
`
`III. My Understanding of Obviousness
`
`14.
`
`I understand a patent claim is invalid if the claimed invention would
`
`have been obvious to a person of ordinary skill in the field at the time the
`
`application was filed. This means that even if all of the requirements of the claim
`
`- 7 -
`
`

`

`cannot be found in a single prior art reference that would anticipate the claim, the
`
`claim can still be invalid.
`
`15. As part of this inquiry, I have been asked to consider the level of
`
`ordinary skill in the field that someone would have had at the time the claimed
`
`invention was made. In deciding the level of ordinary skill, I considered the
`
`following:
`
`• the levels of education and experience of persons working in the field;
`
`• the types of problems encountered in the field; and
`
`• the sophistication of the technology.
`
`16. To obtain a patent, a claimed invention must have, as of the priority
`
`date, been nonobvious in view of the prior art in the field. I understand an
`
`invention is obvious when the differences between the subject matter sought to be
`
`patented and the prior art are such that the subject matter as a whole would have
`
`been obvious at the time the invention was made to a person having ordinary skill
`
`in the art.
`
`17.
`
`I understand that to prove prior art or a combination of prior art
`
`renders a patent obvious, it is necessary to: (1) identify the particular references
`
`that, singly or in combination, make the patent obvious; (2) specifically identify
`
`which elements of the patent claim appear in each of the asserted references; and
`
`- 8 -
`
`

`

`(3) explain how the prior art references could have been combined in order to
`
`create the inventions claimed in the challenged claim.
`
`18.
`
`I understand certain objective indicia can be important evidence
`
`regarding whether a patent is obvious or nonobvious. Such indicia include:
`
`(1) commercial success of products covered by the patent claims; (2) a long-felt
`
`need for the invention; (3) failed attempts by others to make the invention;
`
`(4) copying of the invention by others in the field; (5) unexpected results achieved
`
`by the invention as compared to the closest prior art; (6) praise of the invention by
`
`the infringer or others in the field; (7) the taking of licenses under the patent by
`
`others; (8) expressions of surprise by experts and those skilled in the art at the
`
`making of the invention; and (9) the patentee proceeded contrary to the accepted
`
`wisdom of the prior art.
`
`19.
`
`I also understand that “obviousness” is a legal conclusion based on the
`
`underlying factual issues of the scope and content of the prior art, the differences
`
`between the claimed invention and the prior art, the level of ordinary skill in the
`
`field of the prior art, and any objective indicia of non-obviousness. For that reason,
`
`I am not rendering a legal opinion on the ultimate legal question of obviousness.
`
`Rather, my testimony addresses the underlying facts and provides factual analysis
`
`that would support a legal conclusion of obviousness or non-obviousness. When I
`
`- 9 -
`
`

`

`use the term obvious, it is with reference to the perspective of one of ordinary skill
`
`at the time of invention.
`
`IV. Level of Ordinary Skill in the Art
`
`20. Based on the disclosures of the ’581 patent, a POSITA would have
`
`had a bachelor’s degree in Electrical Engineering, Computer Engineering,
`
`Computer Science, or an equivalent field as well as at least 2-5 years of academic
`
`or industry experience in the computer network security industry.
`
`21. The required levels of educational and industry experience are on a
`
`sliding scale relative to each other. A person of ordinary skill could have a more
`
`advance educational degree with less industry experience.
`
`V. Overview of the ’581 Patent
`
`22. The ’581 patent relates to a method and network that securely
`
`forwards messages in a telecommunication network. ’581 patent, Ex. 1001,
`
`Abstract. In particular, the ’581 patent describes facilitating communications
`
`received from a mobile host using the IPSec protocol. Id., 6:59-67. “The IP
`
`Security protocols (IPSec) provides the capability to secure communications
`
`between arbitrary hosts” using negotiated encryption keys. Id., 1:59-61. These
`
`encryption keys are typically negotiated in an automated fashion using a protocol
`
`known as “Internet Key Exchange” or IKE. Id., 4:6-11.
`
`- 10 -
`
`

`

`23. One well-known limitation of the IPsec protocol, however, is that it
`
`was designed to only connect computers having fixed IP addresses. Id., 4:12-16.
`
`This is because the negotiated encryption keys for the IPSec connection are stored
`
`in a structure referred to as a “security association (SA)” and the “SAs are bound to
`
`static addresses.” See id., 4:60-62. Therefore, conventionally, when a mobile
`
`computer moves to a different network and consequently changes to a different IP
`
`address, the “IKE key exchange will have to be redone.” Id., 4:19-21.
`
`24.
`
`“This
`
`is problematic, because
`
`IKE key exchanges
`
`involve
`
`computationally expensive . . . calculations.” Id., 4:21-24. Further, re-establishing
`
`an IPSec SA may result in an interruption of service due to the many messages
`
`required for a full re-negotiation of the SA. See id., 9:29-35 The ’581 patent
`
`identifies this known issue of a moving mobile terminal in a telecommunication
`
`network with IPSec. Id., 4:15-30. In particular, the ’581 patent explains that when
`
`a mobile terminal moves to a different network address, a “full re-negotiation” of
`
`keys is required to re-establish a new secure connection. See id., 9:29-33, 9:57-59.)
`
`25. To avoid this “full re-negotiation,” the ’581 patent states its solution is
`
`to simply require the mobile terminal to send a notification to update the SA with
`
`the new address. Id., Abstract. The ’581 explains that this “signaling mechanism”
`
`allows an existing secure connection to be re-used and updated via a request
`
`message sent from the mobile terminal. See id., 7:23-42. In this manner, the ’581
`
`- 11 -
`
`

`

`patent proposes the reestablishment of a secure connection may be avoided and
`
`some processing steps may be saved, as seen from a comparison of Figure 5 to
`
`Figure 4. See id., 10:17-20.
`
`26. To illustrate this operation, the ’581 patent describes the movement of
`
`a mobile terminal from a first address to a second address while the mobile
`
`terminal is communicating with an “other terminal.” Id., Abstract. The ’581 patent
`
`describes this mobile terminal as a “first terminal.” Id. “The first terminal moves
`
`from a first address to a second address.” Id. “When the first terminal moves from
`
`the first address to a second address, the connection is changed to be between the
`
`second address and [] the other terminal by means of a request from the first
`
`terminal . . . .” Id.
`
`27. The ’581 patent describes an embodiment of this communication
`
`process using a “security gateway.” See id., 8:50-60. Figure 1 as annotated below
`
`depicts this connection. “Computer 1 may be a client computer and computer 2 a
`
`destination computer, to which the secure messages are sent . . . .” Id., 8:51-55.
`
`“Computer 2 might be a security gateway for a third computer 3.” Id., 8:55-56.
`
`“The security gateway can be a common security gateway for e.g., a company
`
`LAN, whereby there are several computers in the LAN protected by computer 2.”
`
`Id., 8:57-60.
`
`- 12 -
`
`

`

`’581 patent, FIG. 1 (annotated).
`
`
`
`28. The ’581 patent explains that “an IPSec tunnel [is] established
`
`between computer 1 and computer 2.” Id., 8:52-55. Computer 1 may be associated
`
`with a first address “A.” When computer 1 moves from address A to address B,
`
`computer 1 sends a message to computer 2 requesting that computer 2 register the
`
`new address. See id., 8:57-8:63, 9:1-4, 9:60-9:66. In response to this request
`
`message, computer 2 updates the address corresponding to computer 1. “[The]
`
`existing IPSec tunnel end-point can be moved . . . from one point of attachment to
`
`another. For instance, an IPSec tunnel established between addresses A and X . . .
`
`can be changed by using the defined signaling to be between addresses B and X . .
`
`. .” Id., 7:28-35.
`
`- 13 -
`
`

`

`VI. Overview of the State of the Art at the Time of Filing
`29. The ’581 patent includes a lengthy Technical Background section
`
`describing the state of the art, context, and framework for its purported invention.
`
`This description describes the state of the art prior to the earliest priority date of the
`
`’581 patent. I discuss this background further below.
`
`A.
`
`Internet Protocol Security (IPSec) and Security Associations
`(SAs)
`
`30. As previously described, the ’581 patent explains the well-known
`
`Internet Protocol Security (IPsec) standard framework that “provides the capability
`
`to secure communications between arbitrary hosts, e.g., across a LAN, across
`
`private and public wide area networks (WANs).” ’581 patent, 1:59-62; see also Ex.
`
`1011, RFC2401, 51. “[A]cross the internet[,] IPSec can be used in different ways,
`
`such as for building secure virtual private networks, to gain a secure access to a
`
`company network, or to secure communication with other organisations, ensuring
`
`authentication and confidentiality and providing a key exchange mechanism.” ’581
`
`patent, 1:62-66; see also RFC2401, 25. In this manner, the ’581 patent
`
`acknowledges the well-known prior art configurations that include IPSec tunnel
`
`mode and mobile terminal communications with security gateways, such as
`
`firewalls or routers. ’581 patent, 2:43-53; see also RFC2401, 6, 25, 28.
`
`31. The ’581 patent further explains that the IPsec standard includes three
`
`major protocols: (1) authentication headers (AH); (2) encapsulating security
`
`- 14 -
`
`

`

`payloads (ESP); and (3) security associations (SA). See ’581 patent, 2:13-34; see
`
`also RFC2401, 6-13. “Both AH and ESP are vehicles for access control based on
`
`the distribution of cryptographic keys and the management of traffic flows related
`
`to these security protocols.” ’581 patent, 2:19-22; see also RFC2401, 6-7. “A
`
`security association [SA] is a one-way relationship between a sender and a receiver
`
`that offers security services to the traffic carried on it.” ’581 patent, 2:24-26. “SAs
`
`are bound to static addresses.” See id., 4:60-62. “[I]f a secure two way relationship
`
`is needed, then two security associations are required.” Id., 2:27-28. “[An] SA
`
`bundle is the combination of all SAs used to secure a packet.” Id., 2:33-34.
`
`32.
`
`“A security association is uniquely identified by three parameters. The
`
`first one, the Security Parameters Index (SPI), is a bit string [that] is carried in AH
`
`and ESP headers to enable the receiving system to select the SA under which a
`
`received packet will be processed. IP destination address is the second parameter,
`
`which is the address of the destination end point of the SA, which may be an end
`
`user system or a network system such as a firewall or a router. The third
`
`parameter, the security protocol identifier indicates whether the association is an
`
`AH or ESP security association.” Id., 2:43-53 (emphasis added); see also
`
`RFC2401, 8-9.
`
`- 15 -
`
`

`

`IPSec Transport Mode vs. Tunnel Mode
`
`B.
`33. The ’581 patent continues to describe the two well-known modes of
`
`operation for IPsec: “transport and tunnel mode.” ’581 patent, 3:10-11. “Typically,
`
`transport mode is used for end-to-end communication between two hosts.” Id.,
`
`3:14-15 (emphasis added); see also RFC2401, 9. In contrast, “[t]unnel mode is
`
`often used when one or both ends of a SA is a security gateway, such as a firewall
`
`or a router that implements IPSec.” ’581 patent, 3:22-24 (emphasis added), see
`
`also 2:9-12, 5:54-58, citing RFC2401; RFC2401, 9 (“A tunnel mode SA is
`
`essentially an SA applied to an IP tunnel. Whenever either end of a security
`
`association is a security gateway, the SA MUST be tunnel mode. Thus an SA
`
`between two security gateways is always a tunnel mode SA, as is an SA between a
`
`host and a security gateway.”). An article from the Internet Protocol Journal further
`
`describes the well-known operation of tunnel mode:
`
`The entire original, or inner, packet travels through a ‘tunnel’ from
`one point of an IP network to another; no routers along the way need
`to examine the inner IP header . . . Tunnel mode is used when one or
`both ends of an SA is a security gateway, such as a firewall or router
`that implements IPSec. With tunnel mode, a number of hosts on
`networks behind firewalls may engage in secure communications
`without implementing IPSec. The unprotected packets generated by
`such hosts are tunneled through external networks by tunnel mode
`SAs set up by the IPSec process in the firewall or secure router at the
`boundary of the local network.
`
`- 16 -
`
`

`

`Ex. 1009, Stallings, 14 (emphasis added).
`
`34. The book “Demystifying the IPSec Puzzle” by Sheila Frankel
`
`provides a visualization of three well-known scenarios using transport mode and
`
`tunnel mode. (See Ex. 1008, Frankel, 3, FIGs. 1.1(a)-1.1(c).)
`
`- 17 -
`
`

`

`Figure 1.1(a) Communication scenario 1: host-to-host.
`
`Network N1
`
`Host H1-1 Host H1-2
`
`Network N?
`
`
`
`
`Host H2-1 Host H2-2
`My
`
`
`
`
`
`$62
`
`Host H2-3
`
`Figure 1.1(b) Communication scenario 2: gateway-to-gateway.
`
`
`
`
`Host H?-1 Host H2-?
`
`Network N2
`
`Figure 1.1(c) Communication scenario 3: host-to-gateway.
`
`
`
`Frankel, FIGs. 1.1(a)-1.1(c).
`Frankel, FIGs. 1.1(a)-1.1(c).
`
`
`
`- 18 -
`-18 -
`
`

`

`35. As seen in Figure 1.1(a), “two hosts [are] communicating with each
`
`other.” Frankel, 3. As previously explained, the two hosts may form an IPsec SA
`
`connection using transport mode. See ’581 patent, 3:14-15. Figure 1.1(b) depicts a
`
`“small-scale VPN: two separate networks, each protected from the outside by a
`
`security gateway that screens all communications to and from its associated
`
`network.” Frankel, 3. As explained in the ’581 patent, “[t]unnel mode is often used
`
`when one or both ends of a SA is a security gateway,” so an IPSec SA connection
`
`using tunnel mode would likely exist between the two gateways depicted in Figure
`
`1.1(b). ’581 patent, 3:22-24; see also RFC2401, 9.
`
`36. Most relevant to the ’581 patent is Figure 1.1(c). In this figure, “a
`
`single host [is] communicating with another host that resides on a network
`
`protected by a security gateway. This commonly occurs when an employee dials
`
`into a business network from home or when on a business trip.” Frankel, 3. As
`
`explained in the ’581 patent, “[t]unnel mode is often used when one or both ends
`
`of a SA is a security gateway,” so an IPSec SA connection using tunnel mode
`
`would likely exist between the host and gateway depicted in Figure 1.1(c). ’581
`
`patent, 3:22-24; see also RFC2401, 9.
`
`C. The IPSec Mobility Problem
`37. Frankel further explains the same well-known problem described in
`
`the ’581 patent. The scenario depicted in Figure 1.1(c) “is complicated by the fact
`
`- 19 -
`
`

`

`that the single host, when dialing into the network, may not have a fixed network
`
`address.” Frankel, 3.
`
`38. The ’581 patent also describes this same “mobile terminal” problem
`
`because “IPSec is intended to work with static network topology, where hosts are
`
`fixed to certain subnetworks. For instance, when an IPsec tunnel has been formed
`
`by using Internet Key Exchange (IKE) protocol, the tunnel end-points are fixed
`
`and remain constant.” ’581 patent, 4:13-18; see also RFC2401, 25-26, 28. “A SA
`
`is bound to a certain IP address, and if it is changed, the existing IPSec SA
`
`becomes useless because it has been established by using different end-point
`
`address.” ’581 patent, 4:37-39. “If IPSec is used with a mobile host, the IKE key
`
`exchange will have to be redone from every new visited network.” Id., 4:19-21.
`
`This full re-negotiation could lead to inefficiencies and computationally expensive
`
`calculations. Id., 4:21-24. In this manner, the ’581 patent describes the same
`
`problems identified in Frankel and well-known in the art.
`
`39. The ’581 patent defines the term “mobility” as not only referring to a
`
`physical mobility of a mobile terminal but instead also referring to “moving from
`
`one network to another.” Id., 4:31-35. When the mobile terminal uses another
`
`network or IP address, the mobile terminal has “moved.” Id.
`
`- 20 -
`
`

`

`Prior Art Solutions to the IPSec Mobility Problem
`
`D.
`40. The ’581 patent acknowledges the well-known mobility issue was
`
`addressed in the prior art: “[t]he problem has been discussed in the IETF
`
`standardisation forum, www.IETF.org, wherein an idea to support mobility for
`
`IPSec ESP tunnels by means of signalling to update the address of one end after a
`
`movement was mentioned by Francis Dupont.” ’581 patent, 4:40-44; see also Ex.
`
`1010, Dupont, 3 (“The signaling function provides a way to update the care-of
`
`address in this pair on correspondent nodes when the mobile node has moved, ie.
`
`[sic] has acquired a new care-of address.”). As will be discussed below, the ’581
`
`patent adopts this well-known signaling solution to update the mobile node’s
`
`address. Simply put, the purported invention of the ’581 patent merely adopts a
`
`well-known technique from among many prior-art techniques already known to
`
`POSITAs at the time of the ’581 patent’s invention.
`
`41. One known method of addressing the IPSec mobility issue described
`
`above was to establish multiple SAs corresponding to networks visited by a mobile
`
`terminal. See, e.g., Ex. 1006, Ahonen, 4:10-13; Ex. 1013, Akhtar, 23:60-67, 24:47-
`
`59, FIG. 8; Ex. 1014, Patil, 6:44-8:10. Then, when a mobile host moves to a
`
`particular network, the corresponding SA created for that network is used for the
`
`connection. See Ahonen, 9:7-10; Akhtar, 32:42-45, 32:50-55, 34:16-20. For
`
`example, Ahonen describes establishing pre-existing SAs that are activated based
`
`- 21 -
`
`

`

`on the network the mobile host is visiting: “The remote control function is used by
`
`the mobile host 1 to remotely ‘activate’ preexisting secure connections to the
`
`correspondent host 4.” Ahonen, 9:8-10 (emphasis added). Similarly, Akhtar
`
`describes establishing multiple SAs between multiple addresses as seen in Figure 9
`
`below.
`
`Akhtar, FIG. 9.
`
`
`
`42.
`
`In this manner, the prior art describes a solution to the IPSec mobility
`
`problem via the use of multiple pre-established security associations and the