IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`In re Inter Partes Reexamination of:
`
`Edmund Munger et al.
`
`)
`)
`) Control No.: 95/001,682
`)
`) Group Art Unit: 3992
`)
`) Examiner: Behzad Peikari
`)
`For: AGILE NETWORK PROTOCOL FOR SECURE ) Confirmation No.: 1074
`COMMUNICATIONS WITH ASSURED
`)
`SYSTEM AVAILABILITY
`)
`
`U.S. Patent No. 6,502,135
`
`Issued: December 31, 2002
`
`Mail Stop Inter Partes Reexam
`Commissioner for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`Declaration of Angelos D. Keromytis, Ph.D.
`
`I declare that the following statements are true to the best of my knowledge, information. and
`
`belief, formed after reasonable inquiry under the circumstances.
`
`I, ANGELOS D. KEROMYTIS, declare as follows:
`
`1.
`
`I have been retained by VirnetX Inc. (''VirnetX'') for
`
`the above-referenced
`
`reexamination proceeding. I understand that this reexamination involves U.S. Patent No. 6,502,135
`
`("the '135 patent"). I further understand that the '135 patent is assigned to VirnetX and that it is part
`
`of a family of patents ("Munger patent family") that stems from U.S. provisional application nos.
`
`60/106,261 ("the
`
`'261 application"), filed on October 30, 1998, and 601137,704 ('"the "704
`
`application"), filed on June 7, 1999. I also understand that the '135 patent is a continuation-in-pat1 of
`
`U.S. application no. 09/429,643 (now U.S. Patent No. 7,010,604). which claims priority to the "261
`
`and '704 applications.
`
`I.
`
`RESOURCES I HAVE CONSULTED
`
`2.
`
`I have reviewed the '135 patent, including claims 1-18.
`
`I have also reviewed a
`
`Request for Inter Partes Reexamination of the "135 patent filed by Apple Inc. with the U.S. Patent
`
`- 1 -
`
`Petitioner RPX Corporation - Ex. 1052, p. 1
`
`

`

`Control No.: 95/001,682
`Declaration of Angelos D. Keromytis, Ph.D.
`
`and Trademark Office on July 11, 2011 ("Request" or "Reg."), as well as its accompanying exhibits. 1
`
`Additionally, I have reviewed an Order Granting Request for Inter Partes Reexamination of the '135
`
`patent ("the Order") mailed on October 3, 2011, and an Office Action ("the Office Action") mailed
`
`on February 15, 2012?
`
`3.
`
`I have also studied the following documents cited in and included with the Request
`
`and/or Office Action: Aventail Connect v3.1/2.6 Administrator's Guide (Reg. Ex. XI) (hereinafter
`
`"Aventail v3.1"); Aventail Connect v3.01/2.51 Administrator's Guide (Reg. Ex. X2) (hereinafter
`
`"Aventail v3.01"); AutoSOCKS v2.1 Administrator's Guide
`
`(Req. Ex. X3)
`
`(hereinafter
`
`"AutoSOCKS''); Wang, Broadband Forum TR-025: Core Network Architecture Recommendations
`
`For Access to Legacy Data Networks over ADSL, Issue 1.0 ("Wang"); U.S. Patent Number
`
`6,496,867 ("Beser"); Kent, "Security Architecture for IP ," RFC 2401 ("Kent"); Reed, ''Proxies for
`
`Anonymous Routing", 12th Annual Computer Security Applications Conference ("Reed'); BinCJOl
`
`User's Guide and BinGO! Extended Feature Reference ("BinGO''); U.S. Patent Number 6,615,357
`
`("Boden"); U.S. Patent Number 6,182,141 ("Blum"); U.S. Patent Number 4,885,778 ("Weiss'');
`
`Goldschlag et al., "Hiding Routing Information," ("Goldschlag"); Ferguson et al., "What Is a VPN,"
`
`("Ferguson"); RFC 1034, "Domain Names-Concepts and Facilities" ("RFC 1034"); RFC 1035,
`
`"Domain Names-Implementation and Specification" ("RFC 1 035"); RFC 1123, "Requirements for
`
`Internet Hosts-Applications and Support" ("RFC 1123"); RFC 2068, ''Hypertext Transfer Protocol
`
`- HTTP/1.1" (''RFC 2068"); RFC 1928, "Socks Protocol Version 5" (''RFC 1928''); RFC 1180, "A
`
`TCP/IP Tutorial" ("RFC 1180"); RFC 1661, "The Point-to-Point Protocol (PPP)'' ("RFC 1661 ");
`
`RFC 1968, "The PPP Encryption Control Protocol (ECP)" ("RFC 1968"); RFC 2420, ''The PPP
`
`Triple-DES Encryption Protocol (3D ESE)" ("RFC 2420"); RFC 2661, "Layer Two Tunneling
`
`Protocol
`
`'L2TP"' ("RFC 2661 "); RFC 2118, "Microsoft Point-To-Point Encryption (MPPE)
`
`Protocol" ("RFC 2118"); RFC 2364, "PPP Over AAL5" ("RFC 2364"); RFC 2663, "IP Network
`
`Address Translator (NAT) Terminology and Considerations" ("RFC 2663''); and RFC 1483,
`
`1 I refer
`the Request for Inter Partes Reexamination as "the Request'' and,
`to
`correspondingly, I will refer to Apple Inc. as "the Requester."
`
`2 The Office Action incorporates nearly all of the Request by reference. For that reason,
`when I sometimes refer to "the Request," I am also referring to the Office Action.
`
`- 2 -
`
`Petitioner RPX Corporation - Ex. 1052, p. 2
`
`

