`
`
`
`
`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
`U.S. Patent No. 7,620,810
`
`
`
`
`
`
`
`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-00819
`
`

`

`
`
`TABLE OF CONTENTS
`
`
`I. 
`Qualifications ................................................................................................... 4 
`II.  My Understanding of Claim Construction ...................................................... 7 
`III.  My Understanding of Obviousness ................................................................. 7 
`IV.  Level of Ordinary Skill in the Art ................................................................... 9 
`V.  Overview of the ’810 Patent .......................................................................... 10 
`VI.  Overview of the State of the Art at the Time of Filing ................................. 14 
`A. 
`Internet Protocol Security (IPSec) and Security Associations (SAs) . 14 
`B. 
`IPSec Transport Mode vs. Tunnel Mode ............................................ 15 
`C. 
`The IPSec Mobility Problem ............................................................... 19 
`D. 
`Prior Art Solutions to the IPSec Mobility Problem ............................ 21 
`VII.  Claims 1, 4-5, and 7 are Obvious over Ishiyama and Murakawa. ................ 24 
`A.  Overview of Ishiyama ......................................................................... 24 
`B. 
`Overview of the Combination of Ishiyama and Murakawa ................ 30 
`C. 
`The Combination of Ishiyama and Murakawa Renders Claim 1
`Obvious. .............................................................................................. 34 
`1. 
`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
`between a first address of the mobile terminal and an address of
`the security gateway, the secure connection defined by at least
`the addresses of the mobile terminal and the security gateway,”
`[1A]. .......................................................................................... 40 
`Ishiyama discloses “b) the mobile terminal changing from the
`first address to a second address,” [1B]. ................................... 44 
`Ishiyama discloses “c) while at the second address, the mobile
`terminal sending a request message to the address of the
`security gateway to request the security gateway to change the
`secure connection to be defined between the second address and
`the address of the security gateway,” [1C]. .............................. 45 
`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]. .............................................................. 48 
`
`2. 
`
`3. 
`
`4. 
`
`5. 
`
`
`
`- i -
`
`

`

`6. 
`
`7. 
`
`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 
`Ishiyama discloses “the secure connection being established by
`forming a Security Association (SA) using IPSec protocols, and
`the request message and/or a reply message being encrypted
`and/or authenticated by using the same SA already established.”
`[1F]. ........................................................................................... 56 
`The Combination of Ishiyama and Murakawa Renders Claim 7
`Obvious. .............................................................................................. 58 
`The Combination of Ishiyama and Murakawa Renders Claim 4
`Obvious. .............................................................................................. 66 
`The Combination of Ishiyama and Murakawa Renders Claim 5
`Obvious. .............................................................................................. 72 
`VIII.  Claims 2 and 3 are Obvious over Ishiyama, Murakawa, and Ahonen. ......... 73 
`A.  Overview of the Combination of Ishiyama, Murakawa, and Ahonen 73 
`B. 
`The Combination of Ishiyama, Murakawa, and Ahonen Renders
`Claims 2 and 3 Obvious. ..................................................................... 78 
`IX.  Claim 6 is Obvious over Ishiyama, Murakawa, and Forslöw. ...................... 81 
`X. 
`Conclusion ..................................................................................................... 85 
`
`
`D. 
`
`E. 
`
`F. 
`
`
`
`- ii -
`
`

`

`
`
`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 that this proceeding involves U.S.
`
`Patent No. 7,620,810 (“’810 patent”), titled “Method and Network For Ensuring
`
`Secure Forwarding of Messages,” and that the ’810 patent is currently assigned to
`
`Mobility Patent Holding MPH Oy.
`
`2.
`
`I have reviewed and am familiar with the specification of the ’810
`
`patent issued on November 17, 2009. I understand that the ’810 patent has been
`
`provided as Ex. 1001. I will cite to the specification using the following format:
`
`Ex. 1001, ’810 patent, 1:1-10. This example citation points to the ’810 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 ’810 patent:
`
` File Wrapper for U.S. Patent No. 7,620,810. I understand that the ’810
`
`patent file wrapper has been provided as Ex. 1003.
`
` 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 ’810 patent. I understand that Ishiyama has been provided as Ex.
`
`1004.
`
`
`
`- 1 -
`
`

