`
`In re Patent of: Munger et al.
`U.S. Patent No.: 6,502,135
`Issue Date:
`Dec. 31, 2002
`Appl. Serial No.: 09/504,783
`Filing Date:
`Feb. 15, 2000
`Title:
`AGILE NETWORK PROTOCOL FOR SECURE COMMUNICATIONS
`WITH ASSURED SYSTEM AVAILABILITY
`
` Attorney Docket No.: 38868-0004IP1
`
`
`
`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. 6,502,135, 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 41
`
`MICROSOFT 1003
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`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 with 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. 6,502,135 (the “‘135 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 ‘135 patent, the prosecution histories of reexamination control numbers 95/001,269,
`
`Page 2 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`95/001,679, and 95/001,682; 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. 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 ‘135 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 ‘135 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.
`
`Brief Overview of the ‘135 Patent (page 4)
`
`Terminology (page 4)
`
`III.
`
`Aventail and Combinations Based on Aventail (page 6)
`
`IV. Kiuchi and Combinations Based on Kiuchi (page 27)
`
`Publication and Authenticity of Requests For Comment (RFCs) (page 39)
`
`Conclusion (page 41)
`
`V.
`
`VI.
`
`Page 3 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`I.
`
`11.
`
`Brief Overview of the ‘135 Patent
`
`The ‘135 patent is generally directed to a “agile network protocol for secure
`
`communications with assured system availability.” Ex. 1001, Title. The ‘135 patent includes 18
`
`claims, of which claims 1, 10, 13, and 18 are independent.
`
`12.
`
`A section of the ‘135 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
`
`FIGS. 25-27. Ex. 1001 at 37:17-21. In the example embodiment, the ‘135 patent describes that
`
`a “specialized DNS server traps DNS requests and, if the request is from a special type of user
`
`(e.g., one for which secure communication services are defined), the server does not return the
`
`true IP address of the target node, but instead automatically sets up a virtual private network
`
`between the target node and the user.” Ex. 1001 at 37:63 to 38:2.
`
`13.
`
`In the case of standard “DNS requests that are determined to not require secure
`
`services (e.g., an unregistered user), the DNS server transparently ‘passes through’ the request to
`
`provide a normal look-up function.” Ex. 1001, at 38:6-9. On the other hand, if access to a
`
`secure site has been requested, the system described in the ‘135 patent “determines whether the
`
`user has sufficient security privileges to access the site,” and, if so, transmits a message
`
`requesting that a virtual private network be created between the client and the secure target site.
`
`See Ex. 1001 at 38:25-33. The ‘135 patent describes that the various functions of the DNS proxy,
`
`DNS server, and gatekeeper can be performed on the same or different machines. See Ex. 1001
`
`at 38:53-55; 61-65.
`
`II.
`
`14.
`
`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
`
`Page 4 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`claims should be interpreted as broadly as their terms reasonably allow, but that such
`
`interpretation should not be inconsistent with the patent’s specification. 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
`
`15.
`
`I have been informed that it would be useful to provide some guidance in this
`
`proceeding with respect to certain terms, and I have been asked to consider the term below and
`
`its corresponding construction. In each instance of doing so, I considered the 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.
`
`16.
`
`I have considered whether a broadest reasonable interpretation of “virtual private
`
`network” would be broad enough to cover “a private network that is configured within a public
`
`network.” I believe that it would, since, as described below, such an interpretation is not
`
`inconsistent with the ‘135 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.
`
`17.
`
`There is not an explicit definition of “virtual private network” in the ‘135 patent.
`
`However, the ‘135 patent describes that virtual private networks may be established over the
`
`Internet, and secured, for example, using public key encryption. See Ex. 1001 at 37:37-58.
`
`However, the ‘135 patent also contemplates other methods of establishing security. For
`
`example, the ‘135 patent describes the use of a quasi-random IP hopping scheme to implement a
`
`VPN. See, e.g., Ex. 1001 at 23:10-14 (“In a second mode referred to as ‘promiscuous per VPN’
`
`mode, a small set of fixed hardware addresses are used, with a fixed source/destination hardware
`
`address used for all nodes communicating over a virtual private network.”). Moreover, claim 6
`
`Page 5 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`relies on this embodiment, specifying 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.” Id. at 47:53-55 (emphasis added); see also id. at 2:25-36 (explaining use of
`
`anonymity techniques).
`
`III. Aventail and Combinations Involving Aventail
`
`A.
`
`Aventail
`
`18.
`
`The Aventail reference describes various parts of the Aventail ExtraNet Center,
`
`which is “a client/server solution for management of sophisticated extranets.” Ex. 1007 at 125.
`
`Some of the parts of the Aventail ExtraNet Center include an Aventail ExtraNet Server (AES),
`
`an Aventail Policy Console, and Aventail Connect. Id. The Aventail ExtraNet Server (AES) is
`
`“a SOCKS v5 proxy server that manages the authentication of users and processes all of the
`
`connection requests.” Id. The Aventail Policy Console is “the graphical administrative tool for
`
`creating, viewing and managing the policies for your extranet.” Id. “As an application that sits
`
`between WinSock and the TCP/IP stack, Aventail Connect 3.01 is a Layered Service Provider
`
`(LSP)” that executes on a client computer. Ex. 1007 at 13.
`
`19.
`
`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
`
`Page 6 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`client machines.” Ex. 1007 at 125. 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.
`
`20.
`
`Aventail explains that the Aventail ExtraNet Center is designed to monitor
`
`network usage, provide private communication over public networks and enable remote users to
`
`securely access internal network resources. Ex. 1007 at 10-11. For example, “Aventail Connect
`
`redirects WinSock calls and reroutes them based upon a set of routing directives (rules) assigned
`
`when Aventail Connect is configured.” Ex. 1007 at 5.
`
`21.
`
`Aventail generally describes systems and processes that will automatically and
`
`transparently establish a VPN between a client computer and a private network. In particular,
`
`“Aventail Connect is designed to run transparently on each workstation . . . .” Ex. 1007 at 11.
`
`Aventail Connect client software is installed and runs on the client computer (e.g., a mobile
`
`device known as a “mobile user”), while Aventail Extranet Server (i.e., “Aventail VPN Server”)
`
`software is installed and runs on a gateway computer connected to both the Internet and a private
`
`network. This is illustrated in the following annotated figure from Ex. 1007 at page 76:
`
`Page 7 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`
`
`22.
`
`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 connected via the Aventail VPN 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. See Ex. 1007 (Aventail) at 76.
`
`23.
`
`Aventail Connect was designed to run transparently from the point of view of the
`
`user and the application requesting a connection. See Ex. 1007 at 11. This means Aventail
`
`Connect is 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.
`
`Page 8 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`24.
`
`Aventail includes an example of a deployment with mobile users using Aventail
`
`Connect and AES to access resources on a secure corporate network. See Ex. 1007 at 76-77. As
`
`Aventail explains:
`
`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. The public access is provided through a router that
`is connected to the public Internet. The private segment is used to
`house all of the corporation's private network resources and data to
`be used only by internal company employees. The Aventail
`ExtraNet Server depicted in this example is used to provide secure
`and monitored access to the private LAN for mobile employees
`and partners. For security reasons the Aventail ExtraNet Server is
`configured such that operating system routing is disabled.
`Therefore, no direct network connections between the public LAN
`and the private LAN can be created without being securely proxied
`through the Aventail ExtraNet Server.
`The mobile user workstations connected to the public Internet
`are the client workstations, onto which Aventail Connect will be
`deployed. Due to the routing restrictions described above, these
`clients will have no network access beyond the Aventail ExtraNet
`Server unless they are running Aventail Connect. Depending on
`the security policy and the Aventail ExtraNet Server configuration,
`Aventail Connect will automatically proxy their allowed
`application traffic into the private network. In this situation,
`Aventail Connect will forward traffic destined for the private
`internal network to the Aventail ExtraNet Server. Then, based on
`the security policy, the Aventail ExtraNet Server will proxy mobile
`user traffic into the private network but only to those resources
`
`Page 9 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`allowed. The client workstations we focus on in this section are
`Microsoft Windows based PCs. . . .
`User authentication and encryption on the Aventail ExtraNet
`Server require all users to use Aventail Connect to authenticate and
`encrypt their sessions before any connection to the internal private
`network(s). For this example, the Aventail ExtraNet Server
`encrypts all sessions with SSL.
`Ex. 1007 at 76-77.
`
`25.
`
`This example configuration shows that the AES is a “gatekeeper” computer under
`
`the broadest reasonable construction standard because it sits between the public internet and the
`
`private network, and passes traffic between the public internet and the private network. See Ex.
`
`1007 at 76. Congruently, Aventail describes the role of a “gatekeeper” as “evaluat[ing] its
`
`security policies to authenticate the user (client) request and determine if the user has access to
`
`the requested destination,” a role performed, in part, by the AES. Ex. 1007 at 173. The above
`
`example configuration shows that the AES would only proxy traffic from a user who has been
`
`authorized to interact with a specified target on the private network. See id. at 77. In other
`
`words, the AES maintains policies that dictate which resources on the private network a
`
`particular user would be given access.
`
`26.
`
`Thus, Aventail shows a client computer running Aventail Connect (i) operating
`
`transparently to the user (ii) authenticating users attempting to access a secure location, (iii)
`
`automatically encrypting communications between the client computers used by authenticated
`
`users and secure network destinations, (iv) communicating via a “gatekeeper” computer (the
`
`AES) to network resources on a private network, and (v) being configured by network
`
`administrators to route the TCP/IP traffic between it and the secure network destination. See Ex.
`
`1007 at 11-12, 76-77.
`
`Page 10 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`27.
`
`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.
`
`28.
`
`Aventail explains that an application on the client computer, via WinSock, “goes
`
`through the following steps to connect to a remote host on the Internet or corporate network:”
`
`1. The application executes a Domain Name System (DNS)
`lookup to convert the hostname into an Internet Protocol (IP)
`address. If the application already knows the IP address, this step is
`skipped.
`2. The application requests a connection to the specified
`remote host. This causes the underlying stack to begin the TCP
`handshake, when two computers initiate communication with each
`other. When the handshake is complete, the application is notified
`that the connection is established, and data can then be transmitted
`and received.
`3. The application sends and receives data.
`
`Ex. 1007 at 12.
`
`29.
`
`Aventail explains that the Aventail Connect software functions within the TCP/IP
`
`handling procedures of the client computer. In particular, it explains that the Aventail Connect
`
`software transparently intercepts and evaluates all TCP/IP requests being made on the client
`
`computer. So, when a user types a website into a browser, the Aventail Connect software would
`
`intercept that connection request. See Ex. 1007 at 69 (explaining how a web Browser is
`
`Page 11 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`configured to allow Aventail Connect to “access to Web pages behind the Aventail ExtraNet
`
`Server.”). Then, the Aventail Connect client evaluates what actions to take based on the
`
`destination specified in the request (i.e., defined either by a domain name or an IP address,
`
`whichever was present in the request). See Ex. 1007 at 15-16.
`
`30.
`
`Aventail describes how this is done as follows:
`
`Aventail Connect slips in between WinSock and the
`underlying TCP/IP stack. (See diagram below.) As an application
`that sits between WinSock and the TCP/IP stack, Aventail
`Connect 3.01 is a Layered Service Provider (LSP). Aventail
`Connect can change data (compressing it or encrypting it, for
`example) before routing it to the TCP/IP stack for transport over
`the network. The routing is determined by the rules described in
`the configuration file.
`
`Ex. 1007 at 12-14 (emphasis added).
`
`
`
`Page 12 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`31.
`
`In other words, Aventail Connect acts as proxy server to the TCP/IP application.
`
`For example, when Aventail Connect intercepts and responds to DNS lookup requests (as will be
`
`described in greater detail below), Aventail Connect acts a DNS proxy server. See Ex. 1007 at
`
`15-16. In particular, RFC 1919, which explains “classical” and “transparent” proxy techniques,
`
`describes that “[a] classical application proxy implements both the ‘client’ and ‘server’ parts of
`
`an application protocol.” M. Chatel, Classical versus Transparent IP Proxies, RFC 1919 at 1, 5
`
`(Mar. 1996). Similarly, RFC 2068 describes a “proxy” as an “intermediary program which acts
`
`as both a server and a client for the purpose of making requests on behalf of other clients.” R.
`
`Fielding et al., Hypertext Transfer Protocol -- HTTP/1.1, RFC 2068 at 10 (Jan. 1997). Aventail
`
`Connect is an intermediary proxy program that both responds to requests from TCP/IP
`
`applications and sends requests to the AES to create a secure connection on behalf of the client
`
`TCP/IP applications. Thus, one of one of ordinary skill in the art would have understood that
`
`acts as a DNS proxy server under the broadest reasonable construction.
`
`32.
`
`This is very similar to the process described in the ’135 patent. For example, the
`
`’135 patent states:
`
`According to one embodiment, 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.
`Ex. 1001 at 38:23-33.
`
`Page 13 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`33.
`
`Aventail explains how the process by which Aventail Connect intercepts and
`
`evaluates DNS and connection requests. See Ex. 1007 at 15-16. Aventail Connect is a “Layered
`
`Service Provider” (‘LSP’) that functions within the native DNS and TCP/IP handling protocols
`
`of the client computer. Ex. 1007 (Aventail) at 13-14. As Aventail explains, Aventail Connect
`
`performs the same basic functions as standard WinSock communications (described above), but
`
`additional actions and options are nested inside each step. See Ex. 1007 at 15. I will now
`
`describe these actions with regard to the following message sequence chart (“Chart 1”) that
`
`illustrates the description on pages 15 and 16 of Aventail.
`
`Page 14 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`Chart 1
`
`
`
`34.
`
`Initially, a requesting TCP/IP application issues a DNS lookup request to convert
`
`the hostname to an IP address (arrow 1 of Chart 1). See Ex. 1007 at 15. 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:
`
`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
`
`Page 15 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`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.
`
`35.
`
`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.
`
`36.
`
`Thus, 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. 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.
`
`Page 16 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`37.
`
`In particular, Aventail Connect compares the domain name included in the DNS
`
`lookup requests against one or more redirection rules. See Ex. 1007 at 15-16. 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.”).
`
`38.
`
`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.
`
`39.
`
`First, the administrator defines one or more Aventail ExtraNet Servers 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 host computers, or IP address ranges.” 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
`
`Page 17 of 41
`
`
`
`(i.e., a secure target computer) could be a “destination.” The options for destinations are
`
`illustrated in this table (below):
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`
`
`Ex. 1007 at 41.
`
`40.
`
`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 including 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 extranet server, (ii) the traffic corresponding to the request could be routed to
`
`bypass the extranet server (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 18 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`
`
`41.
`
`If a domain name in a DNS lookup request matches a redirection rule denying
`
`access to a specified location, the network connection is blocked locally by Aventail Connect.
`
`See Ex. 1007 at 44. Thus, if 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”). Because this denial of access
`
`happens when Aventail Connect handles the DNS lookup request (and not later when handling a
`
`connect request), the denial necessarily happens prior to creation of a VPN with the domain
`
`name included in the DNS lookup request. See Ex. 1007 at 15-16, 42-44.
`
`42.
`
`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
`
`Page 19 of 41
`
`
`
`Attorney Docket No.: 38868-0004IP1
`U.S. Patent No. 6,502,135
`
`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
`
`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 secure destinations that require a VPN (e.g., authentication and
`
`encryption). See, e.g., Ex. 1007 at 77. (Where the proxy-option is not enabled, “[o]nly traffic
`
`destined for the internal network is authenticated and encrypted; all other traffic passes through
`
`Aventail Connect unchanged.”). Thus, under the broadest reasonable construction standard, by
`
`comparing the domain name included in a DNS lookup request to a list of redirection rules,
`
`Aventail Connect (acting as a DNS proxy server) determines whether the DNS request is
`
`requesting access to a secure web site.
`
`43.
`
`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 des