`

`Control No.: 95/001,682
`Declaration of Angelos D. Keromytis, Ph.D.
`
`"Multiprotocol Encapsulation over A TM Adaption Layer 5" ("RFC 1483").3
`
`4.
`
`I am familiar with the level of ordinary skill in the art with respect to the inventions
`
`of the '135 patent as of February 15, 2000, when the application for the '135 patent was filed.
`
`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.
`
`5.
`
`I have been asked to consider how one of ordinary skill in the art would have
`
`understood the references mentioned above. My findings are set forth below.
`
`II.
`
`QUALIFICATIONS
`
`6.
`
`I have a great deal of experience and familiarity with computer and network security,
`
`and have been working in this field since 1993.
`
`7.
`
`I am currently an Associate Professor of Computer Science at Columbia University,
`
`as well as Director of the University's Network Security Laboratory. I joined Columbia in 2001 as
`
`an Assistant Professor, after receiving my M.Sc. and Ph.D. degrees in Computer Science, both from
`
`the University of Pennsylvania. My Ph.D. dissertation work was on the topic of secure access
`
`control for distributed systems and, in particular, on the management of trust in distributed computer
`
`networks.
`
`8.
`
`I received my B.Sc. in Computer Science from the University of Crete, in Greece, in
`
`1996. During my undergraduate studies, I worked as system administrator in the Computing Center
`
`at the University of Crete. Following that, I worked as network engineer at the first commercial
`
`Internet Service Provider ("ISP") in Greece, FORTHnet SA, where I was exposed to many network
`
`security issues.
`
`9.
`
`have actively participated in the Internet Engineering Task Force ("IETF''), a
`
`standards-setting body for the Internet, since 1995. In the late 1990s and early 2000s, my work with
`
`the IETF was primarily within the Internet Protocol Security ("IPsec") Working Group. In addition
`
`to contributing to the specification of the IPsec standards, I wrote the first implementation of the
`
`3 Although I listed dates in these citations, I am not testifying to whether any of these
`references were actually publicly distributed on the date listed.
`
`- 3 -
`
`Petitioner RPX Corporation - Ex. 1052, p. 3
`
`

