`By:
`
`Joseph E. Palys
`Paul Hastings LLP
`875 15th Street NW
`Washington, DC 20005
`Telephone: (202) 551-1996
`Facsimile: (202) 551-0496
`E-mail: josephpalys@paulhastings.com
`
`
`
`Naveen Modi
`Paul Hastings LLP
`875 15th Street NW
`Washington, DC 20005
`Telephone: (202) 551-1990
`Facsimile: (202) 551-0490
`E-mail: naveenmodi@paulhastings.com
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`
`
`
`APPLE INC.
`Petitioner
`
`v.
`
`VIRNETX INC.
`Patent Owner
`
`
`
`
`
`
`
`Case IPR2015-00811
`Patent 8,868,705
`
`
`
`
`
`
`
`
`
`
`Declaration of Fabian Monrose, Ph.D.
`
`
`
`1
`
`
`
`
`
`Page 1 of 64
`
`VIRNETX EXHIBIT 2016
`Apple v. VirnetX
` IPR2016-00332
`
`
`
`Case No. IPR2015-00811
`
`Table of Contents
`
`I.
`
`II.
`
`Introduction ...................................................................................................... 4
`
`Resources Consulted ........................................................................................ 5
`
`III. Background and Qualifications ....................................................................... 5
`
`IV. Level of Ordinary Skill .................................................................................. 10
`
`V.
`
`Claim Terms .................................................................................................. 11
`
`A.
`
`B.
`
`“Secure Domain Name” (Claims 3, 10, and 25) ................................. 11
`
`“Encrypted Communications Channel” Phrases (Claims 1, 2, 4-
`7, 9, 11-13, 18, 21, 22, and 26-29) ...................................................... 13
`
`C.
`
`“Provisioning Information” (Claims 1, 9, and 21) .............................. 14
`
`D. Other Terms ......................................................................................... 15
`
`VI. Aventail and RFC 2401 .................................................................................. 17
`
`A.
`
`B.
`
`Aventail’s Disclosure ........................................................................... 17
`
`Claims 1 and 21 ................................................................................... 21
`
`1.
`
`2.
`
`3.
`
`“Determining Whether the Request to Look Up an IP
`Address Transmitted [Intercepted] in Step 1 Corresponds
`to a Device That Accepts an Encrypted Channel
`Connection with the Client Device” ......................................... 21
`
`“Encrypted Communications Channel Between the Client
`Device and the Target Device” ................................................. 29
`
`“In Response to Determining . . . Providing Provisioning
`Information” .............................................................................. 31
`
`a)
`
`b)
`
`c)
`
`HOSTENT ...................................................................... 33
`
`TCP Sequence Numbers ................................................. 36
`
`Selection of Encryption Method & Certificate
`Exchange ......................................................................... 38
`
`2
`
`Page 2 of 64
`
`
`
`Case No. IPR2015-00811
`
`d)
`
`SOCKS Exchanges ......................................................... 39
`
`C.
`
`D.
`
`E.
`
`Claims 2, 16, and 33 ............................................................................ 40
`
`Claims 3 and 25 ................................................................................... 42
`
`Claims 17 and 34 ................................................................................. 43
`
`VII. Conclusion ..................................................................................................... 45
`
`
`
`
`
`3
`
`Page 3 of 64
`
`
`
`Case No. IPR2015-00811
`
`I, FABIAN MONROSE, declare as follows:
`
`I.
`
`Introduction
`1.
`I have been retained by VirnetX Inc. (“VirnetX”) for this inter partes
`
`review proceeding. I understand that this proceeding involves U.S. Patent No.
`
`8,868,705 (“the ’705 patent”). I understand the ’705 patent is assigned to VirnetX
`
`and that it is part of a family of patents that stems from U.S. provisional
`
`application nos. 60/106,261 (“the ’261 application”), filed on October 30, 1998,
`
`and 60/137,704 (“the ’704 application”), filed on June 7, 1999. I understand that
`
`the ’705 patent is a continuation of U.S. application no. 13/049,552 filed March 16,
`
`2011 (“the ’552 application”), which is a continuation of U.S. application no.
`
`11/840,560 filed August 17, 2007 (now U.S. Patent No. 7,921,211, “the ’211
`
`patent”), which is a continuation of U.S. application no. 10/714,849 filed
`
`November 18, 2003 (now U.S. Patent No. 7,418,504 (“the ’504 patent), which is a
`
`continuation of U.S. application no. 09/558,210 filed April 26, 2000 (“the ’210
`
`application,” abandoned). And I understand the ’210 application is a continuation-
`
`in-part of U.S. application no. 09/504,783 filed February 15, 2000 (now U.S.
`
`Patent 6,502,135, “the ’135 patent”), and that the ’135 patent is a continuation-in-
`
`part of U.S. application no. 09/429,643 (now U.S. Patent No. 7,010,604) filed
`
`October 29, 1999, which claims priority to the ’261 and ’704 applications.
`
`4
`
`Page 4 of 64
`
`
`
`Case No. IPR2015-00811
`
`II. Resources Consulted
`2.
`I have reviewed the ’705 patent, including claims 1-34. I have also
`
`reviewed the Petition for Inter Partes Review (Paper No. 1) filed with the U.S.
`
`Patent and Trademark Office (“Office”) by Apple Inc. on March 2, 2015 (Paper
`
`No. 1, the “Petition”). I have also reviewed the Patent Trial and Appeal Board’s
`
`(“Board”) decision to institute inter partes review (Paper No. 8, the “Decision”) of
`
`September 11, 2015.
`
`3.
`
`I understand that in this proceeding the Board instituted review of the
`
`’705 patent on two grounds: (1) obviousness of claims 1-3, 6, 14, 16-25, 28, 31,
`
`33, and 34 over Aventail and RFC 2401; (2) obviousness of claims 8-10, 12, 15,
`
`30, and 32 over Aventail, RFC 2401, and RFC 2543; (3) obviousness of claims 4,
`
`5, 7, 26, 27, and 29 over Aventail, RFC 2401, and Brand; and (4) obviousness of
`
`claims 11 and 13 over Aventail, RFC 2401, RFC 2543, and Brand. I have
`
`reviewed the exhibits and other documentation supporting the Petition that are
`
`relevant to the Decision and the instituted grounds, and any other material that I
`
`reference in this declaration.
`
`III. Background and Qualifications
`4.
`I have a great deal of experience and familiarity with computer and
`
`network security, and have been working in this field since 1993 when I entered
`
`the Ph.D. program at New York University.
`
`5
`
`Page 5 of 64
`
`
`
`Case No. IPR2015-00811
`
`5.
`
`I am currently a Professor of Computer Science at the University of
`
`North Carolina at Chapel Hill. I also hold an appointment as the Director of
`
`Computer and Information Security at the Renaissance Computing Institute
`
`(RENCI). RENCI develops and deploys advanced technologies to facilitate
`
`research discoveries and practical innovations. To that end, RENCI partners with
`
`researchers, policy makers, and technology leaders to solve the challenging
`
`problems that affect North Carolina and our nation as a whole. In my capacity as
`
`Director of Computer and Information Security, I
`
`lead
`
`the design and
`
`implementation of new platforms for enabling access to, and analysis of, large and
`
`sensitive biomedical data sets while ensuring security, privacy, and compliance
`
`with regulatory requirements. At RENCI, we are designing new architectures for
`
`securing access to data (e.g., using virtual private networks and data leakage
`
`prevention technologies) hosted among many different institutions. Additionally, I
`
`serve on RENCI’s Security, Privacy, Ethics, and Regulatory Oversight Committee
`
`(SPOC), which oversees the security and regulatory compliance of technologies,
`
`designed under the newly-formed Data Science Research Program and the Secure
`
`Medical Research Workspace.
`
`6.
`
`I received my B.Sc. in Computer Science from Barry University in
`
`May 1993. I received my MSc. and Ph.D. in Computer Science from the Courant
`
`Institute of Mathematical Sciences at New York University in 1996 and 1999,
`
`6
`
`Page 6 of 64
`
`
`
`Case No. IPR2015-00811
`
`respectively. Upon graduating from the Ph.D. program, I joined the Systems
`
`Security Group at Bell Labs, Lucent Technologies. There, my work focused on the
`
`analysis of
`
`Internet Security
`
`technologies
`
`(e.g.,
`
`IPsec and client-side
`
`authentication) and applying
`
`these
`
`technologies
`
`to Lucent’s portfolio of
`
`commercial products. In 2002, I joined the Johns Hopkins University as Assistant
`
`Professor in the Computer Science department. I also served as a founding
`
`member of the Johns Hopkins University Information Security Institute (JHUISI).
`
`At JHUISI, I served a key role in building a center of excellence in Cyber Security,
`
`leading efforts in research, education, and outreach.
`
`7.
`
`In July of 2008, I joined the Computer Science department at the
`
`University of North Carolina (UNC) Chapel Hill as Associate Professor, and was
`
`promoted to Full Professor four years later. In my current position at UNC Chapel
`
`Hill, I work with a large group of students and research scientists on topics related
`
`to cyber security. My former students now work as engineers at several large
`
`companies, as researchers in labs, or as university professors themselves. Today,
`
`my research focuses on applied areas of computer and communications security,
`
`with a focus on traffic analysis of encrypted communications (e.g., Voice over IP);
`
`Domain Name System (DNS) monitoring for performance and network abuse;
`
`network security architectures for traffic engineering; biometrics and client-to-
`
`client authentication techniques; computer forensics and data provenance; runtime
`
`7
`
`Page 7 of 64
`
`
`
`Case No. IPR2015-00811
`
`attacks and defenses for hardening operating system security; and large-scale
`
`empirical analyses of computer security incidents. I also regularly teach courses in
`
`computer and information security.
`
`8.
`
`I have published over 75 papers in prominent computer and
`
`communications security publications. My research has received numerous
`
`awards, including the Best Student Paper Award (IEEE Symposium on Security &
`
`Privacy, July, 2013), the Outstanding Research in Privacy Enhancing Technologies
`
`Award (July, 2012), the AT&T Best Applied Security Paper Award (NYU-Poly
`
`CSAW, Nov., 2011), and the Best Paper Award (IEEE Symposium on Security &
`
`Privacy, May, 2011), among others. My research has also received corporate
`
`sponsorship, including two Google Faculty Research Awards (2009, 2011) for my
`
`work on network security and computer forensics, as well as an award from
`
`Verisign Inc. (2012) for my work on DNS.
`
`9.
`
`I am the sole inventor or a co-inventor on three issued US patents and
`
`four pending patent applications, nearly all of which relate to network and systems
`
`security. Over the past 12 years, I have been the lead investigator or a
`
`co-investigator on grants totaling nearly nine million US dollars from the National
`
`Science Foundation (NSF), the Department of Homeland Security (DHS), the
`
`Department of Defense (DoD), and industry. In 2014, I was invited to serve on the
`
`Information Science and Technology (ISAT) study group for the Defense
`
`8
`
`Page 8 of 64
`
`
`
`Case No. IPR2015-00811
`
`Advanced Research Projects Agency (DARPA). During my
`
`three year
`
`appointment, I will assist DARPA by providing continuing and independent
`
`assessment of the state of advanced information science and technology as it
`
`relates to the U.S. Department of Defense.
`
`10.
`
`I have chaired several international conferences and workshops,
`
`including for example, the USENIX Security Symposium, which is the premier
`
`systems-security conference for academics and practitioners alike. Additionally, I
`
`have also served as Program Chair for the USENIX Workshop on Hot Topics in
`
`Security, the Program Chair for the USENIX Workshop on Large-scale Exploits &
`
`Emergent Threats, the local arrangements Chair for the Financial Cryptography
`
`and Data Security Conference, and the General Chair of the Symposium on
`
`Research in Attacks and Defenses. As a leader in the field, I have also served on
`
`numerous technical program committees including the Research in Attacks,
`
`Intrusions, and Defenses Symposium (2012, 2013), USENIX Security Symposium
`
`(2013, 2005-2009), Financial Cryptography and Data Security (2011, 2012),
`
`Digital Forensics Research Conference (2011, 2012), ACM Conference on
`
`Computer and Communications Security (2009-2011, 2013), IEEE Symposium on
`
`Security and Privacy (2007, 2008), ISOC Network & Distributed System Security
`
`(2006—2009), International Conference on Distributed Computing Systems (2005,
`
`9
`
`Page 9 of 64
`
`
`
`Case No. IPR2015-00811
`
`2009, 2010), and USENIX Workshop on Large-scale Exploits and Emergent
`
`Threats (2010-2012).
`
`11. From 2006 to 2009, I served as an Associate Editor for IEEE
`
`Transactions on Information and Systems Security (the leading technical journal
`
`on cyber security), and currently serve on the Steering Committee for the USENIX
`
`Security Symposium.
`
`12. My curriculum vitae, which is appended, details my background and
`
`technical qualifications. Although I am being compensated at my standard rate of
`
`$450/hour for my work in this matter, the compensation in no way affects the
`
`statements in this declaration.
`
`IV. Level of Ordinary Skill
`13.
`I am familiar with the level of ordinary skill in the art with respect to
`
`the inventions of the ’705 patent as of what I understand is the patent’s early-2000
`
`priority date. Specifically, based on my review of the technology, the educational
`
`level of active workers in the field, and drawing on my own experience, I
`
`believe a person of ordinary skill in art at that time would have had a master’s
`
`degree in computer science or computer engineering, as well as two years of
`
`experience in computer networking with some accompanying exposure to network
`
`security. My view is consistent with VirnetX’s view that a person of ordinary skill
`
`in the art requires a master’s degree in computer science or computer engineering
`
`10
`
`Page 10 of 64
`
`
`
`Case No. IPR2015-00811
`
`and approximately two years of experience in computer networking and computer
`
`security. I have been asked to respond to certain opinions offered by Dr. Roberto
`
`Tamassia, consider how one of ordinary skill would have understood certain claim
`
`terms, and consider how one of ordinary skill in the art would have understood the
`
`references mentioned above in relation to the claims of the ’705 patent. My
`
`findings are set forth below.
`
`V. Claim Terms
`14.
`I understand that in an inter partes review proceeding, the claims of a
`
`patent are construed under the broadest reasonable interpretation in light of the
`
`specification. I also understand that the parties have proposed constructions for
`
`certain terms of the ’705 patent. Unless otherwise noted, I have used Patent
`
`Owner’s proposed constructions in my analysis. In my opinion, Patent Owner’s
`
`proposed constructions are consistent with the specification. To the extent Patent
`
`Owner has not proposed a construction for a term, I understand that term to have
`
`its plain and ordinary meaning from the perspective of one of ordinary skill in the
`
`art in light of the specification. I have applied this understanding in my analysis.
`
`A.
`15.
`
`“Secure Domain Name” (Claims 3, 10, and 25)
`
`I understand that the parties and the Board have put forth the following
`
`constructions for purposes of this proceeding:
`
`11
`
`Page 11 of 64
`
`
`
`VimetX’s Proposed
`
`Construction
`
`Apple’s Proposed
`
`Construction
`
`Case No. IPR2015-0081 1
`
`name service DNS
`
`A non-standard domain
`name that corresponds to
`a secure computer
`network address and
`
`cannot be resolved by a
`conventional domain
`
`A name that corresponds
`to a secure computer
`network address
`
`No construction proposed
`
`16. The specification teaches
`
`that a “secure domain name” is “a
`
`nonstandard domain name.” (Ex. 1001 at 7:29-31; 50:22-31.) Examples of “a
`
`nonstandard domain name” are provided in the specification: .scom,
`
`.snet,
`
`.sorg,
`
`.sedu,
`
`.smil, and .sgov.
`
`(Id. at 7:39-42.) The specification also explains that a
`
`“secure domain name” “corresponds to a secure computer network address,”
`
`stating that “SDNS 3313 contains a cross-reference database of secure domain
`
`names and corresponding secure network addresses.” (Id. at 5116-10.)
`
`17. Because a “secure domain name” is “a non-standard domain name,”
`
`the specification explains that “a query to a standard domain name service (DNS)
`
`will return a message indicating that the universal resource locator GIRL) is
`
`unknown.” (Id. at 50:32-35; Figs. 33, 34.) One of ordinary skill in the art would
`
`understand based on the disclosure of the ’705 patent that to obtain the URL for a
`
`“secure domain name,” “a secure domain name service (SDNS)” must be queried.
`
`(Id. at 51:35-38; Figs. 33, 34.)
`
`Page 12 of 64
`
`12
`
`
`
`Case No. IPR2015-0081 1
`
`B.
`
`“Encrypted Communications Channel” Phrases (Claims 1, 2, 4-7,
`9, 11-13, 18, 21, 22, and 26-29)
`
`18.
`
`I understand that the parties and the Board have put forth the following
`
`constructions for purposes of this proceeding:
`
` VimetX’s Proposed
`
`Decision’s Construction
`
`Construction
`
`Apple’s Proposed
`Construction
`
`A direct communications No construction proposed No construction proposed
`channel that is encrypted
`
`19. One of ordinary skill in the art would understand that the ’705 patent
`
`describes encrypted communications that are direct between a client device and a
`
`target device. For instance, in one embodiment, the ’705 patent describes the
`
`communication between an originating TARP terminal and a destination TARP
`
`terminal as direct.
`
`(See, e.g., Ex. 1001, 9:41-50, Fig. 2; see also id. at 33:43-51
`
`(describing a variation of the TARP embodiments as
`
`including a direct
`
`communication link); 38:6-9 (describing the embodiment of Figure 24 in which a
`
`first computer and second computer are connected directly).) The ’705 patent
`
`similarly describes direct encrypted communications in later embodiments as well.
`
`(See, e.g., id. at 4017-10, 40:66-41:2 (describing a virtual private network as being
`
`direct between a user’s computer and target), 42:6-10, 42:66-43:3 (describing a
`
`load balancing example in which a virtual private network is direct between a first
`
`host and a second host), 48:66-49:1, 49:10-22 (describing a secure communication
`
`Page 13 of 64
`
`13
`
`
`
`Case No. IPR2015-0081 1
`
`link that is direct between a first computer and a second computer), Figs. 24, 26,
`
`28, 29, 33.)
`
`20.
`
`In each of these embodiments, the ’705 patent specification discloses
`
`that the communication traverses a network (or networks) through which it is
`
`simply passed or routed via various network devices such as Internet Service
`
`Providers, firewalls, and routers. (See, e.g., id. at Figs. 2, 24, 28, 29, 33.)
`
`C.
`
`“Provisioning Information” (Claims 1, 9, and 21)
`
`21.
`
`I understand that the parties and the Board have put forth the following
`
`constructions for purposes of this proceeding:
`
`VirnetX’s Proposed
`Construction
`
`Apple’s Proposed
`Construction
`
`Decision’s Construction
`
`network uses enc tion
`
`Information that is used
`
`Information that enables
`
`Information that is
`
`to establish an encrypted
`communications channel
`
`communication in a
`virtual private network,
`where the virtual private
`
`provided to enable or aid
`in establishing a secure
`communications charmel
`
`22.
`
`In my opinion, Patent Owner’s construction is consistent with the
`
`general notion that provisioning refers to setting up or establishing a connection or
`
`service.
`
`One dictionary explains
`
`that provisioning is
`
`“[s]etting up a
`
`telecommunications service for a particular customer,” and that “[c]ommon
`
`carriers provision circuits by programming their computers to switch customer
`
`lines into the appropriate networks.”
`
`(Ex. 2007 at 6, McGraw—HilI Computer
`
`Desktop Encyclopedia (9th ed. 2001).) Applying these principles to provisioning
`
`Page 14 of 64
`
`14
`
`
`
`Case No. IPR2015-00811
`
`in the context of the ’705 patent, encrypted communications channel provisioning
`
`refers to setting up or establishing an encrypted communication channel. Thus, in
`
`the context of the ’705 patent, the “provisioning information” is “information that
`
`is used to establish an encrypted communications channel.”
`
`23.
`
`In my opinion, in the context of the ’705 patent, one of ordinary skill in
`
`the art would not understand provisioning information to encompass any and all
`
`information that merely “enables or aids in” communication using an encrypted
`
`communications channel, as that information may have nothing to do with
`
`provisioning. For example, information that simply enabled or aided in
`
`communication using an encrypted communications channel would encompass
`
`source and destination information for individual packets of data that are traveling
`
`over a pre-existing channel. One of ordinary skill in the art would not have
`
`understood a channel to be provisioned every time a data packet is sent across it.
`
`D. Other Terms
`24.
`I understand that the parties and Board have provided the following
`
`constructions for purposes of this proceeding. I agree that the claim language
`
`encompasses the features described in each of VirnetX’s constructions.
`
`15
`
`Page 15 of 64
`
`
`
`Case No. IPR2015-0081 1
`
`“Intercept[ing] . . . A Request to Look up an Inlternet Protocol (IP) address”
`Claims 1 and 21
`
`VirnetX’s Proposed
`Construction
`
`Petitioner’s Proposed
`Construction
`
`Board’s Construction
`
`No construction proposed
`
`Receiving a request
`No construction
`pertaining to a first entity
`necessary; alternatively,
`receiving a request to look at another entity
`up an intemet protocol
`address and, apart from
`resolving it into an
`address, performing an
`evaluation on it related to
`
`establishing an encrypted
`communications channel
`
`Construction
`
`Construction
`
`a network address
`
`an IP address
`
`1 Step 2 of claims 1 and 21 recites “the request to look up the IP address
`
`transmitted in step (1)” instead of “intercepted in step (1).” (Ex. 1001 at 55:53-54,
`
`5711-2; see Ex. 1002 at 638, 639, 641, 655-56.) I understand this was an error and
`
`that Patent Owner filed a Certificate of Correction to correct this mistake.
`
`Page 16 of 64
`
`16
`
`
`
`Case No. IPR2015-0081 1
`
`No construction proposed
`
`6, 11, 12, 27 and 28
`
`Construction
`
`Construction
`
`A communication
`No construction
`necessary, alternatively, a medium for transmitting
`transmission link for
`data that is encoded by
`transmitting data that is
`varying a carrier signal /
`encoded by varying a
`A communication
`carrier signal / A
`medium for transmitting
`transmission link for
`data that is not encoded
`
`transmitting data that is
`not encoded by varying a
`carrier si al
`
`by varying a carrier signal
`
`“Phone” Claims 8 15 30 and 32
`
`VirnetX’s Proposed
`Construction
`
`Petitioner’s Proposed
`Construction
`
`No construction necessary A device or component
`that can provide
`tele hon functionali
`
`Board’s Construction
`
`No construction proposed
`
`VI. Aventail and RFC 2401
`
`A.
`
`Aventail’s Disclosure
`
`25. Aventail is an administrator’s guide for configuring Aventail Connect,
`
`which is an application designed to run on a workstation and which routes network
`
`Page 17 of 64
`
`17
`
`
`
`Case No. IPR2015-00811
`
`traffic from an application to a proxy server (the Extranet (SOCKS) server)2. (Ex.
`
`1009 at 7-9.) The SOCKS server “sends the traffic to the Internet or the external
`
`network.” (Id. at 7.) Certain traffic may be routed through the SOCKS server so
`
`that a remote host may be accessed. (Id. at 6-7.)
`
`26. The operation of Aventail Connect is described on pages 11-13, under
`
`the heading “How Does Aventail Connect Work?” Pages 11-12 of Aventail
`
`discloses steps including “actions and options introduced by Aventail Connect,”
`
`which are recreated below. (Id. at 11.)
`
`
`
`
`2 Aventail interchangeably uses the term “Extranet (SOCKS) server” and “SOCKS
`
`server.” (See, e.g., Ex. 1009 at 7, 12.) Furthermore, the Petition refers to the same
`
`server as the “Aventail Extranet Server.” (See, e.g., Pet. at 19; see also Ex.
`
`[Tamassia Depo] at 200:10-15, confirming that the “Aventail extranet server is a
`
`server that operates according to the SOCKS protocol.”) For ease of reference, I
`
`use the term “SOCKS server” to refer to the Extranet (SOCKS) server and the
`
`Aventail Extranet Server.
`
`18
`
`Page 18 of 64
`
`
`
`Case No. IPR2015-00811
`
`
`
`
`
`(Id. at 11-12.)
`
`19
`
`Page 19 of 64
`
`
`
`Case No. IPR2015-00811
`
`As explained by Aventail, first, a “DNS lookup” is received at Aventail Connect
`
`from a client application. (Id. at 11.) If the destination hostname in the DNS
`
`lookup “matches a redirection rule” or the “DNS proxy option is enabled and the
`
`domain cannot be looked up directly,” a “false DNS entry” is created by Aventail
`
`Connect and returned to the client application. (Id. at 12.) A redirection rule
`
`defines, for a destination (e.g., a remote host), what type of traffic (i.e., TCP and/or
`
`UDP) will be allowed to be routed to that destination, and the type of proxy
`
`redirection. (Id. at 38-40.) In the proxy redirection field, the administrator can
`
`specify one of three options (see table below):
`
`
`
`(Id. at 40.)
`
`27. The above actions occur in step 1 as recited in Aventail. (Id. at 11-12.)
`
`In step 2, the client application requests a connection to the remote host and this
`
`connection request is checked by Aventail Connect. (Id. at 12.) The connection
`
`request may contain a previously-created “false DNS entry” that indicates whether
`
`the connection should be proxied. (Id.) The connection request, however, does not
`
`20
`
`Page 20 of 64
`
`
`
`Case No. IPR2015-00811
`
`include a domain name. (Id.) When such a “connection is completed,” the
`
`SOCKS negotiation process “begins,” resulting in a connection to the “extranet
`
`(SOCKS) server.” (Id.) During the SOCKS negotiation, Aventail Connect sends a
`
`list of authentication methods enabled in its configuration file and once the
`
`SOCKS Server selects one of the authentication methods, “Aventail Connect
`
`executes the specified authentication processing.” (Id.) Aventail Connect “then
`
`sends the proxy request to the extranet (SOCKS) server” (emphasis added) and the
`
`proxy request includes “either the IP address provided by the application or the
`
`DNS entry (hostname) . . . .” (Id.)
`
`28. The application then transmits and receives data in step 3. (Id.) In step
`
`3, “[i]f an encryption module is enabled and selected by the SOCKS server,
`
`Aventail Connect encrypts the data on its way to the [Extranet] server on behalf of
`
`the application.” (Id.) Here, Aventail Connect only encrypts data through to the
`
`SOCKS server-not the remote host-and that too if encryption is required by the
`
`SOCKS server.
`
`B. Claims 1 and 21
`1. “Determining Whether the Request to Look Up an IP Address
`Transmitted [Intercepted] in Step 1 Corresponds to a Device
`That Accepts an Encrypted Channel Connection with the
`Client Device”
`I understand that independent claim 1 recites, inter alia, “determining
`
`29.
`
`whether the request to look up an IP address transmitted [intercepted] in step 1
`
`21
`
`Page 21 of 64
`
`
`
`Case No. IPR2015-00811
`
`corresponds to a device that accepts an encrypted channel connection with the
`
`client device.” I understand that independent claim 21 recites a similar feature. I
`
`understand that Petitioner contends that Aventail discloses this feature. (Pet. at 33-
`
`35.) Petitioner contends that the claimed “determining” is disclosed by Aventail
`
`because Aventail discloses determining whether a domain name specified in a
`
`connection request (alleged “intercepted DNS request,” see id. at 32) matches a
`
`domain name of a remote host in Aventail Connect’s table of redirection rules.
`
`(Pet at. 33-35, citing Ex. 1009 at 8-9, 11-12, 40.) According to Petitioner,
`
`“inclusion of the remote host in the redirection rule table . . . enables the Aventail
`
`Connect client to determine if the remote host will accept an encrypted
`
`connection” (Id. at 34, citing Ex. 1009 at 8-9, 11-12, 40 and Ex. 1005 at ¶ 237.)
`
`Both of these propositions are, however, not correct in my opinion.3
`
`
`3 In my analysis, I also refer to two marked-up exhibits (2013 and 2014) that were
`
`created during the deposition of Petitioner’s proposed expert, Dr. Tamassia. (Ex.
`
`2015 at 247:9-248:23.) Exhibit 2013 is a marked-up version of pages 11 and 12 of
`
`Aventail (Ex. 1009) that has each step labeled. Exhibit 2014 is a marked-up
`
`version of the flowchart from Dr. Tamassia’s declaration (Ex. 1005 at ¶ 218) that
`
`has each step labeled and sets forth Dr. Tamassia’s “general overall understanding
`
`of the methodology that is employed by Aventail.” (Ex. 2015 at 187:4-9.)
`
`22
`
`Page 22 of 64
`
`
`
`Case No. IPR2015-00811
`
`30. Petitioner’s first proposition is incorrect because a domain name is
`
`never specified in the connection request. Instead, the connection request
`
`includes an IP address, which is either the fake IP address that was previously
`
`returned by Aventail Connect (in step 1), a routable IP address, or a real IP
`
`address. (See supra section VI.A; Ex. 1009 at 12; Ex. 2013 (steps 2, 2a(1), 2a(2),
`
`2a(3), 2a(4)).) During his deposition, Dr. Tamassia indicated that Box G in his
`
`flowchart is the beginning of step 2 in Aventail, which is the step reciting the
`
`“connection request.” (Ex. [Tamassia Depo] at 234:8-9; Ex. 1009 at 12; Ex. 2013
`
`(step 2).) As seen from the flowchart (recreated below with emphasis), Dr.
`
`Tamassia acknowledges that the connection request referenced in step 2 of
`
`Aventail and as set forth in Box G only has an IP address and not a domain name.
`
`(Ex. 2014.)
`
`23
`
`Page 23 of 64
`
`
`
`Case No. IPR2015-00811
`
`
`
`(Ex. 2014, annotated in red.)
`
`31. To the extent that the Petitioner relies on the “proxy request” referred
`
`to in step 2b of Aventail (see e.g., Ex. 1009 at 12; Ex. 2013 (step 2b(3)) rather than
`
`the “connection request” because the “proxy request” may include a hostname, that
`
`does not disclose the “determination” limitation of claim 1. The proxy request of
`
`24
`
`Page 24 of 64
`
`
`
`Case No. IPR2015-00811
`
`step 2b(3) of Aventail is sent as part of the SOCKS negotiation, which “begins”
`
`“when the connection is completed.” (Ex. 1009 at 12; Ex. 2013 (step 2b).) The
`
`SOCKS negotiations occur after “Aventail Connect checks the connection
`
`request.” (Ex. 1009 at 12; Ex. 2013 (step 2a).) And this checking of the
`
`connection request occurs after the connection request is received in step 2. (Ex.
`
`1009 at 12; Ex. 2013 (steps 2, 2a).)
`
`
`
`(Ex. 2013 at 2, excerpt.) (See also Ex. 1009 at 12.)
`
`32. One of ordinary skill in the art would have thus understood that
`
`Aventail discloses that the proxy request, which is sent after the connection is
`
`completed, is never matched against a redirection rules table because the matching
`
`25
`
`Page 25 of 64
`
`
`
`occurs earlier in step 1b of Aventail and the proxy request is not even sent until
`
`step 2b(3). (Ex. 1009 at 11-12; Ex. 2013.)
`
`Case No. IPR2015-00811
`
`
`
`
`
`(Ex. 2013 at 1-2, excerpt.) (See also Ex. 1009 at 11-12; Ex. 2014.) Dr. Tamassia’s
`
`flowchart appears to be consistent with this understanding. (See Ex. 2013; Ex.
`
`2015 at 226:1-10 (indicating that Dr. Tamassia’s Box H in Ex. 2014 is related to
`
`step 1B of Ex. 2013), id. at 194:23-195:5 (indicating that Dr. Tamassia’s Box N in
`
`Ex. 2014 is related to step 2b(3) of Ex. 2013).
`
`33. Based on the disclosure of Aventail, one of ordinary skill in the art
`
`would have realized that neither the connection request nor the proxy request
`
`disclosed n Aventail is matched against the redirection rules table.
`
`34.
`
`I understand that Petitioner’s second proposition as to why Aventail
`
`allegedly discloses the “determining” limitations of ’705 patent is that “inclusion
`
`of the remote host in the redirection rule table . . . enables the Aventail Connect
`
`client to determine if the remote host will accept an encrypted connection.” (Pet.
`
`at 34, emphasis added.) I also understand that in its institution decision, the Board
`
`also stated that for Aventail to disclose the “determining” step, “[a]ll that is
`
`26
`
`Page 26 of 64
`
`
`
`Case No. IPR2015-00811
`
`required is that the target device accepts an encrypted communication.” (Decision
`
`at 19.) I disagree with these positions. To begin with, Aventail does not disclose a
`
`remote host accept