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

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`
`TABLE OF CONTENTS
`
`
`I. Background and Qualifications ........................................................................... 5
`II. Legal Understanding ........................................................................................... 8
`A. My Understanding of Claim Construction ...................................................... 8
`B. My Understanding of Obviousness ................................................................. 8
`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) .................................................................12
`B. The Internet Key Exchange (IKE) .................................................................15
`C. The Secure Sockets Layer (SSL) ...................................................................17
`D. IPSec and Network Address Translation (NAT) ...........................................18
`IV. Overview of the ’949 Patent .............................................................................20
`V. Claim Construction ...........................................................................................24
`A. “secure connection” .......................................................................................24
`B. “unique identity [of the secure connection]” .................................................25
`VI. The Combination of RFC3104 and Grabelsky Renders Claims 1, 2, 4-7, 9, 11-
`14, 20-21, and 27-29 Obvious..................................................................................26
`A. Brief Overview of RFC3104 .........................................................................26
`B. The Combination of RFC3104 and Grabelsky ..............................................30
`C. Claim 1 ...........................................................................................................36
`D. Claim 2 ...........................................................................................................54
`E. Claim 4 ...........................................................................................................55
`F. Claim 5 ...........................................................................................................58
`G. Claim 6 ...........................................................................................................59
`H. Claim 7 ...........................................................................................................60
`I. Claim 9 ...........................................................................................................63
`J. Claim 11 .........................................................................................................66
`K. Claim 12 .........................................................................................................69
`L. Claim 13 .........................................................................................................70
`M. Claim 14 .........................................................................................................71
`
`
`
`- i -
`
`
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`N. Claim 20 .........................................................................................................71
`O. Claim 21 .........................................................................................................72
`P. Claim 27 .........................................................................................................73
`Q. Claim 28 .........................................................................................................76
`R. Claim 29 .........................................................................................................77
`VII. The Combination of RFC3104, Grabelsky, and Wagner Renders Claim 3
`Obvious. ...................................................................................................................78
`A. Brief Overview of Wagner ............................................................................78
`B. Claim 3 ...........................................................................................................79
`VIII. Conclusion ..................................................................................................84
`
`
`
`
`
`
`
`
`- ii -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`
`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. 8,346,949 (“the ’949 patent”), titled “Method and System for Sending a
`
`Message Through a Secure Connection,” and that the ’949 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 ’949
`
`patent issued on January 1, 2013. I understand that the ’949 patent has been
`
`provided as Ex. 1001. I will cite to the specification using the following format:
`
`(’949 patent, 1:1-10.) This example citation points to the ’949 patent specification
`
`at column 1, lines 1-10.
`
`4.
`
`I have also reviewed and am familiar with the following documents
`
`and materials:
`
`• “RFC3104: 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. 8,346,949
`• “Analysis of the SSL 3.0 Protocol,” by David Wagner and Bruce
`
`Schneier (“Wagner”). I understand that Wagner has been provided as
`
`Ex. 1006.
`
`• “RFC2401: Security Architecture for the Internet Protocol,” by
`
`Stephen Kent and Randall Atkinson (“RFC2401”). I understand that
`
`RFC2401 has been provided as Ex. 1015.
`
`• “RFC2402: IP Authentication Header,” by Stephen Kent and Randall
`
`Atkinson (“RFC2402”). I understand that RFC2402 has been provided
`
`as Ex. 1016.
`
`• “RFC2406: IP Encapsulating Security Payload (ESP),” by Stephen
`
`Kent and Randall Atkinson (“RFC2406”). I understand that RFC2406
`
`has been provided as Ex. 1017.
`
`• “RFC2409: The Internet Key Exchange (IKE),” by Dan Harkins and
`
`Dave Carrel (“RFC2409”). I understand that RFC2409 has been
`
`provided as Ex. 1018.
`
`• “RFC3102: 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.
`
`
`
`- 2 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`• Prosecution history of the ’949 patent. I understand that the
`
`prosecution history has been provided as Ex. 1003.
`
`• 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.
`
`8.
`
`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
`
`
`
`- 3 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`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 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.
`
`9.
`
`I understand that Wagner was originally presented as part of the
`
`Second USENIX Workshop on Electronic Commerce, held in Oakland, California
`
`on November 18-21, 1996, as indicated on the face of Exhibit 1006. See Ex. 1006,
`
`0001; see also Ex. 1009, Mullins Decl., ¶¶38-42. USENIX workshops such as this
`
`were typically open to the interested public, and I have no reason to believe
`
`otherwise in this case. The papers presented at the workshop would typically be
`
`published in conference proceedings and distributed to attendees of the workshop
`
`without restriction.
`
`10.
`
`I am familiar with the technology described in the ’949 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 ’949 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 ’949 Patent.
`
`
`
`- 4 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`
`I.
`
`Background and Qualifications
`
`11. My qualifications are stated more fully in my curriculum vitae,
`
`attached as Exhibit 1008. Here, I provide a brief summary of my qualifications:
`
`12.
`
`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.
`
`13.
`
`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.
`
`
`
`- 5 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`14. 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.
`
`15. 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.
`
`16. 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.
`
`17. These positions, along with my education, all of which were
`
`completed before the relevant timeframe for assessing the validity of the ’949
`
`patent, more than qualify me as a person of ordinary skill in the art for the ’949
`
`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
`
`
`
`- 6 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`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.
`
`18.
`
`I have continued my work in computer security after the relevant
`
`timeframe for assessing the validity of the ’949 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.
`
`19.
`
`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 the
`
`art of the ’949 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 ’949 patent.
`
`20. 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.
`
`
`
`- 7 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`
`II. Legal Understanding
`
`A. My Understanding of Claim Construction
`I understand that, before the PTAB, claims are to be given their
`21.
`
`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
`22.
`
`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.
`
`23. 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.
`
`
`
`- 8 -
`
`