`

`Control No.: 95/001,682
`Declaration of Angelos D. Keromytis, Ph.D.
`
`Photuris key management protocol (now RFC 2522).
`
`I also contributed to the first open-source
`
`implementation of the IKSAMP/IKE key management protocol for the open-source BSD operating
`
`system (now RFC 2409), and developed the first such implementation for the Linux operating
`
`system. My Linux implementation, named Pluto, was adopted by the National Institute of Standards
`
`and Technology ("NIST") in 1999.
`
`In addition, my implementation of IPsec for the open-source
`
`BSD operating system is currently used by many companies and governments around the world, and
`
`serves as the basis for several commercial products that employ cryptographic communications. In
`
`1999, I architected and implemented the first open-source framework for supporting hardware
`
`cryptographic accelerators. This framework is used in the open-source OpenBSD, NetBSD,
`
`FreeBSD, and Linux operating systems. My work in implementing firewalls and other cryptographic
`
`and network protocols has resulted in commercial systems and publications in refereed technical
`
`conferences and academic journals.
`
`I served as Working Group Secretary for the IETF IPsec
`
`Working Group (2003-2005) and as Security Area Advisor to the IETF at large (2003-2008).
`
`I 0.
`
`In my current position at Columbia University, I work with a large group of graduate
`
`and postgraduate students in the area of cybersecurity. My past students now work in this field as
`
`university professors, as technical researchers for research
`
`laboratories, or as engineers for
`
`telecommunications companies. I have received federal, state, and corporate sponsorship to conduct
`
`cybersecurity research from the Department of Defense, the National Security Agency, the Defense
`
`Advanced Research Projects Agency ("DARPA"), the National Science Foundation, the Department
`
`of Homeland Security, the Air Force, the Office for Naval Research, the Army Research Office, the
`
`Department of the Interior, the National Reconnaissance Office, New York State, Google, Intel,
`
`Cisco, and others. In my ten years as a professor, I have received over 36 million dollars to support
`
`my research in cybersecurity. I also regularly teach courses on cybersecurity, in addition to more
`
`general courses in computer science.
`
`11.
`
`I have published over 200 technical papers in refereed journals, conferences, and
`
`workshops, all of which are directed to various areas of cybersecurity. I have also authored a book,
`
`coauthored another book, and contributed chapters for many other books that relate to cybersecurity.
`
`Between 1999 and 20 I 0, I have drafted or codrafted eight standards documents that were pub! ished
`
`as Request for Comments ("RFCs"). Several of these RFCs are directly related to IP security. For
`
`example, RFC 6042 relates to transport layer security; RFC 5708, RFC 2792, and RFC 2704 relate to
`
`key signature and encoding for trust management; and RFC 3586 relates to IP security policy
`
`requirements. Additionally, I am a coinventor on twelve issued U.S. patents, and have several other
`
`-4-
`
`Petitioner RPX Corporation - Ex. 1052, p. 4
`
`

`

`Control No.: 95/001,682
`Declaration of Angelos D. Keromytis, Ph.D.
`
`applications pending. Most of these patents and pending applications are related to network and
`
`systems security.
`
`12.
`
`have chaired several
`
`international
`
`technical conferences and workshops
`
`in
`
`cybersecurity, including, for example, the International Conference on Financial Cryptography and
`
`Data Security (FC), ACM Computer and Communication Security (CCS), and the New Security
`
`Paradigms Workshop (NSPW). I have also served in over eighty technical program committees for
`
`such events. From 2004-2010, I served as Associate Editor for the premier technical journal on
`
`cybersecurity-the ACM Transactions on
`
`Information and Systems Security
`
`(TISSEC).
`
`Additionally, I have served on several advisory workshops to the United States Government on
`
`cybersecurity, including, among others, the Office of the Director of National Intelligence
`
`(ODNI)/National Security Agency (NSA) Invitational Workshop on Computational Cybersecurity in
`
`Compromised Environments (C3E) (2011 ), the Office of Naval Research (ONR) Workshop on Host
`
`Computer Security (2010), the Intelligence Community Technical Exchange on Moving Target
`
`(20 1 0), Lockheed Martin Future Security Threats Workshop (2009), and the ARO/FSTC Workshop
`
`on Insider Attack and Cyber Security.
`
`13.
`
`In addition to this work, I have cofounded two companies in cybersecurity. One
`
`company, StackSafe Inc. (formerly Revive Systems Inc.), was a provider of a virtualized
`
`preproduction staging environment that includes automated testing, analysis, and reporting for IT
`
`operations teams.
`
`I was with this company from its founding in 2005 until 2009. The second
`
`company, Allure Security Technologies (founded in 201 0), develops deception-based solutions for
`
`detecting and mitigating the malicious cyber-insider threat, commercializing technology developed at
`
`Columbia through DHS and DARPA grants and a DARPA SBIR contract.
`
`14.
`
`My curriculum vitae, which is appended to this declaration, details my background
`
`and technical qualifications. Although I am being compensated at my standard rate of $500/hour for
`
`my work on this declaration, the compensation in no way affects the statements in this declaration.
`
`III.
`
`BACKGROUND OF THE '135 PATENT
`
`15.
`
`Before turning to a discussion of the references relied on in the Request and the
`
`Office Action, I summarize my understanding of certain embodiments disclosed in the '135 patent.
`
`Generally speaking, the '135 patent discloses embodiments relating to establishing virtual private
`
`networks (VPNs) and/or virtual private links between devices connected to a network. For example,
`
`certain embodiments of the '135 patent may establish a VPN between a client computer and a target
`
`- 5 -
`
`Petitioner RPX Corporation - Ex. 1052, p. 5
`
`

