IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`Larson et al.
`In re Patent of:
`U.S. Patent No.: 7,921,211 Attorney Docket No.: 38868-0007IP2
`Issue Date:
`April 5, 2011
`Appl. Serial No.: 11/840,560
`Filing Date:
`August 17, 2007
`Title:
`AGILE NETWORK PROTOCOL FOR SECURE COMMUNICATIONS
`
`USING SECURE DOMAIN NAMES
`
`
`
`DECLARATION OF DR. ROCH GUERIN
`
`1.
`
`My name is Dr. Roch Guerin. I am the chair of the Computer Science &
`
`Engineering department at Washington University in St. Louis. I have been asked to offer
`
`technical opinions relating to U.S. Patent No. 7,921,211, and prior art references relating to its
`
`subject matter. My current curriculum vitae is attached and some highlights follow.
`
`2.
`
`I earned my diplôme d'ingénieur (1983) from École nationale supérieure des
`
`télécommunications, in Paris, France. Thereafter, I earned my M.S. (1984) and PhD (1986) in
`
`electrical engineering from The California Institute of Technology in Pasadena, California.
`
`3.
`
`Prior to becoming a professor in engineering, I held various positions at the IBM
`
`T.J. Watson Research Center. Specifically, from 1986 to 1990, I was a research staff member
`
`within the Communication Department, where I worked to design and evaluate high-speed
`
`switches and networks. From 1990 to 1991, I was a research staff member within the IBM High
`
`Performance Computing and Communications Department, where I worked to develop and
`
`deploy an integrated broadband network. From 1992 to 1997, I was the manager of Broadband
`
`Networking within IBM’s Security and Networking Systems Department, where I led a group of
`
`researchers in the area of design, architecture, and analysis of broadband networks. One of the
`
`projects on which I worked, for example, led to U.S. Patent No. 5,673,318, which regards “[a]
`
`Page 1 of 36 
`
`MICROSOFT 1022
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`method and system for providing data authentication, within a data communication environment,
`
`in a manner which is simple, fast, and provably secure,” and of which I am a named inventor.
`
`See U.S. Patent No. 5,673,318, abstract. From 1997 to 1998, I was the manager of Network
`
`Control and Services within IBM’s Security and Networking Systems Department, where I led a
`
`department responsible for networking and distributed applications, including topics such as
`
`advance reservations, policy support, including for Resource Reservation Protocol (RSVP),
`
`quality of service (QoS) routing, and security, and integrated switch and scheduling designs.
`
`4.
`
`I have been a professor of engineering for the past fifteen years. As such, but
`
`prior to becoming the chair of the Computer Science & Engineering department at Washington
`
`University in St. Louis, I was the Alfred Fitler Moore Professor of Telecommunications
`
`Networks (an honorary chair) in the Department of Electrical and Systems Engineering at the
`
`University of Pennsylvania. As a professor of engineering, I have taught many courses in
`
`networking, including Advanced Networking Protocols (TCOM 502), which addressed, among
`
`other things, virtual private networks.
`
`5.
`
`I have authored over fifty journal publications, including “On the Feasibility and
`
`Efficacy of Protection Routing in IP Networks,” which was honored as the IEEE INFOCOM
`
`2010 Best Paper Award. I have been named a Fellow by both the IEEE and ACM, and, from
`
`2009 to 2012, I was the Editor-in-Chief of the IEEE/ACM Transactions on Networking.
`
`Furthermore, I am a named inventor on over thirty issued U.S. patents.
`
`6.
`
`I am familiar with the content of U.S. Patent No. 7,921,211 (the “‘211 patent”).
`
`In addition, I have considered the various documents referenced in my declaration as well as
`
`additional background materials. I have also reviewed certain sections of the prosecution history
`
`of the ‘211 patent, the prosecution history of reexamination control numbers 95/001,789 and
`
`Page 2 of 36 
`
`

`