`

` 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 ’810 patent. I understand that Murakawa
`
`has been provided as Ex. 1005.
`
` U.S. Patent No. 6,976,177 to Ahonen was filed on January 18, 2001
`
`and published on July 19, 2001, both dates being more than one year
`
`before the earliest priority date of the ’810 patent. I understand that
`
`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 ’810
`
`patent. I understand that 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.
`
`
`
`- 2 -
`
`

`

` RFC2401 - S. Kent, and R. Atkinson, Security Architecture for the
`
`Internet Protocol, RFC2401, November 1998. I understand RFC2401
`
`has been provided as Ex. 1011.
`
` RFC793 – Information Sciences Institute, University of Southern
`
`California, Transmission Control Protocol, RFC793, 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, being more than one year before the earliest priority date of the
`
`’810 patent. I understand that 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,
`
`being more than one year before the earliest priority date of the ’810
`
`patent. I understand that Patil has been provided as Ex. 1014.
`
` U.S. Patent No. 6,418,130 to Cheng et al. was filed on January 21,
`
`1999, being more than one year before the earliest priority date of the
`
`’810 patent. I understand that Cheng has been provided as Ex. 1015.
`
` The Inter Partes Review Petition filed in this case.
`
`
`
`5.
`
`I am familiar with the technology described in the ’810 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 ’810 patent. I
`
`have used this experience and insight along with the above-noted references as the
`
`basis for my opinions that support the grounds of unpatentability set forth in the
`
`Petition for Inter Partes Review of the ’810 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:
`
`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, I 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
`
`
`
`- 4 -
`
`

`

`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, including functionality, security, and safety.
`
`8.
`
`I have conducted significant research and published numerous papers
`
`in the field of computer security. For example, I have published 34 papers in this
`
`field, 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 several papers on Onion Routing. Onion Routing, now called Tor, is a system
`
`for privacy and anonymity on the internet. I and my co-inventors for Onion
`
`Routing, were awarded the Alan S. Berman Award at the Naval Research
`
`Laboratory in 1999.
`
`9. My research and work has resulted in my being a joint inventor on 12
`
`issued patents related to computer security, including one patent on Onion Routing,
`
`as well as 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
`
`
`
`- 5 -
`
`

`

`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 timeframe for assessing the validity of the ’810 patent, more
`
`than qualify me as a person of ordinary skill in the art for the ’810 patent at the
`
`relevant time. In addition, I worked with people who possessed the same
`
`experience as a person of ordinary skill in the art. From my personal experience
`
`working on computer security solutions as well as through my interaction with
`
`others, I understand the types of problems and the knowledge that a person of
`
`ordinary skill in the art would have confronted and known at the relevant time.
`
`11.
`
`I have continued my work in computer security after the relevant
`
`timeframe for assessing the validity of the ’810 patent as well, from 1999 to the
`
`present. I have held several top-level executive positions 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 of
`
`
`
`- 6 -
`
`

`

`the art of the ’810 patent that is well beyond the level of knowledge and skill of a
`
`person of ordinary skill in the art at the time of the filing of the ’810 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
`
`“POSITA”).
`
`III. My Understanding of Obviousness
`
`14.
`
`I understand that 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
`
`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
`
`
`
`- 7 -
`
`

`

`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 that 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 that 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, render the patent obvious; (2) specifically identify
`
`which elements of the patent claim appear in each of the asserted references; and
`
`(3) explain how the prior art references could have been combined in order to
`
`create the inventions claimed in the asserted claim.
`
`18.
`
`I understand that 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
`
`
`
`- 8 -
`
`

