Case IPR2019-00823
`Patent 9,712,494
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner.
`____________
`
`Case IPR2019-00823
`Patent 9,712,494
`____________
`
`
`EXHIBIT 2002
`
`DECLARATION OF PROFESSOR GEORGE N. ROUSKAS, PH.D.
`
`Exhibit 2002
`Page 2002-1
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`TABLE OF CONTENTS
`
`Page
`
`I.
`
`II.
`
`III.
`
`IV.
`
`INTRODUCTION ........................................................................................ 1
`
`QUALIFICATIONS ..................................................................................... 1
`
`BASES OF OPINIONS ................................................................................ 6
`
`APPLICABLE LEGAL STANDARDS ...................................................... 8
`
`A. Ordinary Skill in the Art ........................................................................ 8
`
`B.
`
`Claim Construction.............................................................................. 10
`
`C. Obviousness (35 U.S.C. § 103) ........................................................... 10
`
`V.
`
`OVERVIEW OF THE ’494 PATENT AND THE STATE OF THE
`ART AT THE TIME OF THE INVENTION ..........................................13
`
`A.
`
`B.
`
`C.
`
`The Difficulties of Implementing Standard IPSec with Mobile
`Devices and NAT Devices .................................................................. 14
`
`The Invention of the ’494 Patent ......................................................... 21
`
`Illustration of the ’494 Patent Invention ............................................. 23
`
`D. RFC 3104 RSIP Support for End-to-End IPSec ................................. 25
`
`E. Grabelsky DNAT Support for End-to-End IPSec ............................... 30
`
`VI.
`
`CLAIM CONSTRUCTION .......................................................................33
`
`A. Unique Identity .................................................................................... 34
`
`B. Mobile Computer ................................................................................ 40
`
`C.
`
`Substitute/Substituting ........................................................................ 46
`
`VII. GROUND 1: CLAIMS 1-5 AND 8-11 ARE PATENTABLE OVER
`THE COMBINATION OF RFC 3104 AND GRABELSKY ..................49
`
`i
`
`Exhibit 2002
`Page 2002-2
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`A. Claim 1 is Patentable Over the Combination of RFC 3104 and
`Grabelsky ........................................................................................... 49
`
`1.
`
`2.
`
`The Petition Fails to Establish that the Prior Art
`Teaches the “Mobile Computer” in “The Intermediate
`Computer Configured to Receive from a Mobile
`Computer a Secure Message” ................................................ 49
`
`The Petition Fails Because There is No Reasonable
`Expectation of Success that the Modifications Necessary
`to Make RSIP Support Mobile Hosts Would Work ............ 73
`
`B. Claim 2 is Further Patentable Because The Petition Fails to
`Establish that the Prior Art Teaches “The Intermediate
`Computer Is Further Configured to Substitute the Unique
`Identity Read from the Secure Message With Another Unique
`Identity Prior to Forwarding ........................................................... 74
`
`1.
`
`2.
`
`3.
`
`Dr. Goldschlag’s “Adding . . . an outer IP Header” Is
`Not Substituting the Unique Identity .................................... 75
`
`Dr. Goldschlag’s “Replacing an Outer IP Header” Does
`Not Meet the Limitation of Substituting the Unique
`Identity ..................................................................................... 76
`
`The Confusing Argument That Combining RFC 3104
`and Grabelsky Produces a “combination of the
`outermost IP header and the IPSec protocol header
`[that] is changed by RSIP server N” Is Completely
`Unsupported ............................................................................ 77
`
`C. Claims 3, 5, 8 and 10 Are Patentable Over the Combination of
`RFC 3104 and Grabelsky ................................................................. 80
`
`D. Claim 4 is Further Patentable Over the Combination of RFC
`3104 and Grabelsky ........................................................................... 80
`
`1.
`
`2.
`
`The Petition Fails to Fill In the Missing Limitation ............ 80
`
`The Cited Art Does Not Disclose the Claimed Two-Part
`Translation Table .................................................................... 83
`
`ii
`
`Exhibit 2002
`Page 2002-3
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`E. Claim 9 is Further Patentable Over the Combination of RFC
`3104 and Grabelsky ........................................................................... 85
`
`F. Claim 11 is Further Patentable Over the Combination of RFC
`3104 and Grabelsky ........................................................................... 87
`
`VIII. GROUND 2: CLAIMS 6-7 ARE PATENTABLE OVER THE
`COMBINATION OF RFC 3104, GRABELSKY AND WAGNER .......89
`
`IX. CONCLUSION ...........................................................................................90
`
`
`
`iii
`
`Exhibit 2002
`Page 2002-4
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`I.
`
`INTRODUCTION
`
`1. My name is George Rouskas. I have been retained as an expert
`
`witness to provide my independent opinion in regards with matters at issue in the
`
`inter partes review of U.S. 9,712,494 (“the ’494 Patent”) in the IPR2019-00823
`
`proceeding. I have been retained by MPH Technologies Oy (“MPH”), the Patent
`
`Owner, in the above proceedings. Petitioner in this case is Apple Inc. (“Apple”).
`
`2.
`
`Unless otherwise noted, the statements made herein are based on my
`
`personal knowledge, and if called to testify about this declaration, I could and
`
`would do so competently and truthfully.
`
`3.
`
`A detailed record of my professional qualifications including cases in
`
`which I was an expert is being submitted herewith as Exhibit 2003 and is
`
`summarized in Section II, infra.
`
`4.
`
`I am not a legal expert and offer no opinions on the law. However, I
`
`have been informed by counsel of the various legal standards that apply, and I have
`
`applied those standards in arriving at my conclusions.
`
`II.
`
`QUALIFICATIONS
`
`5.
`
`I am an Alumni Distinguished Graduate Professor with Tenure in the
`
`Department of Computer Science at North Carolina State University (NC State),
`
`where I also serve as the Director of Graduate Programs. I am an experienced
`
`researcher and educator in the field of computer networking, with expertise in
`
`1
`
`Exhibit 2002
`Page 2002-5
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`Internet architectures and protocols, virtualization and cloud computing, mobile
`
`devices, network devices, network security and security protocols, in a variety of
`
`applications including providing for the protection of information transmitted
`
`between devices within and among networks.
`
`6.
`
`I have thirty years of experience in computer networking since I
`
`received my bachelor’s degree in 1989. I have twenty-five years of experience as a
`
`professor in the Department of Computer Science of NC State.
`
`7.
`
`During this time, I have led, overseen, and contributed to numerous
`
`research projects involving technical concepts that are closely related to the
`
`technology at issue in the IPR2019-00823 proceeding, which relates to the issue of
`
`providing secure connections over networks, such as where a first computer device
`
`uses a security protocol to securely communicate with a second computer through
`
`an intermediate computer. For example, as part of my own research group’s NSF-
`
`funded ChoiceNet project, my research group developed a new Internet
`
`architecture, a suite of communication protocols, and a proof-of-concept prototype
`
`implementation to enable real-time economic transactions in the network layer,
`
`including secure payments. Earlier, for the NSA-funded Jumpstart project, my
`
`group developed a novel signaling architecture and protocol for high-speed
`
`networks and designed relevant security mechanisms.
`
`2
`
`Exhibit 2002
`Page 2002-6
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`8.
`
`I have taught courses on computer networks, Internet protocols, data
`
`structures and computer performance evaluation. In 1997 I created one of the
`
`world’s first graduate level courses on Internet Protocols, which I continue to teach
`
`regularly, and in which I cover in depth topics related to network security
`
`(including IPSec) and mobile IP.
`
`9.
`
`In my career in this field, I have received numerous accolades for my
`
`contributions to computer networking, including being elected as Fellow of the
`
`IEEE in 2012. Other accolades include the Outstanding Service Award for the
`
`Optical Networking Technical Committee (ONTC) of the IEEE Communication
`
`Society (2019); the Joyce Hatch Service Award from the NC State Chapter of the
`
`Association for Computing Machinery/Association of Information Technology
`
`Professionals (ACM/AITP) (2018); the title of Distinguished Lecturer in the IEEE
`
`(2010-2012); an IBM Faculty Award (2007); the Best Paper Award for the
`
`International Workshop on End-to-End Virtualization and Grid Management
`
`(EVGM) (2007) (with C. Castillo and K. Harfoush); the Best Paper Award for the
`
`International Symposium on Communication Systems, Networks and Digital
`
`Signal Processing (CSNDSP) (2006) (with B. Chen and R. Dutta); the ALCOA
`
`Foundation Engineering Research Achievement Award, NC State College of
`
`Engineering (2004); the Alumni Outstanding Research Award, NC State (2003);
`
`3
`
`Exhibit 2002
`Page 2002-7
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`the CAREER Award from the National Science Foundation (1997); and the
`
`Graduate Research Award from the Georgia Tech College of Computing (1994).
`
`10.
`
`I received my Ph.D. in Computer Science (Georgia Institute of
`
`Technology, 1994); M.S. in Computer Science (Georgia Institute of Technology,
`
`1991); and B.S. in Computer Engineering (National Technical University of
`
`Athens, 1989).
`
`11.
`
`In 2000-2001, while on Sabbatical from NC State, I worked as
`
`Network Architect for Vitesse Semiconductor, where I was responsible for the
`
`design of a state-of-the-art 2.5 Gbps network processor.
`
`12. My work as an academic began in 1994, when I joined NC State as an
`
`Assistant Professor. In 1999, I was promoted to Associate Professor with Tenure.
`
`In 2002, I was promoted to the position of Professor.
`
`13.
`
`I have held and hold visiting positions on the faculties of a number of
`
`international universities, including positions as a Distinguished Scientist at King
`
`Abdulaziz University (Saudi Arabia, March 2013 to present); Visiting Professor at
`
`the Laboratoire d’Informatique University of Paris 6 (France, October 2012);
`
`Visiting Professor at the Universidad Tecnica Federico Santa Maria (Chile,
`
`December 2008); and Visiting Professor at the Laboratoire de Méthodes
`
`Informatiques University of Evry (France, July 2006, December 2002, June 2000).
`
`4
`
`Exhibit 2002
`Page 2002-8
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`14.
`
`I have received funding from numerous agencies, foundations and
`
`companies for research on network design and communication. The sources of
`
`funding for this research include the National Science Foundation (NSF), the
`
`Defense Advanced Research Projects Agency (DARPA), the National Security
`
`Agency (NSA), Microsoft, IBM and Cisco.
`
`15.
`
`I have served in a number of leadership roles for the IEEE, including
`
`as Chair of the IEEE Communications Society’s Distinguished Lecturer Selection
`
`Committee (2016-2017); Vice Chair of the IEEE Communications Society’s
`
`Technical and Educational Activities Council (2016-2017); and Chair of the IEEE
`
`Communications Society’s Optical Networking Technical Committee (2016-2017).
`
`16.
`
`I have served in various founding, editorial and leadership positions
`
`for publications in my field, including as founding Editor-in-Chief of IEEE
`
`Networking Letters (2018-present); founding Editor-in-Chief, Elsevier Optical
`
`Switching and Networking Journal (2004-2017); Associate Editor, IEEE/OSA
`
`Journal of Communications and Networking (2010-2012); Co-Guest Editor, JCM
`
`Journal of Communications, Special Issue on the “Advances in Communications
`
`and Networking,” vol. 6, no. 9, December 2011; Associate Editor, IEEE/ACM
`
`Transactions on Networking (2000-2004); Associate Editor, Computer Networks
`
`(2001-2004); Associate Editor, Optical Networks (2000-2004); and Co-Guest
`
`Editor, IEEE Journal on Selected Areas in Communications, Special Issue on
`
`5
`
`Exhibit 2002
`Page 2002-9
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`“Protocols for Next Generation Optical WDM Networks,” vol. 18, no. 10, October
`
`2000.
`
`17.
`
`I have graduated twenty-five Ph.D. students. Two have received Ph.D.
`
`dissertation awards, one has received an NSF Career award, and one became an
`
`NSA Fellow. Three of my former Ph.D. students became Assistant Professors
`
`upon graduation, and the rest joined significant technology companies or research
`
`institutes, including RENCI (UNC-Chapel Hill), IBM Research, Google,
`
`Facebook, Cisco, Oracle, Ericsson, Riverbed Technologies, Sprint, and Sierra
`
`Wireless, among others. I have also graduated twelve M.S. students.
`
`18. During the course of my career, I have had more than 200 scientific
`
`articles, three books and ten book chapters published, which have collectively
`
`received more than 8500 citations (Google Scholar, as of November 21, 2019).
`
`These are summarized in attached my curriculum vitae (see Ex. 2003).
`
`III.
`
`BASES OF OPINIONS
`
`19.
`
`In the course of conducting my analysis and forming my opinions, I
`
`have reviewed at least the items listed below as well as the papers submitted by
`
`Patent Owner in MPH in IPR2019-00824 and IPR2019-00826:
`
`i.
`
`ii.
`
`U.S. Patent No. 9,712,494 and its prosecution history;
`
`Petition by Apple in IPR2019-00823;
`
`iii.
`
`Petition by Apple in IPR2019-00824;
`
`6
`
`Exhibit 2002
`Page 2002-10
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`iv.
`
`Petition by Apple in IPR2019-00826;
`
`v.
`
`Declaration of Dr. David Goldschlag in IPR2019-00823;
`
`vi. Declaration of Dr. David Goldschlag in IPR2019-00824;
`
`vii. Declaration of Dr. David Goldschlag in IPR2019-00826;
`
`viii. Patent Owner’s Preliminary Response in IPR2019-00823;
`
`ix.
`
`Patent Owner’s Preliminary Response in IPR2019-00824;
`
`x.
`
`Patent Owner’s Preliminary Response in IPR2019-00826;
`
`xi.
`
`Institution Decision by the PTAB in IPR2019-00823;
`
`xii.
`
`Institution Decision by the PTAB in IPR2019-00824;
`
`xiii.
`
`Institution Decision by the PTAB in IPR2019-00826;
`
`xiv. Deposition Transcript of Dr. David Goldschlag (January 30, 2020)
`
`xv. U.S. Pat. No. 9,712,502;
`
`xvi. U.S. Pat. No. 9,838,362;
`
`xvii. RFC 3104 “RSIP Support for End-to-end IPsec”
`
`xviii. RFC 3102 “Realm Specific IP: Framework”
`
`xix. RFC 3103 “Realm Specific IP: Protocol Specification”
`
`xx. U.S. Pat No. 7,032,242 (Grabelsky)
`
`xxi. RFC 2401 “Security Architecture for the Internet Protocol”
`
`xxii. RFC 2402 “IP Authentication Header”
`
`xxiii. RFC 2406 “IP Encapsulating Security Payload (ESP)
`
`
`7
`
`Exhibit 2002
`Page 2002-11
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`xxiv. Conversation with Dr. Michael Borella regarding RFC 3104 and
`RSIP.
`
`
`IV.
`
`APPLICABLE LEGAL STANDARDS
`
`A. Ordinary Skill in the Art
`
`20. My opinions in this declaration are based on the understandings of a
`
`person of ordinary skill in the art, which I understand is sometimes referred to as
`
`an “ordinary artisan” or by the acronyms “POSITA” (person of ordinary skill in the
`
`art) or “PHOSITA” ” (person having ordinary skill in the art), as of the time of the
`
`invention, which I understand is here assumed to be at least as early as January 21,
`
`2003, which is the filing date of the PCT application PCT/2002/0112 from which
`
`priority was asserted by original U.S. application 10/500,930, which issued as U.S.
`
`Pat. No. 8,346,949, and from which priority was asserted by the present application
`
`through an intervening application. I also understand that the priority chain of the
`
`present application extends from the above mentioned PCT Application to the
`
`January 22, 2002, filing date of the application filed in Finland, FI 2002/0112. See
`
`Ex. 1001 [’494 Patent] (Cover Page) 0001. My analysis and conclusions are the
`
`same whether the relevant time period is 2003 or 2002. I understand that the person
`
`of ordinary skill in the art is a hypothetical person who is presumed to have known
`
`the relevant art at the time of the invention. By “relevant,” I mean relevant to the
`
`challenged claims of the ’494 Patent.
`
`8
`
`Exhibit 2002
`Page 2002-12
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`21.
`
`I understand that, in assessing the level of skill of a person of ordinary
`
`skill in the art, one should consider the type of problems encountered in the art, the
`
`prior solutions to those problems found in the prior art references, the rapidity with
`
`which innovations are made, the sophistication of the technology, the level of
`
`education of active workers in the field, and my own experience working with
`
`those of skill in the art at the time of the invention.
`
`22.
`
`In this case, Dr. Goldschlag has asserted in his declaration that a
`
`person of ordinary skill in the art (POSITA) at the time of the ’494 Patent would
`
`have had 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. Ex. 1002 [Goldschlag Decl.] ¶
`
`31. I have employed Dr. Goldschlag’s definition in this declaration, except that I
`
`have disregarded the words “at least” for purposes of my analysis because they
`
`would seem to make his definition of the level of ordinary skill open-ended and
`
`uncertain.
`
`23.
`
`I was at the time of invention, and am, one of more than ordinary skill
`
`in the art through my education and research experience. As of the date of the
`
`invention, I am very familiar with the types of problems encountered in computer
`
`network security, the types of prior art solutions described in prior art references,
`
`and the rapidity at which innovations are made. Indeed, I am very familiar with
`
`9
`
`Exhibit 2002
`Page 2002-13
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`people having this level of skill in the area of computer network security. At the
`
`time of the invention, and since that time, I have been teaching undergraduate and
`
`graduate level courses in computer network architecture and protocols including
`
`various techniques for addressing information security.
`
`B. Claim Construction
`
`24.
`
`I understand that claims of the patent-at-issue in this IPR are generally
`
`interpreted according to their ordinary and customary meaning taking into
`
`consideration the so-called “intrinsic evidence” of the patent consisting of (1) the
`
`claim language; (2) the specification; and (3) the prosecution history. I understand
`
`that the Board has discretion to take into consideration so-called “extrinsic
`
`evidence” including references (prior art and non-prior art) as well as definitions
`
`from dictionaries and treatises.
`
`25.
`
`I understand that claim terms may be explicitly defined in the patent
`
`specification or they may be implicitly defined through consistent usage in the
`
`specification. I also understand that the scope of claim terms may be limited by
`
`statements in the specification or prosecution history where the applicant clearly
`
`disavows or disclaims subject matter in a clear and unmistakable manner.
`
`C. Obviousness (35 U.S.C. § 103)
`
`26.
`
`I have been informed that a patent may be invalid if the claimed
`
`invention considered as a whole would have been obvious at the time the invention
`
`10
`
`Exhibit 2002
`Page 2002-14
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`was made to a person having ordinary skill in the art. 35 U.S.C. § 103. I have been
`
`informed that the following factors must be evaluated to determine whether
`
`Petitioner has met its burden of proof on obviousness: (1) the scope and content of
`
`the prior art; (2) the level of ordinary skill in the art; and (3) the differences
`
`between the claimed subject matter and the prior art. Based on these factual
`
`inquiries, it must then be determined, as a matter of law (4) whether or not the
`
`claimed subject matter as a whole would have been obvious to one of ordinary skill
`
`in the art at the time the alleged invention was made.
`
`27.
`
`I understand that a finding of obviousness requires a showing that as
`
`of the date of the invention (a) the prior art teaches or suggests each of the
`
`limitations of the claim; (b) there exists an apparent reason or motivation to
`
`combine and/or modify the prior art as proposed; and (c) a person of ordinary skill
`
`would have a reasonable expectation of success, including that the proposed
`
`combination and/or modification of the prior art would operate for its intended
`
`purpose.
`
`28.
`
`I have been informed that a claim is not proved obvious merely by
`
`demonstrating that each of the elements was independently known in the prior art.
`
`I have been informed that many, if not all, inventions rely on building blocks
`
`already known, and claimed inventions almost of necessity will likely be
`
`combinations of what is already known.
`
`11
`
`Exhibit 2002
`Page 2002-15
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`29.
`
`I have been informed that it is important in the obviousness inquiry to
`
`identify whether a reason existed at the time of the invention that would have given
`
`a POSITA motivation to combine and/or modify the prior art references in the
`
`manner proposed by the Petitioner so as to arrive at the claimed invention. Put
`
`another way, a finding of obviousness should be supported by an apparent reason
`
`to combine and/or modify the prior art references as proposed by the Petitioner.
`
`30.
`
`I also understand that the obviousness inquiry should guard against
`
`hindsight bias or hindsight reconstruction where after-the-fact reasoning is applied
`
`to combine prior art elements using the claimed invention as a template, without
`
`establishing that, as of the date of the invention, there exists a motivation to
`
`combine or apparent reason to combine and/or modify the prior art as proposed.
`
`31.
`
`I have been informed that it is important in the obviousness inquiry
`
`that it is understood how the combination of references is supposed to work. An
`
`explanation of the operation of the combined references is often a prerequisite to
`
`showing that a person of ordinary skill in the art would have been motivated to
`
`make the proposed combination and would have had a reasonable expectation of
`
`success in doing so.
`
`32.
`
` In assessing obviousness, I have been instructed to consider both the
`
`ordinary creativity and common sense of the person of ordinary skill in the art. I
`
`12
`
`Exhibit 2002
`Page 2002-16
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`also understand that it is impermissible for common sense to be applied so as to fill
`
`gaps in prior art that fails to teach or suggest a limitation of the claim.
`
`33.
`
`In assessing obviousness, I have been instructed that, in order to
`
`qualify as proper prior art for an obviousness analysis, a reference must qualify as
`
`analogous art. I have been informed that a reference qualifies as analogous art with
`
`respect to the claims if it is either: (1) from the same field or endeavor as the
`
`patent; or (2) the reference is reasonably pertinent to the particular problem
`
`addressed by the invention. I have also been informed that in order for a reference
`
`to be reasonably pertinent, it must logically have commended itself during the
`
`ordinary course of development to an inventor’s attention in considering his
`
`problem.
`
`V.
`
`OVERVIEW OF THE ’494 PATENT AND THE STATE OF THE ART
`AT THE TIME OF THE INVENTION
`
`For clarity to the reader, my citations will adhere to these formats:
`
` The exhibit number and a brief descriptor of the document (e.g., “Ex.
`
`1001 [’494 Patent]”) will be referenced when a document is cited.
`
` Petitions and other papers filed by the parties. Example: Pet., 10,
`
`refers to the Petition at page 10.
`
` Patents will be cited by their specific column and line numbers.
`
`Example: “Ex. 1006 [Grabelsky], 1:10-12” refers to the Grabelsky
`
`patent at page Col. 1, lines 10-12.
`
`13
`
`Exhibit 2002
`Page 2002-17
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
` Articles and other publications will be cited by their bates stamped
`
`page and their original page number, as appropriate. Example, “Ex.
`
`1004 [RFC 3104], 4” refers to RFC 3104 at page 4.
`
`A. The Difficulties of Implementing Standard IPSec with Mobile
`Devices and NAT Devices
`
`34. Telecommunications networks can encompass a vast array of
`
`components including local area networks (LANs), wide area networks (WANs)
`
`and various computing devices all interconnected using intermediary networking
`
`devices. Intermediary networking devices such as routers enable different networks
`
`to be interconnected so as to function as an “internetwork,” that is, as an internet.
`
`Such interconnected networks can allow geographically dispersed users to
`
`communicate. Ex. 1001 [’494 Patent], 1:24-37.
`
`35. Normally, a person who mails a sealed letter does not want and does
`
`not expect that the contents of the letter will be read by a third party while the letter
`
`is en route to the intended recipient. In a similar manner, those parties who
`
`exchange communications between a first terminal and a second terminal want to
`
`protect the confidentiality and integrity of the information they are exchanging.
`
`36. The ’494 Patent explains that IPSec is a technology to secure the
`
`communications of messages across networks:
`
`The IP security protocols (IPSec) provides the capability
`
`to secure communications across a LAN, across private
`
`14
`
`Exhibit 2002
`Page 2002-18
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`and public wide area networks (WANs) and 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 [(as remote access IPSec
`
`use)], or
`
`to
`
`secure communication with other
`
`organisations, ensuring authentication and confidentiality
`
`and providing a key exchange mechanism. IPSec ensures
`
`confidentiality integrity, authentication, replay protection,
`
`limited
`
`traffic flow confidentiality,
`
`limited identity
`
`protection, and access control based on authenticated
`
`identities. Even if some applications already have built in
`
`security protocols, the use of IPSec further enhances the
`
`security.
`
`Ex. 1001 [’494 Patent], 1:54-67.
`
`37. At the time of the invention, IPSec was described in “Security
`
`Architecture for the Internet Protocol,” issued by the Internet Engineering Task
`
`Force (IETF) Network Working Group as RFC 2401. See Ex. 1015 [RFC 2041]
`
`(Security Architecture for the Internet Protocol, November 1998). The two types of
`
`protocols supported by IPSec, Authentication Header (AH) and Encapsulating
`
`Security Payload (ESP), are described in Ex. 1016 (RFC 2402) [IP Authentication
`
`Header] (November 1998). See Ex. 1001 [’494 Patent], 2:9-18. The ’494 document
`
`states that the various documents defining IPSec are RFCs 2401-2412. Ex. 1001
`
`[’494 Patent], 2:6-8.
`
`15
`
`Exhibit 2002
`Page 2002-19
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`38. RFC 2401 itself describes the fundamental features and processes of
`
`IPSec secure connections:
`
`This memo specifies the base architecture for IPsec
`
`compliant systems. The goal of the architecture is to
`
`provide various security services for traffic at the IP layer
`
`. . . The following fundamental components of the IPsec
`
`security architecture are discussed in terms of their
`
`underlying, required functionality . . .
`
`a. Security Protocols -- Authentication Header (AH) and
`
`Encapsulating Security Payload (ESP)
`
`b. Security Associations -- what they are and how they work,
`
`how they are managed, associated processing
`
`c. Key Management -- manual and automatic (The Internet Key
`
`Exchange (IKE))
`
`d. Algorithms for authentication and encryption
`
`
`
`
`
`
`
`Ex. 1015 [RFC 2401], 3 (Section 1.1: Summary of Contents of Document).
`
`39. The ’494 Patent provides a detailed explanation of the features of
`
`IPSec:
`
`IPSec can encrypt and/or authenticate traffic at IP level.
`
`Traffic going in to a WAN is typically compressed and
`
`encrypted and traffic coming from a WAN is decrypted
`
`and decompressed. . . . Two protocols are used to provide
`
`security at the IP layer, an authentication protocol
`
`designated by the header of the protocol, Authentication
`
`Header (AH), and a combined encryption/authentication
`
`16
`
`Exhibit 2002
`Page 2002-20
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`protocol designated by the format of the packet for that
`
`protocol, Encapsulating Security Payload (ESP). … 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.
`
`Ex. 1001 [’494 Patent], 2:1-18.
`
`40. The ’494 Patent describes fundamental concepts of IPSec secure
`
`connections. For example, Security Associations (SAs) are data structures that are
`
`fundamental to IPSec processing. Ex. 1001 [’494 Patent], 2:19-49. The ’494 Patent
`
`explains that an SA defines a one-way security relationship that protects the
`
`message traffic sent from sender to a receiver. Id. If a two-way secure connection
`
`between the sender and receiver is desired, then two SA definitions are required. In
`
`some cases, multiple SAs, referred to as an “SA bundle,” are used to protect a data
`
`packet being sent from one address to another. In the ’494 Patent, the term “IPsec
`
`connection” encompasses an IPSec bundle or IPSec bundles (e.g., one for each
`
`direction) of SAs that define the security protocols that will be employed for
`
`message traffic between two host devices, for example. Id., 2:31-38.
`
`41. The ’494 Patent discloses that an SA is uniquely defined by three
`
`parameters: (1) the Security Parameters Index (SPI), (2) the IP destination address
`
`(Dst), and (3) the IPSec security protocol type (which can be an AH
`
`[Authentication Header] or an ESP [Encapsulated Security Payload]). Id., 2:39-49.
`
`For each IPSec connection a Security Association Database (SADB) stores the
`
`17
`
`Exhibit 2002
`Page 2002-21
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`information for each SA, including items (1)-(3) above, as well as information
`
`defining the authentication algorithms, encryption algorithms, keys and related
`
`parameters that are used to cryptographically protect the message traffic over the
`
`IPSec secure connection. Id., 2:50-3:12.
`
`42. The ’494 Patent explains that IPSec secure connections support two
`
`modes: transport mode and tunnel mode. Transport mode protects the IP packet
`
`payload, not the entire IP packet including header information. Tunnel mode
`
`provides more complete protection by creating an outer packet with a new IP
`
`header that protects everything within it, which is effectively treated as a payload
`
`of the outer packet. For the tunnel mode, the original packet can be represented as
`
`an IP datagram in the form of IP|payload. Next, a new, outer IP header is added to
`
`the original packet, yielding IP|IP|payload. The original packet is then secured
`
`using either IPSec AH protocol or ESP protocol. If ESP is applied, the resulting
`
`packet is IP|ESP|IP|payload. Notably, the IP header of the outer packet can have
`
`source and destination addresses that are completely different from the source and
`
`destination addresses of the encapsulated inner packet. For example, if the outer
`
`packet source is A and its destination is B, the inner packet travels within a tunnel
`
`from A to B without its contents being exposed along the way by intervening
`
`routers that eventually forward the packet to its outer packet destination of B. See
`
`Ex. 1001 [’494 Patent], 3:13-65.
`
`18
`
`Exhibit 2002
`Page 2002-22
`IPR2019-00823, Apple Inc. v. MPH Techs. Oy
`
`

`

`
`
`43. As referenced in RFC 2401 (see Ex. 1015, 3), an essential aspect of
`
`IPSec is key management. Key management includes t