`

`computer m response to a request received from the client computer for a network address
`
`corresponding to a domain name associated with the target computer. (' 135 patent 37:63-39:41.)
`
`Control No.: 95/001,682
`Declaration of Angelos D. Keromytis, Ph.D.
`
`2701
`
`RECEI'IEONS
`REQUEST FOil
`TARGET SIT£:
`
`t
`
`r<O
`
`~EQIJEST£01
`
`YES
`
`211)3
`!
`PA.-'tSTHRII
`REOUESfTO
`DlxS SHiVER
`
`2702 ~ '-< ~CliRE SiTE
`{--
`~',0:
`~~ .
`USER
`RETURN
`.. 1 'liOST UNKNO'Mt
`0
`"./AUTHORIZED ro
`1<
`~ CONNECT?/
`ERROR
`
`"104
`'
`
`~·--
`
`.;
`!
`
`'
`
`FIG.
`
`2700·
`
`ESTABUSH
`\?tiW~
`TAR<;HSITE
`
`FIG. 27
`
`16.
`
`As shown in Figures 26 and 27 of the '135 patent, reproduced above, a computer
`
`2601 may generate a domain name service (DNS) request for an internet protocol (JP) address
`
`corresponding to a domain name of a target computer, such as secure target site 2604 and/or unsecure
`
`target site 2611. DNS proxy server 2610 may receive the DNS request from computer 260 I and
`
`determine whether the DNS request is requesting access to a secure web site. (' 135 patent 38:23-30,
`
`39:2:6.)
`
`17.
`
`If the DNS request is requesting access to a secure web site, DNS proxy server 2610
`
`may determine whether the user and/or computer 2601 is authorized to access the secure web site.
`
`('135 patent 38:25-30, 39:7-20.) If so, a VPN may be automatically initiated between computer 2601
`
`and secure target site 2604. (' 135 patent 38:30-43, 39:22-33.) In certain embodiments, this may
`
`include DNS proxy 2610 sending a request to create the VPN to a gatekeeper 2603; gatekeeper 2603
`
`may allocate resources for the VPN in response to the request. (' 135 patent 38:30-43.) The '135
`
`patent makes clear that the gatekeeper 2603 may be implemented separately from, or as a part of,
`
`modified DNS server 2602 that includes DNS proxy 2610. (' 135 patent 38:53-60.)
`
`18.
`
`If, on the other hand, the DNS request is requesting access to a non-secure website,
`
`DNS proxy server 2610 may pass the request through to conventional DNS server 2609, which may
`
`return the IP address ofunsecure target website 2611. (' 135 patent 38:43-52.)
`
`19.
`
`The claims of the' 135 patent are directed to some of these embodiments.
`
`- 6 -
`
`Petitioner RPX Corporation - Ex. 1052, p. 6
`
`

`

`Control No.: 95/001,682
`Declaration of Angelos D. Keromytis, Ph.D.
`
`IV.
`
`REFERENCES CITED
`
`A.
`
`20.
`
`Aventail
`
`Aventail v3.1 is an administrator's guide for configuring Aventail Connect, a client
`
`component of the Aventail ExtraNet Center, an extranet solution. (Aventail v3.1 3, 7.) Aventail
`
`Connect works in connection with extranet servers running the SOCKS protocol, including the
`
`Aventail ExtraNet Server, the SOCKS 5 server component ofthe Aventail ExtraNet Server. (Jd. at 7.)
`
`21.
`
`(1)
`
`Aventail v3.1 discloses two primary embodiments:
`
`Aventail Connect may be used to provide secure inbound access, i.e., allowing an
`organization to provide its mobile employees and partners secure access to the
`organization's private network, extranet, or LAN from remote locations over the
`Internet. (E.g., id. at 5, 7, 77.)
`
`(2)
`
`Aventail Connect may also be used as a simple proxy client for managed outbound
`access, e.g., from a corporate network to the Internet, through a SOCKS compliant
`server. (E.g., id. at 5, 7, 68.)
`
`22.
`
`In the first embodiment, Aventail Connect accesses the private network through the
`
`Aventail ExtraNet Server. (Id. at 77.) The Aventail ExtraNet Server restricts inbound access by
`
`allowing only authorized client computers running A ventail Connect to send or receive data to a
`
`computer on the private network, and provides an encrypted connection between the A ventail
`
`ExtraNet Server and the external client computer. (See, e.g., id. at 72).
`
`23.
`
`In the second embodiment, Aventail Connect may be configured to route certain
`
`traffic from a client computer running Aventail Connect to a SOCKS compliant proxy server to
`
`traverse a firewall and access a remote host beyond the firewall. (See id. at 6-7.)
`
`In some cases,
`
`multiple firewalls may be traversed using successive proxy servers (id. at 68-73). Routing is
`
`accomplished, in part, by an administrator first defining what SOCKS proxy servers that Aventail
`
`Connect may use when routing connections. (Id. at 35-37.) Any SOCKS compliant proxy server
`
`may be used.
`
`(See id. at 37 (figure depicting that a user may choose SOCKS v4, v5, or HTTP
`
`proxy).) The administrator then defines destinations (e.g., hostnames) that may be routed through the
`
`previously defined servers.
`
`(Jd. at 39.) After the destinations have been configured, the
`
`administrator may create redirection rules. A redirection rule defines, for a defined destination, what
`
`type of traffic (i.e., TCP and/or UDP) will be allowed to be routed to that destination, and which
`
`proxy server will be used to route that traffic. (Id. at 42-44.) The redirection rules may be arranged
`
`to prioritize how a destination will be handled. (Id. at 43.)
`
`- 7-
`
`Petitioner RPX Corporation - Ex. 1052, p. 7
`
`

`

`Control No.: 95/001,682
`Declaration of Angelos D. Keromytis, Ph.D.
`
`24.
`
`Based on my review, Aventail v3.01 and AutoSOCKS incorporates similar subject
`
`matter of, and is substantially similar to Aventail v3.1. Moreover, it is my understanding that many,
`
`if not all, of the allegations made by the Request and adopted by the Office Action with regard to
`
`Aventail v3.01 and AutoSOCKS are substantially similar to the allegations made with respect to
`
`Aventail v3.1. Therefore, for the purpose of this declaration I will refer to all three references
`
`collectively as "Aventail." All citations will be based on Aventail v3.1, but I will also refer generally
`
`to those sections of Aventail v3.01 and AutoSOCKS that disclose similar subject matter.
`
`25.
`
`I understand independent claim 1 to recite, among other things, "(3) in response to
`
`determining that the DNS request in step (2) is requesting access to a secure target web site,
`
`automatically initiating the VPN between the client computer and the target computer."
`
`26.
`
`I have been asked to assume that Aventail teaches a VPN, generally. Even if Aventail
`
`is viewed as showing a VPN, however, it is my opinion that Aventail still does not contain all of the
`
`features of claim 1. For example, in my opinion, Aventail does not disclose at least the feature of
`
`initiating a VPN in response to determining that a DNS request is requesting access to a secure target
`
`web site, as recited by step (3) of claim 1.
`
`27.
`
`The Request contends that if a hostname matches a redirection rule then a connection
`
`would be established between a client computer running A ventail Connect and the A ventail Extranet
`
`Server, and, if authentication was successful, the purported VPN would be established. (Req. at 43
`
`(citing Aventail v3.1 12.)
`
`28.
`
`The Request does not say how a DNS request is determined to be requesting access to
`
`a secure web site in Aventail. Rather, the Request points to two different things: ( 1) evaluating a
`
`hostname, and (2) evaluating a connection request. (Req. at 41) Thus, the Request is unclear as to
`
`what determines that a DNS request is requesting access to a secure target web site.
`
`29.
`
`If the Request is contending that evaluating a hostname against a redirection rule is a
`
`determination step then the only thing Aventail discloses in response to that determination is the
`
`creation of a false DNS request. Moreover, Aventail does not disclose that the false DNS entry
`
`initiates a connection request. Aventail teaches on page 12 that, in step 2, Aventail Connect merely
`
`"checks" an already existing connection request to determine whether the request contains a false
`
`DNS entry. Whether a completed connection is subsequently encrypted or not is not disclosed by
`
`Aventail as having anything to do with a DNS request, let alone "in response to determining that the
`
`DNS request in step (2) is requesting access to a secure target web site," as recited in claim 1.
`
`- 8 -
`
`Petitioner RPX Corporation - Ex. 1052, p. 8
`
`

`

`Control No.: 95/001,682
`Declaration of Angelos D. Keromytis, Ph.D.
`
`30.
`
`Similarly, in my opinion, evaluating the connection request for the presence of a false
`
`DNS entry in Aventail does not involve determining that a DNS request is requesting access to a
`
`secure target web site. A false DNS entry may be created irrespective of whether a target web site is
`
`determined to be secure or not. For example, a false DNS entry will be created as a result of
`
`selecting a DNS proxy option, i.e., to proxy all DNS lookups that cannot be looked up directly,
`
`whether for secure destinations or not. (See Aventail v3.1 12 (step 1, bullet point 3).) Moreover, a
`
`"false DNS entry" is not a DNS request.
`
`31.
`
`Aventail does not disclose that encryption (i.e., the purported VPN) is automatically
`
`initiated in response to determining that the DNS request in step (2) is requesting access to a secure
`
`target web site, as recited by claim 1. Aventail explains that encryption is initiated, if at all, ''[ w ]hen
`
`the connection is completed" to the SOCKS server. (Aventail v3.1 12 (step 2.b).) But Aventail does
`
`not teach any link between a DNS request and the encryption, much less that it is automatically
`
`initiated in response to determining that the DNS request in step (2) is requesting access to a secure
`
`target web site, as recited by claim 1.
`
`32.
`
`Furthermore, the Request contends that Aventail discloses the step of generating a
`
`DNS request that requests an IP address because A ventail Connect "automatically routes appropriate
`
`network traffic," and points to three different methods of how "A ventail Connect ... resolvel s]
`
`hostnames to yield IP addresses." (Req. at 39-40.) The first and third methods cited by the Request
`
`are disclosed as not being performed by the TCP/IP stack, and there is no suggestion that a
`
`subsequent connection would be made through a SOCKS server, much less be encrypted. (See
`
`Aventail v3.1 11, 45.) The second method, highlighted by the Request, is directed to A ventail
`
`Connect being configured to "send the hostname to a DNS server on another computer for
`
`resolution." (Req. at 40.)
`
`It appears that this is the method that the Request contends discloses a
`
`DNS request.
`
`33.
`
`However, page 12 of Aventail describes, in Step 1, that "Aventail Connect will
`
`forward the hostname to the extranet (SOCKS) server in step 2 and the SOCKS server performs the
`
`hostname resolution." (!d. at 12.) In Step 2, after "the connection is completed," and authentication
`
`processing executed, Aventail Connect "then sends the proxy request to the extranet (SOCKS) server
`
`[including] the DNS entry (hostname) provided in step 1." (!d.) Accordingly, what the Request
`
`points to as the request for an IP address is generated by Aventail Connect (from the client computer)
`
`after the establishment of what the Request points to as the VPN. Consequently, the purported VPN
`
`- 9 -
`
`Petitioner RPX Corporation - Ex. 1052, p. 9
`
`

`

`Control No.: 95/00 I ,682
`Declaration of Angelos D. Keromytis, Ph.D.
`
`is not initiated in response to a determination that the DNS request is requesting access to a secure
`
`target web site.
`
`34.
`
`It is my understanding that the Request also contends that the purported YPN is
`
`automatically established when traffic is proxied into a private network as a result of a determination
`
`made by Aventail Connect that the traffic should be redirected to the private network. (Req. at 42-
`
`43.) However, the cited portion of Aventail discloses that Aventail Connect proxies traffic into the
`
`private network "[d]epending on the security policy and the Aventail ExtraNet Server configuration."
`
`(Aventail v3.1 77.) The Request has not provided any reasoning as to how proxying a connection
`
`into a private network based on a policy or configuration includes a determination related to a DNS
`
`request.
`
`35.
`
`The Request further contends that a VPN is automatically established because the
`
`A ventail ExtraNet Server requires "all users to use A ventail Connect to authenticate and encrypt their
`
`sessions before any connection to the internal private network(s)." (Req. at 43 (citing Aventail v3.1
`
`78).) In my opinion, this just indicates that the encryption of Aventail occurs in response to receiving
`
`a connection, and does not teach any link between a DNS request and the encryption, much less that
`
`it is automatically initiated in response to determining that the DNS request in step (2) is requesting
`
`access to a secure target web site, as recited by claim 1.
`
`36.
`
`For these reasons, it is my opinion that the purported VPN of Aventail would not be
`
`automatically initiated in response to determining that a DNS request is requesting access to a secure
`
`target web site.
`
`37. With regard to claim 4, it is my opinion thatAventail does not disclose that step (3) of
`
`claim 1 comprises the step of, prior to automatically initiating the VPN between the client computer
`
`and the target computer, determining whether the client computer is authorized to establish a VPN
`
`with the target computer and, if not so authorized, returning an error from the DNS request. It is my
`
`understanding that the Request points to the Fratto declaration (Ex. E2) to try to show that the feature
`
`of claim 4 is disclosed by Aventail because Aventail "would inherently know how to handle errors
`
`returned according to the relevant DNS and TCPIIP communication protocols." (Req. at 47 (citing
`
`Ex. E2 (Fratto) at 136-42.) Nothing in Aventail discloses returning an error from a DNS request.
`
`The declaration discusses how a "DNS response" could be returned with a RCODE when the server
`
`refuses to provide a response due to a policy restriction (i.e., the client computer is not authorized).
`
`(Req. at 47.) However, as previously explained, Aventail teaches that the server does not even
`
`attempt to resolve a hostname until after the client computer is authenticated. (Aventail v3.1 I 2 (step
`
`- 10-
`
`Petitioner RPX Corporation - Ex. 1052, p. 10
`
`

`

`Control No.: 95/001,682
`Declaration of Angelos D. Keromytis, Ph.D.
`
`2.b).) Accordingly, the RCODE could not be returned in response to a client computer not being
`
`authorized to establish the purported VPN.
`
`38. With regard to claim 6, it is my opinion that Aventail does not disclose that step (3) of
`
`claim 1 comprises the step of establishing the VPN by creating an IP address hopping scheme
`
`between the client computer and the target computer. The Request again points to the Fratto
`
`declaration to try to show that the feature of claim 6 is disclosed by Aventail because Aventail
`
`discloses a MultiProxy scheme and a Proxy Chaining scheme. The Request does nothing to show
`
`that a VPN is established by creating an IP address hopping scheme. The proxy schemes disclosed
`
`by Aventail would not be understood by one of ordinary skill in the art as establishing the purported
`
`VPN. Rather, the proxy schemes are implemented merely to satisfy the "need to traverse multiple
`
`firewalls." (Aventail v3.1 68.) Providing a mechanism for traversing multiple firewalls does not
`
`contribute in any meaningful way towards securing data transmitted over a public network, much less
`
`establishing a VPN. (See id. at 116.)
`
`39.
`
`I understand independent claim 10 to recite, among other things, a "DNS proxy
`
`server" that "returns the IP address for the requested domain name if it is determined that access to a
`
`non-secure web site has been requested."
`
`40.
`
`I understand the Request contends that Aventail Connect, running on the client
`
`computer, may be seen as a "DNS proxy server," and that the Aventail ExtraNet Server is a gateway
`
`computer. (Req. at 54.) It appears that the Request contends that Aventail Connect (the alleged
`
`proxy server) will return an IP address if a hostname does not match a redirection rule. (See Req. at
`
`54.) I disagree.
`
`41.
`
`In my opinion, the Request's view is contradictory to the Request's own position that
`
`"the term 'DNS proxy server' means 'a computer or program that responds to a domain name inquiry
`
`in place of a DNS."' (Req. at 36 (emphasis added).) Aventail Connect does not respond to a domain
`
`name inquiry in place of a DNS when a redirection rule is not matched, much less return an IP
`
`address for the requested domain name if it is determined that access to a non-secure web site has
`
`been requested. Aventail teaches that if"hostname matches a local domain string or does not match a
`
`redirection rule, Aventail Connect passes the name resolution query through to the TCP/IP stack
`
`[which] performs the lookup as if Aventail Connect were not running." (Req. at 54 (quoting
`
`Aventail v3.1 11) (emphasis in original). See also Aventail v3.1 45 (hostnames "are passed to the
`
`local resolver for name resolution instead of being proxied through the SOCKS v5 server.").) Thus,
`
`Aventail discloses that Aventail Connect does not return the IP address for the requested domain
`
`- 1 1 -
`
`Petitioner RPX Corporation - Ex. 1052, p. 11
`
`

`

`Control No.: 95/00 I ,682
`Declaration of Angelos D. Keromytis, Ph.D.
`
`name if it is determined that access to a non-secure web site has been requested. Rather, Aventail
`
`Connect is ignored completely.
`
`42.
`
`For these reasons, it is my opinion that Aventail does not disclose the feature of a
`
`DNS proxy server that returns the IP address for the requested domain name if it is determined that
`
`access to a non-secure web site has been requested, as recited by claim I 0.
`
`43.
`
`It is also my opinion that Aventail does not disclose a "DNS proxy server that
`
`generates a request to create a VPN between the client computer and the secure target computer if it
`
`is determined that access to a secure web site has been requested," as recited by claim I 0.
`
`44.
`
`The Request contends that, if a hostname matches a redirection rule, "Aventail
`
`Connect will ... begin the TCP handshake with the server .... "
`
`(Reg. at 54 (quoting Aventail
`
`v3.112).) As an initial matter, the Request mischaracterizes Aventail, as the quoted feature is
`
`performed only when "the request contains a routable IP address," and thus the purported proxy
`
`server would not receive a request from the client computer to look up an IP address from which a
`
`determination may be made. (See Aventail v3.1 I2 (step 2.a).) Even so, Aventail Connect would not
`
`be seen as making a request to create a VPN. Aventail Connect merely makes a connection request.
`
`(Aventail v3.1 II-I2.) The connection request of Aventail is not understood as a request to create a
`
`VPN. Rather, Aventail teaches that the step of establishing a connection is no different than in
`
`standard Winsock communications, which do not incorporate security. (Aventail v3.1 8, 11.)
`
`Aventail may forward a hostname with the connection request. (Aventail v3.1 I2 (the hostname is
`
`forwarded to the extranet server and the server performs the resolution).) Aventail, however, does
`
`not disclose that the proxy server does anything with the hostname other than perform a hostname
`
`resolution. (See id.)
`
`45.
`
`I understand independent claim I3 to recite "a central computer that maintains a
`
`plurality of authentication tables each corresponding to one of the client computers" and
`
`"authenticating, with reference to one of the plurality of authentication tables, that the request
`
`received in step (1) is from an authorized client."
`
`46.
`
`The Request contends that the A ventail ExtraNet Server inherently maintains
`
`authen