`

`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; the taking of licenses under the patent by others;
`
`(7) expressions of surprise by experts and those skilled in the art at the making of
`
`the invention; and (8) 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
`
`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 factual analysis that would support a
`
`legal conclusion of obviousness or non-obviousness, and when I use the term
`
`obvious, I am referring 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 disclosure of the ’810 patent, a person of ordinary skill
`
`in the art (POSITA) would have had a Bachelor’s degree in Electrical Engineering,
`
`Computer Engineering, Computer Science, or an equivalent field, as well as at
`
`
`
`- 9 -
`
`

`

`least 2-5 years of academic or industry experience in the computer network
`
`security industry.
`
`21. By equivalent field, I mean that the required levels of educational and
`
`industry experience are on a sliding scale relative to each other. For example, a
`
`person of ordinary skill could have a more advanced educational degree with less
`
`industry experience.
`
`V. Overview of the ’810 Patent
`
`22. The ’810 patent relates to a method and network that securely
`
`forwards messages in a telecommunication network. Ex. 1001,’810 patent,
`
`Abstract. In particular, the ’810 patent describes facilitating communications
`
`received from a mobile host using the IPSec protocol. Id., 6:65-7:6. “The IP
`
`Security protocols (IPSec) provides the capability to secure communications
`
`between arbitrary hosts” using negotiated encryption keys Id., 1:57-58. These
`
`encryption keys are typically negotiated in an automated fashion using a protocol
`
`known as “Internet Key Exchange” or IKE. Id., 4:3-5.
`
`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:9-13.
`
`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:47-58. Therefore, conventionally, when a mobile
`
`
`
`- 10 -
`
`

`

`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:15-18.
`
`24.
`
`“This
`
`is problematic, because
`
`IKE key exchanges
`
`involve
`
`computationally expensive…calculations.” Id., 4:15-18. 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:40-46. The ’810 patent
`
`identifies this known issue of a moving mobile terminal in a telecommunication
`
`network with IPSec. Id., 4:15-18. In particular, the ’810 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:12-15, 9:40-43.
`
`25. To avoid this “full re-negotiation,” the ’810 patent’s states that its
`
`solution is to simply require the mobile terminal to send a notification to update the
`
`SA with the new address. Id., Abstract. The ’810 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:29-45. In this manner,
`
`the ’810 patent proposes that 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:20-23.
`
`26. To illustrate this operation, the ’810 patent describes the movement of
`
`a mobile terminal from a first address to a second address while the mobile
`
`
`
`- 11 -
`
`

`

`terminal is communicating with an “other terminal.” Id., Abstract. The ’810 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 the 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. (emphasis added).
`
`27. The ’810 patent describes an embodiment of this communication
`
`process using a “security gateway.” See id., 8:53-64. 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:54-58.
`
`“Computer 2 might be a security gateway for a third computer 3.” Id., 8:58-59.
`
`“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:60-63.
`
`
`
`- 12 -
`
`

`

`’810 patent, FIG. 1 (annotated).
`
`
`28. The ’810 patent explains that “an IPSec tunnel [is] established
`
`
`
`between computer 1 and computer 2.” Id., 8:57-58. 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:60-9:7, 9:14-19, 9:63-10:2. In response to this request
`
`message, computer 2 updates the address corresponding to computer 1. “[The]
`
`existing IPSec tunnel endpoint can be moved…from one [end] 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:29-37.
`
`
`
`- 13 -
`
`

`

`VI. Overview of the State of the Art at the Time of Filing
`29. The ’810 patent includes a lengthy Technical Background section
`
`describing the state of the art, context, and framework for its purported invention. I
`
`discuss this background further below.
`
`A.
`
`Internet Protocol Security (IPSec) and Security Associations
`(SAs)
`30. As previously described, the ’810 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)….” Id., 1:57-59; 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.” ’810
`
`patent, 1:60-64; see also RFC2401, 25. In this manner, the ’810 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. ’810 patent, 2:41-51; see also RFC2401, 6, 25, 28.
`
`31. The ’810 patent further explains that the IPsec standard includes three
`
`major protocols: (1) authentication headers (AH); (2) encapsulating security
`
`payloads (ESP); and (3) security associations (SA). See ’810 patent, 2:11-32; see
`
`
`
`- 14 -
`
`

