IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`In re Patent of: Munger et al.
`U.S. Patent No.: 7,490,151
`Issue Date:
`Feb. 10, 2009
`Appl. Serial No.: 10/259,494
`Filing Date:
`Sep. 30, 2002
`Title:
`ESTABLISHMENT OF A SECURE COMMUNICATION LINK BASED
`ON A DOMAIN NAME SERVICE (DNS) REQUEST
`
` Attorney Docket No.: 38868-0006IP1
`
`
`
`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,490,151, 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 43
`
`MICROSOFT 1003
`
`Petitioner Apple Inc. - Exhibit 1003, p. 1
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`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. 7,490,151 (the “‘151 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 ‘151 patent, the prosecution histories of reexamination control numbers 95/001,697 and
`
`Page 2 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 2
`
`

`
`95/001,714; 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-0006IP1
`U.S. Patent No. 7,490,151
`
`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 ‘151 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 ‘151 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 ‘151 Patent
`
`Terminology
`
`III.
`
`Aventail and Combinations Based on Aventail
`
`IV. Kiuchi and Combinations Based on Kiuchi
`
`V.
`
`VI.
`
`Publication and Authenticity of Requests For Comment (RFCs)
`
`Conclusion
`
`Page 3 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 3
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`I.
`
`11.
`
`Brief Overview of the ‘151 Patent
`
`The ‘151 patent is generally directed to a “establishment of a secure
`
`communication link based on a domain name service (DNS) request.” Ex. 1001, Title. The ‘151
`
`patent includes 16 claims, of which claims 1, 7, and 13 are independent.
`
`12.
`
`A section of the ‘151 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 36:58-60. In the example embodiment, the ‘151 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:33-38.
`
`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 37:43-46. On the other hand, if access to a
`
`secure site has been requested, the system described in the ‘151 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 37:60 to 38:2. The ‘151 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 37:54-56, 38:22-24, 38:30-32.
`
`
`
`Page 4 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 4
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`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
`
`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. 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.
`
`16.
`
`In particular, I have considered whether a broadest reasonable construction of
`
`“client” would be broad enough to cover “a computer or program from which a data request to a
`
`server is generated.” I believe that it would, since such an interpretation is not inconsistent with
`
`the ‘151 patent’s specification. Indeed, the ‘151 application describes both “client computers”
`
`and “client applications.” See Ex. 1001 at 15:61-62, 37:1-3. Moreover, the proposed
`
`interpretation is consistent with the understanding one of ordinary skill in the art would ascribe
`
`to this term when looking for the broadest reasonable construction. See M. Chatel, Classical
`
`versus Transparent IP Proxies, RFC 1919 at 1, 5 (Mar. 1996); see also R. Fielding et al.,
`
`Hypertext Transfer Protocol -- HTTP/1.1, RFC 2068 at 10 (Jan. 1997).
`
`
`
`Page 5 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 5
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`III. Aventail and Combinations Based on Aventail
`
`A.
`
`Aventail
`
`17.
`
`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.
`
`18.
`
`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 together. 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. 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). Therefore,
`
`Page 6 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 6
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`it would have been obvious to one having ordinary skill in the art to combine the teachings of the
`
`Guides.
`
`19.
`
`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.
`
`20.
`
`Aventail generally describes systems and processes that will automatically and
`
`transparently establish a VPN including 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 (“Aventail VPN Server”)
`
`software is installed and runs on a VPN server connected to both the Internet and a private
`
`network. This is illustrated in the following annotated version of a figure from Ex. 1007 at page
`
`76:
`
`Page 7 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 7
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`
`
`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 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 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 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 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 8
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`23.
`
`Aventail includes an example of a deployment with mobile users using Aventail
`
`Connect and an 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 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 9
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`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.
`
`24.
`
`Thus, Aventail shows a client computer running Aventail Connect (i) operating
`
`transparently to the user (ii) authenticating users attempting to access secure locations, (iii)
`
`automatically encrypting communications between client computers used by authenticated users
`
`and the secure server, and (iv) being configured by network administrators to route the TCP/IP
`
`traffic between it and the secure server. See Ex. 1007 at 11-12, 76-77.
`
`25.
`
`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.
`
`26.
`
`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.
`
`Page 10 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 10
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`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.
`
`27.
`
`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 WinSock requests being made on the client
`
`computer. So, when a user types a website into a browser, the Aventail Connect software would
`
`intercept the resulting request. See Ex. 1007 at 69 (explaining how a web Browser is configured
`
`to allow Aventail Connect to “access to Web pages behind the Aventail ExtraNet Server.”).
`
`Then, the Aventail Connect client would evaluate 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.
`
`28.
`
`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.
`
`Page 11 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 11
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`Ex. 1007 at 12-14 (emphasis added).
`
`
`
`29.
`
`In other words, Aventail Connect acts as a proxy module 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 as a DNS proxy
`
`module. 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 standard DNS servers or an AES to create a secure connection
`
`Page 12 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 12
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`on behalf of the client TCP/IP applications. Thus, Aventail Connect acts as a DNS proxy
`
`module.
`
`30.
`
`This is very similar to the process described in the ’151 patent. For example, the
`
`’151 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 30 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 37:60 to 38:2.
`
`31.
`
`Aventail explains 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 high-level description on pages 15 and 16 of Aventail, which is a simplified
`
`representation not necessarily inclusive of all messages exchanged.
`
`Page 13 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 13
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`Chart 1
`
`
`
`32.
`
`Initially, where a requesting TCP/IP application cannot locally resolve a domain
`
`name, it issues a DNS lookup request that includes a domain name specifying a remote host, the
`
`purpose of which is to elicit an IP address corresponding to the domain name (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 14 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 14
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`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.
`
`33.
`
`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.
`
`34.
`
`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 Aventail
`
`ExtraNet Server corresponding to the domain name. See Ex. 1007 at 15-16.
`
`Page 15 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 15
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`35.
`
`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.”).
`
`36.
`
`Aventail also explains that redirection rules may be created by a user, or may be
`
`established by an administrator using a configuration file used during installation of the Aventail
`
`Connect client. See, e.g., Ex. 1007 at 23-24, 35. A network administrator can prevent viewing
`
`or modification of configuration files using password protection. See Ex. 1007 at 62 (“You can
`
`enable password protection for a configuration file. If you enable password protection, users will
`
`not be able to view or modify the configuration file without the assigned password.”).
`
`37.
`
`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.
`
`Page 16 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 16
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`38.
`
`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
`
`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 could be a “destination.”
`
`The options for destinations are illustrated in this table (below):
`
`
`
`Ex. 1007 at 41.
`
`39.
`
`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 17 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 17
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`
`
`40.
`
`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”).
`
`41.
`
`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 18 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 18
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`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. (Where the DNS 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, 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 (i.e.,
`
`a secure server). The above-described process of DNS lookup is summarized in the following
`
`Chart 2.
`
`Chart 2
`
`
`
`Page 19 of 43
`
`Petitioner Apple Inc. - Exhibit 1003, p. 19
`
`

`
`Attorney Docket No.: 38868-0006IP1
`U.S. Patent No. 7,490,151
`
`42.
`
`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. Avent