`95/001,856; and the claim construction orders from VirnetX Inc. v. Microsoft Corp., Docket No.
`
`6:07CV80 (E.D. Tex.) and VirnetX Inc. v. Cisco Systems, Inc. et al., Docket No. 6:10cv417 (E.D.
`
`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`Tex.).
`
`7. Counsel has informed me that I should consider these materials through the lens of one of
`
`ordinary skill in the art related to the ‘211 patent at the time of the invention, and I have done so
`
`during my review of these materials. I believe one of ordinary skill as of February 15, 2000 (the
`
`priority date of the ‘211 patent) would have a Master’s degree in computer science or computer
`
`engineering, or in a related field such as electrical engineering, as well as about two years of
`
`experience in computer networking and in some aspect of security with respect to computer
`
`networks. I base this on my own personal experience, including my knowledge of colleagues
`
`and others at the time.
`
`8.
`
`I have no financial interest in either party or in the outcome of this proceeding. I
`
`am being compensated for my work as an expert on an hourly basis. My compensation is not
`
`dependent on the outcome of these proceedings or the content of my opinions.
`
`9.
`
`My opinions, as explained below, are based on my education, experience, and
`
`background in the fields discussed above.
`
`10.
`
`This declaration is organized as follows:
`
`I.
`
`II.
`
`III.
`
`IV.
`
`V.
`
`Brief Overview of the ‘211 Patent
`
`Terminology
`
`Aventail and Combinations Involving Aventail
`
`Publication and Authenticity for Requests for Comments (RFCs)
`
`Conclusion
`
`Page 3 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`I.
`
`11.
`
`Brief Overview of the ‘211 Patent
`
`A section of the ‘211 patent’s specification titled “B. Use of a DNS Proxy to
`
`Transparently Create Virtual Private Networks” describes “the automatic creation of a virtual
`
`private network (VPN) in response to a domain-name server look-up function.,” with reference
`
`to FIG. 26. Ex. 1001, 38:55-57. Referring to FIG. 26 below, a “user's computer 2601 includes a
`
`conventional client (e.g., a web browser) 2605 and an IP protocol stack 2606 that preferably
`
`operates in accordance with an IP hopping function 2607 as outlined above.” Ex. 1001, 39:48-
`
`51. “A modified DNS server 2602 includes a conventional DNS server function 2609 and a
`
`DNS proxy 2610.” Ex. 1001, 39:51-52. “A gatekeeper server 2603 is interposed between the
`
`modified DNS server and a secure target site [2604].” Ex. 1001, 39:52-53. “An ‘unsecure’
`
`target site 2611 is also accessible via conventional IP protocols.” Ex. 1001, 39:53-56.
`
`Page 4 of 36 
`
`
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`12.
`
`As described by the ‘211 patent:
`
`DNS proxy 2610 intercepts all DNS lookup functions from client 2605
`
`and determines whether access to a secure site has been requested. If access to a
`
`secure site has been requested (as determined, for example, by a domain name
`
`extension, or by reference to an internal table of such sites), DNS proxy 2610
`
`determines whether the user has sufficient security privileges to access the site. If
`
`so, DNS proxy 2610 transmits a message to gatekeeper 2603 requesting that a
`
`virtual private network be created between user computer 2601 and secure target
`
`site 2604. In one embodiment, gatekeeper 2603 creates “hopblocks” to be used by
`
`computer 2601 and secure target site 2604 for secure communication. Then,
`
`gatekeeper 2603 communicates these to user computer 2601. Thereafter, DNS
`
`proxy 2610 returns to user computer 2601 the resolved address passed to it by the
`
`gatekeeper (this address could be different from the actual target computer) 2604,
`
`preferably using a secure administrative VPN. The address that is returned need
`
`not be the actual address of the destination computer.
`
`Had the user requested lookup of a non-secure web site such as site 2611,
`
`DNS proxy would merely pass through to conventional DNS server 2609 the
`
`look-up request, which would be handled in a conventional manner, returning the
`
`IP address of non-secure web site 2611. If the user had requested lookup of a
`
`secure web site but lacked credentials to create such a connection, DNS proxy
`
`2610 would return a “host unknown” error to the user. In this manner, different
`
`users requesting access to the same DNS name could be provided with different
`
`look-up results.
`
`Page 5 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`Ex. 1001, 39:57 to 40:18.
`
`II.
`
`13.
`
`Terminology
`
`I have been informed that claim terminology must be given the broadest
`
`reasonable interpretation during an IPR proceeding. I have been informed that this means the
`
`claims should be interpreted as broadly as their terms reasonably allow, but that such
`
`interpretation should not be inconsistent with the patent’s specification and with usage of the
`
`terms by one of ordinary skill in the art when considering the broadest reasonable construction. I
`
`have been informed that this may yield interpretations that are broader than the interpretation
`
`applied during a District Court proceeding, such as the pending VirnetX Inc. v. Microsoft Corp.
`
`litigation.
`
`14.
`
`I have been informed that it would be useful to provide some guidance in this
`
`proceeding with respect to the term below and its corresponding construction. As part of that, I
`
`considered this term’s context within the claim, use within the specification, and my
`
`understanding of how one of ordinary skill in the art would understand the term around the time
`
`of the purported invention under the broadest reasonable construction standard.
`
`15.
`
`I have considered whether a broadest reasonable interpretation of “system” would
`
`be broad enough to cover “one or more discrete computers or devices.” I believe that it would,
`
`since such an interpretation is not inconsistent with the ‘211 patent’s specification and the
`
`understanding one of ordinary skill in the art would ascribe to this term when looking for the
`broadest reasonable construction. For example, at col. 39, line 47 – col. 40, line 32, the ‘211
`
`patent describes a system that includes a modified DNS server 2602 and a separate gatekeeper
`
`server 2603, and specifically states that “although element 2602 [(the modified DNS server)] is
`
`shown as combining the functions of two servers [(the DNS proxy 2610 and DNS server 2609)],
`
`the two servers can be made to operate independently.” Ex. 1001 at col. 40:29-31.
`
`Page 6 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`III. Aventail and Combinations Involving Aventail
`
`16.
`
`The Aventail reference includes an “Aventail Connect v3.01/v2.51
`
`Administrator’s Guide” and an “Aventail ExtraNet Server v3.0 Administrator’s Guide,” which
`
`each describes elements of the overall Aventail ExtraNet Center software suite. Because these
`
`two Guides describe related elements of the same system from the same perspective (i.e., an
`
`administrator), I will address them as a single document. However, to the extent that these
`
`Guides would be considered separate from one another, it would have been obvious to one
`
`having ordinary skill in the art to combine their respective teachings when implementing and
`
`configuring the primary elements of the Aventail ExtraNet Center suite. Aventail describes that
`
`“[s]etup of the Aventail ExtraNet Center requires that installation on both a server and multiple
`
`client machines.” Ex. 1007 at 125 (emphasis added). The installation on the server is Aventail
`
`ExtraNet Server, which is described in its Administrator Guide, and the installation on the
`
`multiple client machines is Aventail Connect, which is described in its Administrator Guide. See
`
`Ex. 1007 at 126-129 (describing the installation of both elements and referencing their respective
`
`Administrator Guides). Accordingly, one of ordinary skill in the art would have been motivated
`
`to use these products together since that was their intended design, and would accordingly have
`
`been motivated to combine the teachings of the two Guides.
`
`A.
`
`Aventail
`
`17.
`
`Aventail generally describes a system and processes that transparently establish
`
`an encrypted tunnel between a client computer and a private network. Ex. 1007 at 11. In
`
`particular, Aventail describes various parts of the Aventail ExtraNet Center, which is “a
`
`client/server solution for management of sophisticated extranets.” Ex. 1007 at 125. Aventail
`
`explains that the Aventail ExtraNet Center is designed to monitor network usage, provide private
`
`Page 7 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`communication over public networks and enable remote users to securely access internal
`
`network resources. Ex. 1007 at 10-11.
`
`18.
`
`Aventail ExtraNet Center includes an Aventail ExtraNet Server (AES), an
`
`Aventail Policy Console, and Aventail Connect. Id. Aventail Connect software is installed and
`
`runs on the client computer (e.g., a mobile device known as a “mobile user”), while Aventail
`
`ExtraNet Server software (“Aventail VPN Server”) is installed and runs on a gateway computer
`
`connected to both the Internet and a private network. See Ex. 1007 at18, 126. This is illustrated
`
`the following figure of Ex. 1007 at page 76:
`
`19.
`
`In particular, the Aventail ExtraNet Server (AES) is “a SOCKS v5 proxy server
`
`that manages the authentication of users and processes all of the connection requests.” Ex. 1007
`
`at 125. The Aventail Policy Console is “the graphical administrative tool for creating, viewing
`
`and managing the policies for your extranet.” Id. Aventail Connect is “an application that sits
`
`
`
`Page 8 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`between WinSock and the TCP/IP stack” and “is a Layered Service Provider (LSP)” that
`
`executes on a client computer. Ex. 1007 at 13.
`
`20.
`
` Aventail explains that Aventail Connect is configured to work with applications
`
`that communicate via TCP/IP, which is implemented using the WinSock functionality in client
`
`computers running Windows. See, e.g., Ex. 1007 at 12-13 (“Windows TCP/IP networking
`
`applications (such as telnet, e-mail, Web browsers and ftp) use WinSock to gain access to
`
`networks or the Internet.”). The Aventail Connect product thus had to be compliant with well-
`
`known Internet standards including TCP/IP, DNS and SOCKS v4 and v5. See, e.g., Ex. 1007 at
`
`5-6, 10-12, 14.
`
`21.
`
`Aventail describes a system that automatically authenticates a mobile user, and
`
`then encrypts communications between that mobile user’s client computer (running Aventail
`
`Connect software) and a private network resource via a SOCKS server (i.e., the Aventail
`
`ExtraNet Server or “AES”). See Ex. 1007 at 76. This provides a private encrypted connection
`
`between the client and the private network. Ex. 1007 at 76 (“The design used in the example
`
`above consists of two individual Ethernet segments, one public and one private. The public
`
`segment is used to host anonymous services available to the general public.”)
`
`22.
`
`Aventail describes that “Aventail Connect is designed to run transparently on
`
`each workstation” and “does not require administrators to manually establish an encrypted
`
`tunnel; Aventail Connect can establish an encrypted tunnel automatically.” Ex. 1007 at 11. One
`
`of ordinary skill in the art would understand that Aventail Connect running transparently and
`
`automatically establishing an encrypted tunnel means that the secure SOCKS connection is
`
`established without user involvement.
`
`Page 9 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`23.
`
`Aventail Connect can be configured to intercept connection requests, evaluate
`
`them, and then handle them appropriately (e.g., by proxying a connection request to the AES, or
`
`by passing requests through for normal handling procedures of the computer). See Ex. 1007 at
`
`11. For example, Aventail explains that “Aventail Connect redirects WinSock calls and reroutes
`
`them based upon a set of routing directives (rules).” Ex. 1007 at 5. As an example of a routing
`
`directive, Aventail describes that “Aventail Connect will forward traffic destined for the private
`
`internal network to the AES. Then, based on the security policy, the AES will proxy mobile user
`
`traffic into the private network but only to those resources allowed.” Ex. 1007 at 77.
`
`24.
`
`Thus, Aventail shows a client computer running Aventail Connect (i) operating
`
`transparently to the user (ii) authenticating a user attempting to access a secure location, (iii)
`
`automatically encrypting communications between the client computer and the secure network
`
`destination, (iv) communicating via the AES to network resources on a private network, and (v)
`
`being configured to route the TCP/IP traffic between it and the secure network destination. See
`
`Ex. 1007 at 11-12, 76-77. These steps are described in more detail below with regard to the
`
`following message sequence chart (“Chart 1”) that illustrates the description on pages 15 and 16
`
`of Aventail.
`
`Page 10 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`Client Computer
`
`TCP/IP 
`Application
`
`Aventail 
`Connect
`
`Standard 
`DNS Server
`
`Aventail 
`ExtraNet Server
`
`Destination 
`Server
`
`8 9
`
`10
`
`Chart 1
`
`
`
`2a
`
`4
`
`7
`
`1
`
`2b
`
`3
`
`5 6
`
`11
`
`25.
`
`Initially, a requesting TCP/IP application on a client computer issues a DNS
`
`lookup request that includes a domain name specifying a remote host and requests the IP address
`
`corresponding to the domain name (arrow 1 of Chart 1). See Ex. 1007 at 15. The DNS lookup
`
`request is a request for an IP address associated with the domain name. Aventail Connect
`
`intercepts this DNS lookup request and evaluates it. See id. In particular, Aventail describes that
`
`Aventail Connect performs the following operations on an intercepted DNS lookup:
`
`Page 11 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`
`
`If the 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 on the local workstation. The TCP/IP stack performs the
`
`lookup as if Aventail Connect were not running.
`
`
`
`If the destination hostname matches a redirection rule domain
`
`name (i.e., the host is part of a domain we are proxying traffic to) then Aventail
`
`Connect creates a false DNS entry (HOSTENT) that it can recognize during the
`
`connection request. Aventail Connect will forward the hostname to the extranet
`
`(SOCKS) server in step 2 and the SOCKS server performs the hostname
`
`resolution.
`
`Ex. 1007 at 15-16.
`
`26.
`
`In other words, Aventail describes that Aventail Connect will first check the
`
`domain name in the request against a table of “local domain strings” and then will check the
`
`domain name against a table of “redirection rules.” See Ex. 1007 at 15-16. If the domain name
`
`(i) is in the local domain lookup table or (ii) is not in the redirection rule table, Aventail Connect
`
`passes the request to the operating system for handling by the ordinary DNS handling procedures
`
`of the client computer (arrows 2a in Chart 1). See Ex. 1007 at 15. This would be the case, for
`
`example, for an ordinary non-secure connection. See Ex. 1007 at 77 (“Only traffic destined for
`
`the internal network is authenticated and encrypted; all other traffic passes through Aventail
`
`Connect unchanged. For instance, browsing the Internet from the mobile user workstation
`
`occurs as if Aventail Connect is not even running in the background.”). The resolved IP address
`
`is then returned to the TCP/IP application (arrows 2a in Chart 1). See Ex. 1007 at 13-16. Thus,
`
`Page 12 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`in the case of ordinary, non-secure connections, the IP address is returned to the calling TCP/IP
`
`application, with no proxying or other connection to the AES. See Ex. 1007 at 15.
`
`27.
`
`On the other hand, when the domain name in the DNS lookup request matches a
`
`“redirection rule,” the subsequent connection request will be proxied (sent to) the AES
`
`corresponding to the domain name. See Ex. 1007 at 15-16. In particular, Aventail Connect
`
`compares the domain name included in the DNS lookup requests against one or more redirection
`
`rules. See id. Aventail explains that “redirection rules” are stored in configuration files accessed
`
`by Aventail Connect. See, e.g., Ex. 1007 at 19 (“Integral to the initial installation of Aventail
`
`Connect is deciding how SOCKS traffic will be redirected through the network. Network
`
`redirection rules (used to determine if and how SOCKS redirection will occur) are defined in the
`
`Aventail Connect configuration (.cfg) file.”).
`
`28.
`
`To create a redirection rule, Aventail explains that an administrator must: “1.
`
`Define the extranet (SOCKS) servers[;] 2. Define the destinations (networks and hosts)[; and] 3.
`
`Specify redirection rules.” Ex. 1007 at 35. To create the redirection rules, the administrator uses
`
`a Config Tool that includes the following tabs:
`
`Ex. 1007 at 36.
`
`29.
`
`First, the administrator defines one or more AESs to which requests may be
`
`proxied. See Ex. 1007 at 37-39. Second, the administrator defines one or more “destinations to
`
`be routed through” an AES. See Ex. 1007 at 39-42. A destination may be “subnets, individual
`
`
`
`Page 13 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`host computers, or IP address ranges.” Ex. Ex. 1007 at 40. For example, a range of IP addresses
`
`within the private network of an Aventail VPN server could be designated as a “destination” or a
`
`specific server on the private network behind the Aventail VPN server could be a “destination.”
`
`Ex. The options for destinations are illustrated in this table (below):
`
`
`
`Ex. 1007 at 41.
`
`30.
`
`Aventail shows that redirection rules are stored as a table of values that associate
`
`a destination (e.g. a domain name) with a manner in which network requests that include the
`
`destination are to be handled (e.g., redirected through a particular AES). See, e.g., Ex. 1007 at
`
`42-43. Aventail teaches three options for handling requests containing a destination (e.g.,
`
`domain name) in a redirection rule table entry; namely, (i) the traffic corresponding to the
`
`request could be routed to the AES, (ii) the traffic corresponding to the request could be routed to
`
`bypass the AES (e.g., be sent directly to the destination without redirection), or (iii) access to the
`
`specific destination could be denied. See Ex. 1007 at 44 (figure reproduced below):
`
`Page 14 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`
`If a domain name in a DNS lookup request matches a redirection rule denying
`
`31.
`
`access to a specified location, the network connection is blocked locally by Aventail Connect.
`
`See Ex. 1007 at 44. Thus, in the case where a redirection rule specifies that the client computer
`
`is not authorized to access a particular destination, Aventail Connect will return an error to the
`
`requesting TCP/IP application. See, e.g., Ex. 1007 at 6, 83-86 (describing Aventail Connect’s
`
`Logging Tool, which “displays errors, warnings, and information as Aventail Connect generates
`
`them” and may be used to “troubleshoot problems with network connections”).
`
`32.
`
`If a domain name in a DNS lookup request matches a redirection rule specifying
`
`that traffic to the domain name should be redirected to an AES for delivery within a private
`
`network, Aventail Connect flags the request containing the domain name by “creating a false
`
`DNS entry (HOSTENT) that it can recognize during the connection request.” Ex. 1007 at 15-16.
`
`The false DNS entry is a placeholder that Aventail Connect returns to the TCP/IP application in
`
`place of a real IP address (arrow 2b in Chart 1). See Ex. 1007 at 15-16. Aventail Connect can
`
`Page 15 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`recognize the false DNS entry as related to a specific redirection rule when Aventail Connect
`
`receives it in future requests. See id. Hostnames matching a redirection rule requiring
`
`redirection to an AES are destinations that require a VPN (e.g., authentication and encryption).
`
`See, e.g., Ex. 1007 at 77. (“Only traffic destined for the internal network is authenticated and
`
`encrypted; all other traffic passes through Aventail Connect unchanged.”). Thus, Aventail
`
`Connect compares the domain name included in a DNS lookup request to a list of redirection
`
`rules to determine whether the DNS request is requesting access to a remote host that is on a
`
`virtual private network requiring secure communications. The above-described process of DNS
`
`lookup is summarized in the following Chart 2.
`
`Chart 2
`
` 
`
`Page 16 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`33.
`
`Once the TCP/IP application receives an IP address in response to a DNS lookup
`
`request, the TCP/IP application issues a connection request for the IP address (arrow 3 in Chart
`
`1). See Ex. 1007 at 16. Aventail describes the handling of connection requests as follows:
`
`2. The application requests a connection to the remote host. This
`causes the underlying stack to begin the TCP handshake. When the
`handshake is complete, the application is notified that the connection is
`established and that data may now be transmitted and received. Aventail
`Connect does the following:
`
`a.
`
`Aventail Connect checks the connection request.
`
`If the request contains a false DNS entry (from step 1), it
`•
`will be proxied.
`
`If the request contains a routable IP address, and the rules
`•
`in the configuration file say it must be proxied, Aventail Connect will call
`WinSock to begin the TCP handshake with the server designated in the
`configuration file.
`
`If the request contains a real IP address and the
`•
`configuration file rule says that it does not need to be proxied, the request
`will be passed to WinSock and processing jumps to step 3 as if Aventail
`Connect were not running.
`
`Ex. 1007 (Aventail) at 16.
`
`34.
`
`In other words, Aventail Connect intercepts all connection requests, just as it
`
`intercepts all DNS lookup requests. See Ex. 1007 at 13-14. When the IP address contained in
`
`the connection request does not correspond to a redirection rule, Aventail Connect performs no
`
`special processing and allows the client computer to perform a standard TCP handshake with the
`
`destination associated with the real IP address. See Ex. 1007 at 16.
`
`Page 17 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`35.
`
`On the other hand, when the IP address contained in the connection request is a
`
`false DNS entry (e.g., where the domain name matched a redirection rule and was thus
`
`determined to be associated with a secure computer internal to the AES network) or itself
`
`matches a redirection rule, the connection request is “proxied.” See Ex. 1007 at 16. In other
`
`words, in response to identifying a connection request including a false DNS entry, Aventail
`
`Connect is configured to negotiate a VPN connection with the AES corresponding to the false
`
`DNS entry (arrows 4 of Chart 1). In particular, Aventail teaches:
`
`When the connection is completed, Aventail Connect
`b.
`begins the SOCKS negotiation.
`
`It [i.e., the client computer running Aventail Connect]
`•
`sends the list of authentication methods enabled in the configuration file.
`
`Once the server selects an authentication method, Aventail
`•
`Connect executes the specified authentication processing.
`
`It then sends the proxy request to the extranet (SOCKS)
`•
`server. This includes either the IP address provided by the application or
`the DNS entry (hostname) provided in step 1.
`
`When the SOCKS negotiation is completed, Aventail
`c.
`Connect notifies the application. From the application’s point of view, the
`entire SOCKS negotiation, including the authentication negotiation, is
`merely the TCP handshaking
`
`3.
`
`The application transmits and receives data.
`
`If an encryption module is enabled and selected by the SOCKS
`server, Aventail Connect encrypts the data on its way to the server on
`behalf of the application. If data is being returned, Aventail Connect
`decrypts it so that the application sees cleartext data.
`
`Page 18 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`Ex. 1007 at 15-16.
`
`36.
`
`Thus, by way of the false DNS entry, Aventail Connect recognizes when a
`
`TCP/IP application is requesting a connection with a secure destination within the private
`
`network corresponding to an AES and transparently negotiates a secure SOCKS connection with
`
`the AES that will enable a virtual private network link between the TCP/IP application and the
`
`secure destination. See Ex. 1007 at 16. During the process of establishing a connection with the
`
`AES, Aventail Connect forwards the domain name that matched the redirection rule to the AES,
`
`which performs hostname resolution on the domain name so that the AES can establish a
`
`connection with the destination. Ex. 1007 at 15-16. As part of the negotiation of the secure
`
`SOCKS connection, the AES will allocate VPN resources (e.g., encryption keys) for
`
`communicating between the client computer and the secure destination server. See, e.g., Ex.
`
`1007 at 16, 51. Once the negotiation is complete and the secure SOCKS connection is
`
`established, Aventail Connect notifies the TCP/IP application of a successful connection (arrow
`
`6 of Chart 1). See Ex. 1007 at 16. The above-described process of negotiating a connection with
`
`the AES to create a virtual private network is summarized in the following Chart 3. 
`
`Page 19 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`Chart 3
`
`37.
`
`As part of the SOCKS negotiation process, the AES may be configured to
`
`authenticate the client computer before creating the secure SOCKS connection. For example,
`
`Aventail describes that “[t]he Aventail ExtraNet Server used authentication rules to check
`
`incoming (server) and outgoing (client) requests for access. Ex. 1007 at 163. In particular,
`
`Aventail teaches that the AES may require a client computer to present valid credentials in order
`
`to be authenticated. Ex. 1007 at 16, 32 (describing various authentication protocols, including
`
`SOCKS 4, in which “username is sent, unencrypted, to the SOCKS server along with your
`
`connection request” for authentication of the client computer); see also id. at 46-62, 156-167. If
`
`Page 20 of 36 
`
`