`

`also RFC2401, 6-12. “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.” ’810 patent, 2:17-20; 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.” ’810 patent, 2:22-24. “SAs
`
`are bound to static addresses.” See id., 4:47-58. “[I]f a secure two way relationship
`
`is needed, then two security associations are required.” Id., 2:25-26. “[An] SA
`
`bundle is the combination of all SAs used to secure a packet.” Id., 2:31-32.
`
`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:41-51; see also RFC2401, 8-9. (emphasis
`
`added).
`
`B.
`IPSec Transport Mode vs. Tunnel Mode
`33. The ’810 patent continues to describe the two well-known modes of
`
`operation for IPsec: “transport and tunnel mode.” ’810 patent, 3:8-9. “Typically,
`
`
`
`- 15 -
`
`

`

`transport mode is used for end-to-end communication between two hosts.” Id.,
`
`3:12-13; see also RFC2401, 9. (emphasis added). 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.” ’810 patent, 3:19-21 (emphasis added); see
`
`also 2:6-10, 5:59-62, citing 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.
`RFC2401, 9. 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.
`
`Ex. 1009, Stallings, 0014. (emphasis added).
`
`
`
`
`- 16 -
`
`

`

`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 N2
`
`
`
`
`Host H2-1 Host H2-2
`M
`
`
`
`
`
`$62
`
`Host H2-3
`
`Figure 1.1(b) Communication scenario 2: gateway-to-gateway.
`
`
`
`
`Host H?-1 Host H2-2
`
`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 ’810 patent, 3:12-13. 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 ’810 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). ’810 patent, 3:19-21.
`
`36. Most relevant to the ’810 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 ’810 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). ’810
`
`patent, 3:19-21; see also RFC2401, 9.
`
`C. The IPSec Mobility Problem
`37. Frankel further explains the same well-known problem described in
`
`the ’810 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 ’810 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 endpoints are fixed and
`
`remain constant.” ’810 patent, 4:10-15; 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 endpoint addresses.”
`
`’810 patent, 4:33-35. “If IPSec is used with a mobile host[,] the IKE key exchange
`
`will have to be redone from every new visited network.” Id., 4:15-17. This full re-
`
`negotiation could
`
`lead
`
`to
`
`inefficiencies and computationally expensive
`
`calculations. Id. In this manner, the ’810 patent describes the same problems
`
`identified in Frankel and well-known in the art.
`
`39. The ’810 patent defines the term “mobility” as not only referring to a
`
`physical mobility of a mobile terminal but instead also referring to the “moving
`
`from one network to another….” Id., 4:27-29. When the mobile terminal uses
`
`another network or IP address, the mobile terminal has “moved.” Id.
`
`
`
`- 20 -
`
`

`

`D.
`Prior Art Solutions to the IPSec Mobility Problem
`40. The ’810 patent acknowledges that the well-known mobility issue was
`
`addressed in the prior art: “[t]he problem has been discussed in the IETF
`
`standardization forum, www.IETF.org, wherein an idea to support mobility for
`
`IPSec ESP tunnels by means of signaling to update the address of one end after a
`
`movement was mentioned by Francis Dupont.” ’810 patent, 4:36-40; see also Ex.
`
`1010, Dupont, 3, “Signaling” (“The signaling function provides a way to update
`
`the care-of address in this pair on correspondent nodes when the mobile node has
`
`moved, i.e. has acquired a new care-of address.”) As will be discussed below, the
`
`’810 patent adopts this well-known signaling solution to update the mobile node’s
`
`address. Simply put, the purported invention of the ’810 patent merely adopts a
`
`well-known technique from among many prior-art techniques already known to
`
`POSITAs at the time of the ’810 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 from
`
`Figure 9 below.
`
`Ex. 1013, Akhtar, FIG. 9.
`
`In this manner, the prior art de