`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`APPLE INC.,
`Petitioner
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner
`
`
`
`Case IPR2019-00825
`U.S. Patent No. 9,762,397
`
`
`
`
`
`
`
`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-00825
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`TABLE OF CONTENTS
`
`
`I. Background and Qualifications ........................................................................... 4
`II. Legal Understanding ........................................................................................... 7
`A. My Understanding of Claim Construction ...................................................... 7
`B. My Understanding of Obviousness ................................................................. 7
`C. Level of Skill in the Art .................................................................................10
`III. Overview of the State of the Art at the Time of Filing .....................................11
`A. Internet Protocol Security (IPSec) .................................................................11
`B. The Internet Key Exchange (IKE) .................................................................15
`C. IPSec and Network Address Translation (NAT) ...........................................16
`IV. Overview of the ’397 Patent .............................................................................18
`V. Claim Construction ...........................................................................................22
`A. “secure connection” .......................................................................................23
`B. “unique identity” ............................................................................................24
`VI. The Combination of RFC3104 and Grabelsky Renders Claims 1 and 2
`obvious. ....................................................................................................................25
`A. Brief Overview of RFC3104 .........................................................................25
`B. The Combination of RFC3104 and Grabelsky ..............................................29
`C. Claim 1 ...........................................................................................................35
`D. Claim 2 ...........................................................................................................51
`VII. Conclusion .........................................................................................................52
`
`
`
`
`
`
`
`
`- i -
`
`
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`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. 9,762,397 (“the ’397 patent”), titled “Method and System for Sending a
`
`Message Through a Secure Connection,” and that the ’397 patent is currently
`
`assigned to MPH Technologies OY.
`
`2.
`
`I am over 18 years of age. I have personal knowledge of the facts
`
`stated in this Declaration and could testify competently to them if asked to do so.
`
`3.
`
`I have reviewed and am familiar with the specification of the ’397
`
`patent issued on September 12, 2017. I understand that the ’397 patent has been
`
`provided as Ex. 1001. I will cite to the specification using the following format:
`
`’397 patent, 1:1-10. This example citation points to the ’397 patent specification at
`
`column 1, lines 1-10.
`
`4.
`
`I have also reviewed and am familiar with the following documents
`
`and materials:
`
`• “RFC 3104: RSIP Support for End-to-end IPsec,” by Gabriel
`
`Montenegro and Michael Borella (“RFC3104”). I understand that
`
`RFC3104 has been provided as Ex. 1004.
`
`• U.S. Patent No. 7,032,242 to Grabelsky et al. (“Grabelsky”). I
`
`understand that Grabelsky has been provided as Ex. 1005.
`
`
`
`- 1 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`• “RFC 2401: Security Architecture for the Internet Protocol,” by
`
`Stephen Kent and Randall Atkinson (“RFC2401”). I understand that
`
`RFC2401 has been provided as Ex. 1015.
`
`• “RFC 2402: IP Authentication Header,” by Stephen Kent and Randall
`
`Atkinson (“RFC2402”). I understand that RFC2402 has been provided
`
`as Ex. 1016.
`
`• “RFC 2406: IP Encapsulating Security Payload (ESP),” by Stephen
`
`Kent and Randall Atkinson (“RFC2406”). I understand that RFC2406
`
`has been provided as Ex. 1017.
`
`• “RFC 2409: The Internet Key Exchange (IKE),” by Dan Harkins and
`
`Dave Carrel (“RFC2409”). I understand that RFC2409 has been
`
`provided as Ex. 1018.
`
`• “RFC 3102: Realm Specific IP: Framework,” by Michael Borella et
`
`al. (“RFC3102”). I understand that RFC3102 has been provided as
`
`Ex. 1019.
`
`• Sheila Frankel, Demystifying
`
`the IPsec Puzzle (“Frankel”). I
`
`understand that Frankel has been provided as Ex. 1011.
`
`• Prosecution history of the ’397 patent. I understand that the
`
`prosecution history has been provided as Ex. 1003.
`
`
`
`- 2 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`
`• All other exhibits cited herein.
`
`5.
`
`To the best of my knowledge, the above-mentioned documents and
`
`materials are true and accurate copies of what they purport to be. An expert in the
`
`field would reasonably rely on them to formulate opinions such as those set forth
`
`in this declaration.
`
`6.
`
`I am familiar with the Request for Comments (RFC) process based on
`
`my experience. As Ms. Sandy Ginoza explains, RFC2401, RFC2402, RFC2406,
`
`and RFC2409 were indexed and made publicly available no later than November
`
`1998. Ex. 1007, Ginoza Decl., ¶11. RFC3102 and RFC3104 were indexed and
`
`made publicly available no later than October 2001 as stated by Ms. Ginoza and
`
`confirmed in the IETF data tracker. Id., ¶12; Ex. 1012, IETF Data Tracker, 0001,
`
`0003.
`
`7.
`
`RFCs (“requests for comment”) are the end result of a public drafting
`
`process that begins with the posting of one or more “Internet Drafts” (ID). All IDs
`
`are posted and archived for public access and comment in order to solicit input
`
`from the interested community before taking further action. Based on my
`
`experience in the field, an interested person, including a POSITA, would have had
`
`access to, and would have been able to locate the RFCs noted above as of the dates
`
`they were indexed and made available to the public. For example, as indicated in
`
`“The Internet Standards Process -- Revision 3” (RFC2026), published in October
`
`
`
`- 3 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`1996, “RFCs can be obtained from a number of Internet hosts using anonymous
`
`FTP, gopher, World Wide Web, and other Internet document-retrieval systems.”
`
`Ex. 1013, RFC2026, 6.
`
`8.
`
`I am familiar with the technology described in the ’397 patent as of its
`
`earliest possible priority date of January 22, 2002. I have been asked to provide my
`
`technical review, analysis, insights, and opinions regarding the ’397 patent. I have
`
`used this experience and insight along with the above-noted references as the basis
`
`for the grounds of unpatentability set forth in the Petition for Inter Partes Review
`
`of the ’397 Patent.
`
`I.
`
`Background and Qualifications
`
`9. My qualifications are stated more fully in my curriculum vitae,
`
`attached as Exhibit 1008. Here, I provide a brief summary of my qualifications:
`
`10.
`
`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
`
`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.
`
`
`
`- 4 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`I have conducted significant research and published numerous papers
`
`11.
`
`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.
`
`12. 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.
`
`13. 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
`
`
`
`- 5 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`applications. It was at the Naval Research Laboratory that I co-invented Onion
`
`Routing.
`
`14. 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.
`
`15. These positions, along with my education, all of which were
`
`completed before the relevant timeframe for assessing the validity of the ’397
`
`patent, more than qualify me as a person of ordinary skill in the art for the ’397
`
`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.
`
`16.
`
`I have continued my work in computer security after the relevant
`
`timeframe for assessing the validity of the ’397 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.
`
`
`
`- 6 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`In view of my education and experience both before and after the
`
`17.
`
`relevant time, I am an expert in computer security, with knowledge and skill of the
`
`art of the ’397 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 ’397 patent.
`
`18. My curriculum vitae is provided as Exhibit 1008, which contains
`
`further details on my education, experience, publications, and other qualifications
`
`to render an expert opinion. 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. Legal Understanding
`
`A. My Understanding of Claim Construction
`I understand that, before the PTAB, claims are to be given their
`19.
`
`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”).
`
`B. My Understanding of Obviousness
`I understand that a patent claim is invalid if the claimed invention
`20.
`
`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 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`cannot be found in a single prior art reference that would anticipate the claim, the
`
`claim can still be invalid.
`
`21. 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.
`
`22. 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.
`
`23.
`
`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, make the patent obvious; (2) specifically identify
`
`which elements of the patent claim appear in each of the asserted references; and
`
`
`
`- 8 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`(3) explain how the prior art references could have been combined in order to
`
`create the inventions claimed in the asserted claim.
`
`24.
`
`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
`
`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.
`
`25.
`
`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
`
`
`
`- 9 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`obvious, I am referring to the perspective of one of ordinary skill at the time of
`
`invention.
`
`C. Level of Skill in the Art
`I understand that a person of ordinary skill in the relevant art is
`26.
`
`presumed to be aware of all pertinent art, thinks along conventional wisdom in the
`
`art, and is a person of ordinary creativity—not an automaton.
`
`27.
`
`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.
`
`28. My opinion below explains how a person of ordinary skill in the art
`
`would have understood the technology described in the references I have identified
`
`herein around the January 2002 timeframe.
`
`29. Based on the disclosure of the ’397 patent, a person of ordinary skill
`
`in the art (POSITA) would have a Bachelor’s degree in Electrical Engineering,
`
`Computer Engineering, Computer Science, or equivalent field as well as at least 2-
`
`5 years of academic or industry experience in the field of Internet security.
`
`
`
`- 10 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`30. By equivalent field, I mean that the required levels of educational and
`
`industry experience is on a sliding scale relative to each other. For example, a
`
`POSITA could have a more advanced educational degree with less industry
`
`experience.
`
`31. Regardless of whether I use “I” or a “POSITA” during my technical
`
`analysis below, all of my statements and opinions are always to be understood to
`
`be based on how a POSITA would have understood or read a document.
`
`III. Overview of the State of the Art at the Time of Filing
`
`32. The ’397 patent includes a lengthy Technical Background section
`
`describing the state of the art at the time of filing, context, and framework for its
`
`purported invention. I discuss this background in detail below.
`
`A.
`33.
`
`Internet Protocol Security (IPSec)
`
`Internet Protocol Security (IPSec) is a well-known standard that
`
`“provides the capability to secure communications between arbitrary hosts, e.g.
`
`across a LAN, across private and public wide area networks (WANs)….” Ex.
`
`1001, ’397 patent, 1:50-57; see also Ex. 1015, RFC2401, 51. IPSec is frequently
`
`used to implement Virtual Private Networks (VPNs) as well as to implement local
`
`encryption services in high-security computer networks. Indeed, the ’397 patent
`
`explains that “across 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
`
`
`
`- 11 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`to secure communication with other organisations, ensuring
`
`network, or
`
`authentication and confidentiality and providing a key exchange mechanism.” ’397
`
`patent, 1:50-57; see also RFC2401, 25.
`
`34. Two IPSec security services are typically used to secure data: “an
`
`authentication protocol designated by the header of the protocol, Authentication
`
`Header (AH), and a combined encryption/authentication protocol designated by the
`
`format of the packet for that protocol, Encapsulating Security Payload (ESP).”
`
`’397 patent, 2:5-11. The AH service is designed to provide authentication for data
`
`transmitted over the internet; protecting it from being altered by intermediate
`
`parties. The ESP service can provide data confidentiality as well as authentication,
`
`by encrypting data packets sent over the Internet. Both protocols make use of
`
`shared cryptographic keys (e.g., essentially long numbers) that must be agreed
`
`upon, and typically kept secret, by the endpoints. Both AH and ESP are similar in
`
`implementation in the sense that both operate by adding an appropriate AH or ESP
`
`protocol header to a data packet. Id.; Ex. 1016, RFC2402, 3-5; Ex. 1017,
`
`RFC2406, 3-7. “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.” ’397 patent, 2:11-14.
`
`35. The ’397 patent further explains that “a key concept” of IPSec is a
`
`security association (SA): “A security association is a one-way relationship
`
`
`
`- 12 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`between a sender and a receiver that offers security services to the traffic carried on
`
`it[;] if a secure two-way relationship is needed, then two security associations are
`
`required,” which together is commonly referred to as an “SA bundle.” Id., 2:16-20.
`
`These Security Associations effectively serve as a means for IPsec endpoints to
`
`record and recall the specific security services that are being used for a logical
`
`connection to another host. This information is necessary in order for a host to
`
`determine the correct encryption transforms that must be applied to each incoming
`
`or outgoing data packet.
`
`36. To implement this notion, each host must be capable of uniquely
`
`identifying the correct SA required to process a data packet. The ’397 patent
`
`discloses that “[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:35-45; see also RFC2401, 8.
`
`37. The ’397 patent describes that IPSec services support two modes:
`
`“transport mode” and “tunnel mode.” ’397 patent, 3:2-3; see also RFC2401, 9.
`
`
`
`- 13 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`Transport mode is designed to support encryption of individual packets traveling
`
`directly from a sending host to a destination host. In transport mode, the AH or
`
`ESP headers protect the data payload in each packet, but do not protect the packet
`
`header. In tunneling mode, packets that may originate at other hosts are
`
`“encapsulated” by adding a second AH or ESP header to the front of the packet.
`
`This changes the form of the underlying packet so that it may be routed over a
`
`network connection intact; the added header is removed when the packet reaches
`
`the tunnel end, and it can then be sent on to its destination. As a secondary benefit,
`
`tunnel mode provides additional security protection for the original packet header.
`
`As with most network protocols, the two modes may be used simultaneously (e.g.,
`
`by securing packets with both transport and tunnel modes), and may be combined
`
`with other security protocols such as SSL.
`
`38. This standard approach is reiterated in the ’397 patent: “Transport
`
`mode provides protection primarily for upper layer protocols and extends to the
`
`payload of an IP packet,” while “Tunnel mode provides protection to the entire IP
`
`packet.” ’397 patent, 3:10-20. While “Transport mode may be used in conjunction
`
`with a tunnelling protocol, other than IPSec tunnelling,” “[t]unnel mode is often
`
`used when one or both ends of a SA is a security gateway, such as a firewall or
`
`router that implements IPSec.” Id., 3:13-23. The ’397 patent does not alter these
`
`
`
`- 14 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`standard modes and uses them in substantially the same way as the prior art, such
`
`as RFC3104 and Grabelsky, as I discuss further below.
`
`The Internet Key Exchange (IKE)
`
`B.
`39. The ’397 patent explains that the “default automated key management
`
`protocol for IPSec is referred to as ISAKMP/Oakley,” and “Internet key exchange
`
`(IKE) is a newer name for the ISAKMP/Oakley protocol.” ’397 patent, 4:2-7; see
`
`also RFC2401, 27. IKE is an automated key exchange protocol that uses
`
`techniques including public-key cryptography to derive shared cryptographic key
`
`material and SPI values between pairs of hosts.1 IKE is commonly used in
`
`conjunction with IPSec “to negotiate, and provide authenticated keying material
`
`for, security associations in a protected manner.” Ex. 1018, RFC2409, 2. In this
`
`manner, IKE can be used to establish the IPSec SA over which endpoints will
`
`communicate.
`
`40.
`
`IKE typically involves two phases: “Phase 1 is where the two
`
`ISAKMP peers establish a secure, authenticated channel with which to
`
`
`1 The IKE protocol referenced in RFC2401 is now commonly referred to as
`
`“IKE version 1”, or IKEv1. A later version, called “IKE version 2” is defined in
`
`RFC5996 and post-dates the earliest priority date of the ’397 patent by several
`
`years. This document will use the term IKE exclusively to refer to IKEv1.
`
`
`
`- 15 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`communicate. This is called the ISAKMP Security Association (SA). ‘Main Mode’
`
`and ‘Aggressive Mode’ each accomplish a phase 1 exchange. ‘Main Mode’ and
`
`‘Aggressive Mode’ MUST ONLY be used in phase 1. Phase 2 is where Security
`
`Associations are negotiated on behalf of services such as IPsec or any other service
`
`which needs key material and/or parameter negotiation. ‘Quick Mode’
`
`accomplishes a phase 2 exchange. ‘Quick Mode’ MUST ONLY be used in phase
`
`2.” Id., 5; see also Ex. 1011, Frankel, 87-88.
`
`41. Once the ISAKMP SA is established in phase 1 of IKE, “either party
`
`may initiate Quick Mode,” and “the ISAKMP SA is identified by the Initiator’s
`
`cookie followed by the Responder’s cookie.” RFC2409, 6; see also Frankel, 93-94.
`
`In Quick Mode, “all payloads except the ISAKMP header are encrypted.”
`
`RFC2409, 16. After phases 1 and 2 of the IKE process are complete, an IPSec SA
`
`has been negotiated, including generating all necessary key material. See, e.g., id.,
`
`23; Frankel, 99-100.
`
`IPSec and Network Address Translation (NAT)
`
`C.
`42. Network Address Translation (NAT) enables the separation of
`
`addressing spaces, for example a public domain and a private domain (e.g., an
`
`enterprise or home network). Ex. 1019, RFC3102, 2. This process generally
`
`employs a NAT router to route packets between the two different addressing
`
`spaces. Id. However, typically a “NAT router must examine and change the
`
`
`
`- 16 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`network layer, and possibly the transport layer, header of each packet crossing the
`
`addressing domains that the NAT router is connecting,” which “causes the
`
`mechanism of NAT to violate the end-to-end nature of the Internet connectivity.”
`
`Id, emphasis added. One benefit of NAT is that it enables many more devices to
`
`use the Internet than would be supported due to the limited number of IP addresses
`
`available. For this and other reasons, it has been widely used since well before the
`
`priority date of the ’397 patent.
`
`43. Consistent with this operation, the ’397 patent alleges that “[s]tandard
`
`IPSec does e.g. not work through NAT devices at the moment,” and that “current
`
`IPSec NAT traversal protocols are not well suited to mobility.” ’397 patent, 4:66-
`
`5:4. While the ’397 patent purports that these issues can already be solved by
`
`establishing separate tunnels or IPSec connections between each end host and the
`
`NAT device (i.e., an “intermediate host” between end device), the patent contends
`
`that this adds packet overhead and potentially exposes sensitive data at the NAT
`
`device. Id., 5:38-52, 5:65-6:8.
`
`44. But references such as RFC3104 (which is an extension of RFC3102)
`
`and Grabelsky addressed these issues head on before the ’397 patent, as I discuss
`
`further throughout this document. For example, Grabelsky similarly acknowledges
`
`that “Network address translation interferes with the end-to-end routing principle
`
`of the Internet that recommends that packets flow end-to-end between network
`
`
`
`- 17 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`devices…” Ex. 1005, Grabelsky, 1:62-67. As such, Grabelsky provides techniques
`
`for “end-to-end security [] between two endpoints across an IP [] network.” Id.,
`
`24:5-8. RFC3104, titled “RSIP Support for End-to-end IPsec,” similarly discloses
`
`establishing an IPSec SA end-to-end between two end hosts, through an
`
`intermediate server. Ex. 1004, RFC3104, 1, 5. Thus, a POSITA would have
`
`recognized that the problems and alleged solution presented by the ’397 patent
`
`were not new, and many similar solutions already existed.
`
`IV. Overview of the ’397 Patent
`
`45. The ’397 patent is directed to general techniques for “secure
`
`forwarding of a message from a first computer to a second computer.” ’397 patent,
`
`Abstract. The ’397 patent includes a lengthy technical background discussing “a
`
`need to protect data and resources from disclosure, to guarantee the authenticity of
`
`data, and to protect systems from network based attacks.” Id., 1:34-36. The ’397
`
`patent primarily discusses these concerns in terms of a “mobile host,” where the
`
`term “mobile” not only refers to physical mobility, but rather to “moving from one
`
`network to another, which can be performed by a physically fixed terminal as
`
`well.” Id., 4:30-34.
`
`46. The ’397 patent acknowledges that “IP security protocols (IPSec)
`
`provides the capability to secure communications between arbitrary hosts,” but
`
`“[t]he problem with standard IPSec is [] that it has been designed for static
`
`
`
`- 18 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`connections.” Id., 1:50-58; 4:35-36. Thus, when a host is mobile, the patent alleges
`
`that IPSec provides no mechanism to alter parameters of the secure connection. Id.,
`
`4:37-39. Because of this, the patent alleges that existing solutions employing IPSec
`
`“either employ extra tunnelling, causing extra packet size overhead, or use separate
`
`tunnels, causing potential security problems in the intermediate host(s) that
`
`terminate such tunnels.” Id., 6:15-19. However, numerous solutions already existed
`
`in the prior art that addressed these alleged problems in substantially the same way
`
`as the ’397 patent, for example using standard IPSec protocol to establish a single
`
`secure connection.
`
`47. The ’397 patent’s purported solution involves “a method for
`
`forwarding secure messages between
`
`two computers, especially, via an
`
`intermediate computer.” Id., 6:22-25. The ’397 patent illustrates an example
`
`telecommunication network in Figure 1, which I have reproduced below and
`
`highlighted for clarity.
`
`
`
`- 19 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`
`’397 patent, FIG. 1 (annotated).
`
`
`
`48. The example network includes “a first computer, here a client
`
`computer 1 served by an intermediate computer, here as a server 2, and a host
`
`computer 4, that is served by the second computer, here a security gateway (SGW)
`
`3.” Id., 9:65-10:3. Server 2 acts as the intermediate computer between client
`
`computer 1 and security gateway 3.
`
`49. The ’397 patent describes that “an IPSec connection is formed
`
`between the client computer 1 (the first computer) and the security gateway 3 (the
`
`second computer).” Id., 10:40-42. To create the IPSec connection, “a SA [(Security
`
`Association)] (or usually a SA bundle) is formed between the respective computers
`
`with a preceding key exchange. The key exchange between the first and the second
`
`computer can take place manually or it can be performed with an automatic key
`
`
`
`- 20 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 9,762,397
`
`exchange protocol such as the IKE [(Internet Key Exchange)] protocol.” Id.,
`
`10:42-48. As described above, the patent explains that an IPSec “security
`
`association is a one-way relationship between a sender and a receiver that offers
`
`security services to the traffic carried on it.” Id., 2:15-20.
`
`50. Following establishment of an SA, “[m]essages to be sent to the host
`
`terminal 4 from the client computer 1 are first sent to the server 2, wherein an
`
`IPSec translation and an IKE translation takes place. After that the message can be
`
`sent to the security gateway 3, which sends the message further in plain text to the
`
`host terminal 4.” Id., 10:54-58. A message sent to the intermediate computer (e.g.,
`
`server 2) includes “a unique identity and a destination address.” Id., 1:38-40. This
`
`unique identity and destination address “are used to find an address to the second
`
`computer” (e.g., security gateway 3). Id., 1:40-43. When the address of the second
`
`computer is found, the unique identity and current destination address of the
`
`message are substituted with another unique identi