`

`Attorney Docket No.: 38868-0007IP2
`U.S. Patent No. 7,921,211 
`
`the authentication fails, the AES will deny the connection with the client computer. See Ex.
`
`1007 at 156.
`
`38.
`
`Aventail discloses that the Aventail Connect includes various visual indications
`
`that a secure SOCKS connection has been or can be established. For example, Aventail Connect
`
`includes an option “to display network traffic passing through a selected
`
`authentication/encryption module.” That is, Aventail includes an option to display traffic
`
`passing through a selected secure SOCKS connection. The “Indicator” option can be set in the
`
`“Authentication” module of the Aventail Connect configuration file. When the “Indicator” box
`
`is checked for a particular authentication/encryption module, Aventail Connect displays network
`
`traffic passing through that module to the user in an “Indicator” pop-up window, including
`
`information about (1) the application making the network query, (2) the type of
`
`authentication/encryption used, and (3) the connection.
`
`39.
`
`Further, when using SSL authentication/encryption methods for the secure
`
`SOCKS connection, the Aventail system can also be configured to display an indication that
`
`authentication/encryption is being performed. For example, upon connection to a server with a
`
`new SSL certificate, Aventail Connect can be configured to either (a) display the certificate to
`
`the user or (b) not display the certificate to the user, and then complete the connection.
`
`Similarly, if the server’s SSL certificate were suspect, Aventail Connect can be configured to
`
`either (a) always show the user the suspect certificate and complete the connection, (b) show the
`
`suspect certificate to the user once and complete