`

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

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`the invention; and (8) the patentee proceeded contrary to the accepted wisdom of
`
`the prior art.
`
`27.
`
`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.
`
`C. Level of Skill in the Art
`I understand that a person of ordinary skill in the relevant art is
`28.
`
`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.
`
`29.
`
`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;
`
`
`
`- 10 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`• the types of problems encountered in the field; and
`
`• the sophistication of the technology.
`
`30. 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.
`
`31. Based on the disclosure of the ’949 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.
`
`32. 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.
`
`33. 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
`
`34. The ’949 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.
`
`
`
`- 11 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`
`A.
`35.
`
`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, ’949 patent, 1:43-50; 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 ’949 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
`
`network, or
`
`to secure communication with other organisations, ensuring
`
`authentication and confidentiality and providing a key exchange mechanism.” ’949
`
`patent, 1:43-50; see also RFC2401, 25.)
`
`36. 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).”
`
`’949 patent, 1:64-2:3. 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
`
`
`
`- 12 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`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., 1:64-3; 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.” ’949 patent, 2:3-6.
`
`37. The ’949 patent further explains that “a key concept” of IPSec is a
`
`security association (SA): “A security association is a one-way relationship
`
`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:7-18.
`
`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.
`
`38. To implement this notion, each host must be capable of uniquely
`
`identifying the correct SA required to process a data packet. The ’949 patent
`
`discloses that “[a] security association is uniquely identified by three parameters.
`
`
`
`- 13 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`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:28-38; see also RFC2401, 8.
`
`39. The ’949 patent describes that IPSec services support two modes:
`
`“transport mode” and “tunnel mode.” ’949 patent, 3:1-2; see also RFC2401, 9.
`
`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.,
`
`
`
`- 14 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`by securing packets with both transport and tunnel modes), and may be combined
`
`with other security protocols such as SSL.
`
`40. This standard approach is reiterated in the ‘949 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.” ’949 patent, 3:3-12. 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:6-14. The ’949 patent does not alter these
`
`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.
`41. The ’949 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.” ’949 patent, 3:60-65;
`
`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
`
`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
`
`
`
`- 15 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`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.
`
`42.
`
`IKE typically involves two phases: “Phase 1 is where the two
`
`ISAKMP peers establish a secure, authenticated channel with which to
`
`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.
`
`43. 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.”
`
`
`RFC5996 and post-dates the filing date of the ’949 patent by several years. This
`
`document will use the term IKE exclusively to refer to IKEv1.
`
`
`
`- 16 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`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.
`
`C. The Secure Sockets Layer (SSL)
`44. While the ’949 patent contains no discussion of the Secure Sockets
`
`Layer (SSL) whatsoever, the ’949 patent recites SSL in claim 3. ’949 patent, Claim
`
`3. SSL is a protocol that is “is intended to provide a practical, application-layer,
`
`widely applicable connection-oriented mechanism for Internet client/server
`
`communications security.” Ex. 1006, Wagner, 2. Around the time of the ’949
`
`patent, SSL had “become a de facto standard for cryptographic protection of Web
`
`http traffic.” Id. SSL operates at the “application layer”, which means that SSL
`
`encryption is applied to data before the data is formed into IP packets. IP (or
`
`Network)-layer security systems such as IPsec process data after this packetization
`
`has occurred. Despite these implementation differences, SSL is often used as an
`
`alternative to IPSec, although the protocol standards may be used in conjunction
`
`with one another. The successor to SSL became known as Transport Layer
`
`Security when it was proposed as an Internet Engineering Task Force (IETF)
`
`standard. Frankel, 245. At the time of the ‘949 packet, the most recent version of
`
`SSL was version 3.0, and the most recent version of TLS was TLS 1.0. See Ex.
`
`1014, RFC2246, 1, 60.
`
`
`
`- 17 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`45. Similar to IPSec, SSL employs a key-exchange protocol to establish a
`
`secure, end-to-end connection: “SSL is divided into two layers, with each layer
`
`using services provided by a lower layer and providing functionality to higher
`
`layers. The SSL record layer provides confidentiality, authenticity, and replay
`
`protection over a connection-oriented reliable transport protocol such as TCP.
`
`Layered above the record layer is the SSL handshake protocol, a key-exchange
`
`protocol which initializes and synchronizes cryptographic state at the two
`
`endpoints.” Wagner, 2. Wagner explains that “[a]fter the key-exchange protocol
`
`completes, sensitive application data can be sent via the SSL record layer.” Id.
`
`IPSec and Network Address Translation (NAT)
`
`D.
`46. 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
`
`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. 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
`
`
`
`- 18 -
`
`

`

`Declaration of David Goldschlag, Ph.D.
`U.S. Pat. No. 8,346,949
`this and other reasons, it has been widely used since well before the priority date of
`
`the ’949 patent.
`
`47. Consistent with this operation, the ’949 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.” ’949 patent, 4:59-
`
`64. While the ’949 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 N