`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`___________________
`
`Apple Inc.
`Petitioner,
`
`v.
`
`VirnetX, Inc. and Science Application International Corporation,
`Patent Owner
`
`Patent No. 6,502,135
`Issued: Dec. 31, 2002
`Filed: Feb. 15, 2000
`Inventors: Edmund C. Munger, et al.
`Title: AGILE NETWORK PROTOCOL FOR SECURE COMMUNICATIONS
`WITH ASSURED SYSTEM AVAILABILITY
`
`Inter Partes Review Nos. IPR2013-00348 and IPR2013-00349
`__________________________________________________________________
`
`Declaration of Chris Hopen Regarding Prior Art
`and U.S. Patent No. 6,502,135
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`1
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 1
`
`1
`
`MICROSOFT 1005
`
`
`
`I declare that all statements made herein of my own knowledge are true and
`that all statements made on information and belief are believed to be true; and
`further that these statements were made with the knowledge that willfiil false
`statements and the like so made are punishable by fine or imprisonment, or both,
`under Section 1001 of Title 18 of the United States Code and that such willful false
`
`statements may jeopardize the validity of the patent subject to this inter partes
`review proceeding.
`
`Dated: é"/Z" /§
`
`Signed:
`
`Declaration Of Chris Hopen
`Regarding US Patent No. 6,502,135
`
`2
`
`Petitioner Apple — Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 2
`Petitioner RPX Corporation - Ex. 1005, p. 2
`2
`
`2
`
`
`
`I.
`
`INTRODUCTION
`
`A.
`
`1.
`
`Engagement
`
`I have been retained by counsel for Apple Inc. to provide testimony in
`
`the above-captioned proceeding regarding certain facts of which I am aware, and to
`
`offer my opinions regarding certain issues.
`
`2.
`
`In particular, I have been asked to provide my recollections on the
`
`distribution and availability of certain documents relating to a number of Aventail
`
`products, and the product manuals and written materials distributed with those
`
`products. I also was asked to provide my opinions regarding certain statements
`
`about how these products worked that were made in district court and Patent Office
`
`proceedings.
`
`B.
`
`Background And Qualifications
`
`3.
`
`4.
`
`My Curriculum Vitae is submitted as Exhibit 1057.
`
`I am a citizen of the United States, and reside at 19805 15th Avenue
`
`NW, Shoreline, Washington.
`
`5.
`
`I received a B.S. in Computer Science from Western Washington
`
`University in 1988.
`
`6.
`
`I am currently the President of TappIn, Inc., a wholly owned
`
`subsidiary of GlobalSCAPE, based in Seattle, Washington. TappIn is the
`
`successor entity of HomePipe, a company I founded in 2009. TappIn was acquired
`
`by GlobalSCAPE in 2011.
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`3
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 3
`
`3
`
`
`
`7.
`
`Before founding TappIn, I was affiliated with Aventail, Inc. until that
`
`company was acquired by SonicWall, Inc. in 2007.
`
`8.
`
`I helped co-found Aventail in 1996, and served as its Chief Technical
`
`Officer and Vice-President of Engineering from 1996 to 2007.
`
`9.
`
`Prior to co-founding Aventail, I served as Director of Network
`
`Technology for CompuServe’s Internet Division, where I was a key contributor to
`
`the development of CompuServe’s dial-up internet products and designed and
`
`managed the development of the dial-up protocol stacks of SPRY’s Internet In a
`
`Box, AIR Series, and Internet Office application suites.
`
`10.
`
`I am a named inventor on several U.S. patents, including patents
`
`related to classifying an operating environment of a remote computer, provisioning
`
`remote computers for accessing resources, systems and techniques for controlling
`
`requests for resources from remote computers, distributed cache services,
`
`controlling access to a set of resources on a network, and rule-based routing to
`
`resources through a network.
`
`II.
`
`Public Availability of Aventail Products
`
`11. While I was affiliated with Aventail, I was involved in the design,
`
`development and distribution of all of Aventail’s products.
`
`12.
`
`I have personal knowledge of development of the products, and with
`
`their distribution to Aventail customers.
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`4
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 4
`
`4
`
`
`
`13.
`
`I am also very familiar with the technical features of the products, as I
`
`was involved in creating them.
`
`A.
`
`Aventail AutoSOCKS
`
`14.
`
`In 1997, Aventail released a set of SOCKS v5 compliant VPN
`
`software products including AutoSOCKS v2.1 (“AutoSOCKS”), MobileVPN and
`
`PartnerVPN.
`
`15. AutoSOCKS was a client-based software product that ran on users’
`
`computers, while Mobile VPN and Partner VPN were server-based products.
`
`16. When paired with the Aventail MobileVPN or PartnerVPN server
`
`products, Aventail AutoSOCKS would automatically establish a VPN to give the
`
`remote user access to secured network resources on a private network.
`
`17.
`
`The AutoSOCKS client and the server would automatically
`
`authenticate the remote user and encrypt all communications between the remote
`
`user and the destination network.
`
`18. Version 2.1 of the AutoSOCKS product was publicly distributed in
`
`the summer of 1997.
`
`19. Aventail issued press releases announcing it was selling and
`
`distributing these products. Exhibit 1058 is a copy of a May 2, 1997 Aventail
`
`press release announcing the AutoSOCKS v2.1, MobileVPN, and PartnerVPN
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`5
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 5
`
`5
`
`
`
`products. Exhibit 1059 is a copy of a June 23, 1997 article in InfoWorld reviewing
`
`the AutoSOCKS v2.1 and MobileVPN v2.0 products.
`
`20. Aventail included printed manuals with all of the software packages
`
`that it distributed.
`
`21.
`
`Exhibit 1021 is a copy of the Aventail AutoSOCKS v2.1
`
`Administrator’s Guide that was distributed with the AutoSOCKS v2.1 software.
`
`This document was distributed without any confidentiality restrictions.
`
`22.
`
`I estimate that thousands of copies of the Aventail AutoSOCKS v2.1
`
`software that included the AutoSOCKS v2.1 Administrator’s Guide were
`
`distributed to customers during 1997 and 1998.
`
`B.
`
`Aventail Extranet Center (AEC) v3.0
`
`23.
`
`In the fall of 1998, Aventail announced a product called the Aventail
`
`Extranet Center (“AEC”).
`
`24. Aventail issued a press release announcing that this product was
`
`available in the fall of 1998. Exhibit 1060 is a copy of an October 12, 1998
`
`Aventail press release announcing the Aventail Extranet Center 3.0 product.
`
`Exhibit 1061 is a copy of an October 19, 1998 Network World publication
`
`announcing the Aventail Extranet Center 3.0 product.
`
`25.
`
`The AEC product had three components: (i) the Aventail Extranet
`
`Server (which resided and ran on a server computer), (ii) the Aventail Management
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`6
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 6
`
`6
`
`
`
`Server and Config Tool (which was used to configure server and client
`
`installations), and (iii) the Aventail Connect client software (which resided and ran
`
`on client computers).
`
`26.
`
`The initial release version of the AEC product was version 3.0. The
`
`AEC v3.0 product included version 3.01/2.51 of Aventail Connect and version 3.0
`
`of the Aventail Extranet Server.
`
`27.
`
`The AEC product was distributed with printed manuals, including the
`
`Aventail Connect v3.01/2.51 Administrator’s Guide and the Aventail Extranet
`
`Server v3.0 Administrator’s Guide.
`
`28.
`
`Exhibit 1007 is a copy of the Aventail manuals that were distributed
`
`with the AEC v3.0 product.
`
`29.
`
`The Aventail manuals were an interrelated set of documentation for
`
`the Aventail AEC v3.0 products. They were designed to be used together to help
`
`administrators configure and use various components that made up the AEC
`
`product. For example, the Aventail Connect and Extranet Administrator Guides
`
`refer repeatedly to each other when describing how to configure and use the
`
`components of the AEC product. See, e.g., Ex. 1007 (Aventail) at 5, 10-12, 14,
`
`127 (“Instructions covering advanced configuration options, public certificates,
`
`and troubleshooting may be found in the ‘Aventail Connect Administrator’s
`
`Guide’ and in the online Help.”)
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`7
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 7
`
`7
`
`
`
`30.
`
`The Aventail manuals were distributed without any confidentiality
`
`restrictions. Specifically, Aventail customers were not required to accept any
`
`obligations limiting their ability to use or disseminate the information contained in
`
`or associated with the AEC v3.0 product, or the manuals that accompanied the
`
`product.
`
`31.
`
`The AEC v3.0 product, along with the Aventail manuals, was being
`
`sold and distributed to hundreds of customers before January of 1999.
`
`32.
`
`I personally recall that the AEC v3.0 product was distributed
`
`publically at least as early as October 1998.
`
`33.
`
`I also personally distributed copies of the AEC v3.0 product to
`
`customers before January of 1999.
`
`34.
`
`In particular, I personally distributed copies of installation CDs
`
`containing version 3.01/2.51 of the Aventail Connect Client and version 3.0 of the
`
`Aventail Extranet Server, along with the Aventail manuals, to customers and
`
`potential customers at least as early as October 1998.
`
`35.
`
`In addition, when the product began shipping to customers in the fall
`
`of 1998, Aventail made the Aventail manuals (including the Administrator’s
`
`Guides for Aventail Connect and Extranet Center, and the Quick Start Guide)
`
`available via download from the Aventail website, www.aventail.com.
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`8
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 8
`
`8
`
`
`
`36.
`
`I estimate that Aventail distributed thousands of copies of the AEC
`
`v3.0 product (including the Aventail) during the first six months of 1999 alone.
`
`III. Technical Features and Capabilities of Aventail Products
`
`37. All of my comments in this section will concern the Aventail v3.0
`
`product described in Ex. 1007 (Aventail).
`
`38.
`
`Like the earlier Aventail VPN solution (AutoSOCKS), Aventail
`
`Connect would, when paired with the Extranet Server, automatically establish a
`
`VPN between a remote user and a private network to give the remote user access to
`
`secured network resources on a private network. Ex. 1007 (Aventail) at 15-16.
`
`39.
`
`The Aventail Connect client and the Extranet Server could be
`
`configured to automatically authenticate the remote user and encrypt all
`
`communications with the remote user. Ex. 1007 (Aventail) at 16, 76-77.
`
`40.
`
`The Aventail Connect client and Extranet Server products could be
`
`configured to use different authentication techniques, including SOCKS v4
`
`Identification, Username/Password, Challenge Handshake Authentication Protocol
`
`(CHAP), Challenge Response Authentication Method (CRAM), Secure Sockets
`
`Layer (SSL) authentication, and HTTP Basic (username/password). Ex. 1007
`
`(Aventail) at 46-63.
`
`41.
`
`The Aventail Connect client and Extranet Server products could be
`
`configured to use different encryption algorithms and techniques, including SSL
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`9
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 9
`
`9
`
`
`
`encryption and Diffie-Hellman Anonymous encryption, and RC4 and DES ciphers.
`
`Ex. 1007 (Aventail) at 55.
`
`42.
`
`The AEC v3.0 product operates on both “inbound” and “outbound”
`
`connections. Whether a connection was “inbound” or “outbound” is simply a
`
`matter of perspective – an “outbound” request for access to a secure target
`
`computer intercepted by Aventail Connect on the client computer would be an
`
`“inbound” connection from the Extranet Server and the target computer
`
`perspective. I also note that the Aventail Connect user manual points out that the
`
`communications with a client computer were bi-directional – the client not only
`
`sends “outbound” requests but can respond to “inbound” requests. See, e.g., Ex.
`
`1007 (Aventail) at 11 (“You can use Aventail Connect as a simple proxy client for
`
`managed outbound access, and for secure inbound access.”)
`
`43.
`
`I understand that VirnetX, in previous proceedings, has asserted that
`
`its alleged invention is distinguishable from the Aventail system embodied in the
`
`AEC v3.0 product for a variety of technical reasons. See generally Ex. 1051
`
`(Keromytis Decl.) and Ex. 1052 (Nieh Decl).
`
`44.
`
`For example, VirnetX has incorrectly claimed that the AEC v.30
`
`product did not establish a virtual private network. Ex. 1051 (Niehs Decl) at 4.
`
`VirnetX also incorrectly described how the various components of the AEC v3.0
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`10
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 10
`
`10
`
`
`
`product could be configured, and how they work together. Ex. 1052 (Keromytis
`
`Decl) at 7-13.
`
`45.
`
`The Aventail AEC v3.0 product would transparently create a virtual
`
`private network (VPN) between a client computer and a private network. First, the
`
`Aventail Connect client running on the client computer would intercept and
`
`evaluate all TCP/IP application calls on the client computer (e.g., DNS requests
`
`made through a web browser). Either the client computer, or the server if requests
`
`were being proxied, would determine if the request specified a secure destination
`
`(e.g., a host on the private network). If it did, the client would be authenticated and
`
`communications between the client computer and the private network would be
`
`automatically encrypted. Ex. 1007 (Aventail) at 11-16.
`
`46.
`
`I understand that VirnetX has claimed the AEC v3.0 product would
`
`not create a VPN. See Ex. 1051 (Nieh Decl) at ¶ 19. I disagree.
`
`47.
`
`The Aventail Extranet Server worked in conjunction with the Aventail
`
`Connect Client to establish an encrypted communication channel over the Internet
`
`that would allow a client computer to communicate privately over the Internet with
`
`a secure destination on the private network. Ex. 1007 (Aventail) at 13. These are
`
`VPNs. The Aventail manuals even refer to the Aventail ExtraNet Server as being
`
`the “Aventail VPN Server” in the secure extranet example in the Aventail manuals.
`
`See, e.g., Ex. 1007 (Aventail) at 76.
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`11
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 11
`
`11
`
`
`
`48.
`
`I understand that VirnetX has claimed that computers connected with
`
`AEC v3.0 cannot communicate directly with each other as though they were on the
`
`same network. See Ex. 1051 at ¶ 20-22, 26-27 (Nieh Decl). I disagree. In fact, if
`
`this were true, we would not have been able to market a viable product. The whole
`
`point of the Aventail technology and product line was to enable a remote user to
`
`communicate through a VPN with other computers on a private, secure network.
`
`49. Computer applications connected by Aventail Connect and ExtraNet
`
`Center could communicate directly with each other as though they were on the
`
`same network. For example, the AEC v3.0 product included a feature called the
`
`“Extranet Neighborhood.” This feature included a Windows Explorer-type
`
`interface called “Secure Extranet Explorer” that allowed remote users connected
`
`using Aventail Connect to browse and access specific hosts and other network
`
`resources on the corporate network. See Ex. 1007 (Aventail) at 30-31, 94-95.
`
`50.
`
`The Secure Extranet Explorer would allow a remote user connected to
`
`the network using Aventail Connect to browse, copy, move, and delete files on
`
`target host computers. See Ex. 1007 (Aventail) at 94 (“Extranet Neighborhood
`
`offers Aventail Connect users a secure alternative to traditional file-browsing
`
`methods. Users can securely access computers from the desktop through Extranet
`
`Neighborhood [], or through Windows Explorer.”) The Secure Extranet Explorer
`
`thus allowed the remote client computer to access specific network resources on
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`12
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 12
`
`12
`
`
`
`the private computer as though the target host computer and the remote computer
`
`were on the same internal network. Ex. 1007 (Aventail) at 94-95.
`
`51.
`
`I also understand that VirnetX has claimed that the fundamental
`
`operation of the AEC v3.0 product is incompatible with users transmitting data that
`
`is sensitive to network information. See Ex. 1051 (Nieh Decl) at ¶¶ 23-25. Again,
`
`that is incorrect.
`
`52.
`
`The central purpose of the AEC v3.0 product was to allow remote
`
`users to access secure (“sensitive”) network resources. The software was designed
`
`to give those remote users the ability to connect to and share information as if they
`
`were physically connected to the private (e.g., corporate) network. I cannot
`
`understand how anyone familiar with the purpose or operation of the AEC v3.0
`
`product cannot appreciate this point, given that this was its central purpose.
`
`53. We designed the AEC v3.0 product to make the entire process of
`
`gaining access to private network resources as simple, transparent and automatic as
`
`possible. The Aventail v3.0 manuals explain this clearly. Specifically, they show
`
`that a user who wants access to a secure network resource need only specify the
`
`particular host on the private network, either by entering the hostname or IP
`
`address of the target destination in a web browser or by selecting the host directly
`
`using the Secure Extranet Explorer. The Aventail Connect client on the user’s
`
`computer would then transparently intercept that connection request and proxy it to
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`13
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 13
`
`13
`
`
`
`the Aventail Extranet Server, which would authenticate the user and automatically
`
`establish the VPN between it and the user’s computer. Ex. 1007 (Aventail) at 11-
`
`16, 46-55, 77, 80-81, 83, 89, 99, 108, 129-131, 141-142, 144-145, 154-158, 160-
`
`167. The whole point of this was to automatically and transparently create a VPN
`
`between the remote user and the private network that would allow the remote user
`
`to securely access the private network.
`
`54.
`
`I understand that VirnetX has claimed that the use of false DNS
`
`responses in Aventail prevents the correct transfer of data in the Aventail scheme.
`
`See Ex. 1051 (Nieh Decl) at ¶ 25. I also understand that VirnetX has asserted that
`
`the VPN is not initiated in response to determining that the DNS request was
`
`seeking access to secure resources on a private network. Ex. 1052 (Keromytis
`
`Decl) at ¶ 26-36. Each point is incorrect.
`
`55.
`
`There are three basic steps used by all WinSock applications to
`
`establish a connection using a hostname and domain name, namely: (1) a DNS
`
`lookup to identify the IP address associated with the hostname and domain name,
`
`(2) a request to establish a connection to the remote host, and (3) the transmission
`
`and receipt of data through that connection. Ex. 1007 (Aventail) at 12. The
`
`Aventail Connect functionality was nested within these steps. Ex. 1007 (Aventail)
`
`at 15-16.
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`14
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 14
`
`14
`
`
`
`56. As the Aventail manuals explain, each connection request would be
`
`intercepted by the Aventail Connect client on the client computer. Ex. 1007
`
`(Aventail) at 11, 13-14, 15-16. If the request contained a domain name, the
`
`Aventail Connect client would handle evaluation of that domain name in one of a
`
`three ways. First, if the client were configured with local name resolution rules,
`
`and the domain name matched a value on one of those rules, the domain name
`
`would be locally resolved. Second, if the client were configured to proxy all non-
`
`locally resolved domain names to a proxy server, the request would be proxied to
`
`the designated Extranet Server for name resolution and other handling. Finally, if
`
`connection requests were not being proxied, and the domain name did not match a
`
`local name resolution rule, the Aventail Connect client on the client computer
`
`evaluated only the domain part of the fully qualified hostname to see if it should be
`
`securely routed through the Extranet Server. Ex. 1007 (Aventail) at 15-16.
`
`57.
`
`In the latter two scenarios, the Aventail Connect client would insert a
`
`validly formed yet unused and special IP address into the DNS response to trigger
`
`redirection and encryption of that communication through the Extranet Server. Ex.
`
`1007 (Aventail) at 15-16. The Aventail Connect client did not attempt to actually
`
`resolve these false domain name entries, and did not treat them as actual domain
`
`names specifying destinations. Instead, the flag simply informed the Aventail
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`15
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 15
`
`15
`
`
`
`Connect client that the request had to be proxied to the Aventail Extranet Server
`
`associated with the domain name. Ex. 1007 (Aventail) at 16.
`
`58.
`
`In a second step, the client computer would open a connection to the
`
`designated proxy server (i.e., the designated Extranet Server), and the client would
`
`then be authenticated. Ex. 1007 (Aventail) at 15-16. If authentication were
`
`successful, the client and the ExtraNet Server would then transmit the proxied
`
`connection request (i.e., the destination of the request) and then data between the
`
`client and that host on the private network. Ex. 1007 (Aventail) at 16. All of this
`
`data would be automatically encrypted and decrypted by the Aventail Connect
`
`client. Ex. 1007 (Aventail) at 16.
`
`59.
`
`The use of a false DNS entry by Aventail, thus, did not prevent
`
`correct data transfer at any point in this process. Again, it was simply a technique
`
`to flag a connection request requiring proxying to the Extranet Server for handling.
`
`Ex. 1007 (Aventail) at 15-16. Indeed, the Aventail AEC v3.0 product would not
`
`have been a commercial success if it could not perform this basic function of
`
`securely routing traffic to and from the remote client to the secure network.
`
`60.
`
`I understand that VirnetX has said that the Aventail systems do not
`
`return an IP address to the client computer if the DNS request specifies a non-
`
`secure website. See Ex. 1051 (Nieh Decl) at ¶¶ 30-33; Ex. 1052 (Keromytis Decl)
`
`at ¶¶ 40-44. This is incorrect.
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`16
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 16
`
`16
`
`
`
`61.
`
`The way the Aventail Connect client worked shows that it would
`
`return an IP address to a requesting application if a domain name in a connection
`
`request specified a destination other than one on the remote private network.
`
`62.
`
`First, the Aventail Connect client could be configured to resolve
`
`domain names using “local name resolution” rules. Domain names matching a
`
`local name resolution rule were addresses that could be locally resolved (e.g., local
`
`names on the network or by a DNS server on the local network). Names matching
`
`a local name resolution rule would not specify a host on a remote private network
`
`because these requests would be handled locally, and would not be proxied to the
`
`remote network. Also, if local name resolution rules had been created on the
`
`Aventail Connect client, a domain name in a request would be compared to these
`
`rules first, before the request would be evaluated against a redirection rule or
`
`before it would be proxied to the Extranet Server. Ex. 1007 (Aventail) at 15-16.
`
`63.
`
`Second, when a user running Aventail Connect made a DNS request
`
`that did not match either a local name resolution rule or a redirection rule requiring
`
`a VPN, Aventail Connect would pass the request through to the client computer’s
`
`native TCP/IP and DNS subsystems, which would then return an IP address for the
`
`domain name to the requesting application. See Ex. 1007 (Aventail) at 15-16.
`
`This was a well-known “pass-through” technique for resolving unsecured DNS
`
`requests at the time we developed the AEC v3.0 product.
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`17
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 17
`
`17
`
`
`
`64.
`
`Third, Aventail Connect could be configured to proxy all DNS
`
`requests that did not match a local domain name rule to a different computer (the
`
`Aventail Extranet Server) for resolution. In this configuration, the content of the
`
`connection request was not checked by Aventail Connect on the client computer.
`
`Instead, the request was simply proxied to the Extranet Server, which would then
`
`evaluate the request. See Ex. 1007 (Aventail) at 16 (“The special false response
`
`tells Aventail Connect that the DNS lookup must be proxied, and that it must send
`
`the fully qualified hostname to the SOCKS server with the SOCKS connection
`
`request.”) If the request contained a domain name for a public website, the
`
`Extranet Server would resolve the domain name and return the IP address to the
`
`calling application via the Aventail Connect client. All of this was transparent to
`
`the calling application that made the connection request. See Ex. 1007 at 16
`
`(“From the application’s point of view, the entire SOCKS negotiation, including
`
`the authentication negotiation, is merely the TCP handshaking.”)
`
`65.
`
`In any of these configurations, the IP address of a “non-secure”
`
`destination specified by a domain name will be returned to the client computer.
`
`This was important to the design of the product – it helped make the operation of
`
`the client “transparent.” Ex. 1007 (Aventail) at 15 (“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.
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`18
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 18
`
`18
`
`
`
`The TCP/IP stack performs the lookup as if Aventail Connect were not running.”);
`
`Ex. 1007 (Aventail) at 77 (“Second, not all traffic passes through to the Aventail
`
`ExtraNet Server. 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.”)
`
`66.
`
`I understand that VirnetX has claimed that “Nothing in Aventail
`
`discloses returning an error from a DNS request.” See Ex. 1052 (Keromytis Decl.)
`
`at ¶ 37. This too is incorrect.
`
`67.
`
`The Aventail Connect and Aventail ExtraNet Server products were
`
`inherently DNS-based schemes. If a domain name in a request could not be
`
`resolved, an error would be returned to the calling application. This again, is a
`
`consequence of how DNS servers work.
`
`68.
`
`I note that it was possible to configure Aventail Connect to proxy all
`
`requests – including both secure and non-secure destinations – to the Aventail
`
`ExtraNet Server for handling. This would be done, for example, to prevent a user
`
`while on a VPN from directly accessing a public website. In this configuration, if
`
`the proxied request contained a domain name of a public website (e.g.,
`
`“apple.com”), the Aventail ExtraNet Server would resolve the name and return the
`
`IP address.
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`19
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 19
`
`19
`
`
`
`69.
`
`If the name could not be resolved, an error would be returned. So, for
`
`example, if a user failed authentication, an error, typically “host unknown,” would
`
`be returned to the calling application. Similarly, if accessing the public website
`
`would violate a policy (e.g., visiting a competitor’s website while on the VPN), the
`
`Aventail ExtraNet Server would refuse to resolve the domain name, and the “host
`
`unknown” error again would be returned to the calling application.
`
`70.
`
`I understand that VirnetX has claimed that the IP address-hopping
`
`schemes employed by the AEC v3.0 product do not “contribute in a meaningful
`
`way” to the processes used by the AEC product to secure data being transmitted
`
`over a public network. See Ex. 1052 (Keromytis Decl.) at 38. That is incorrect.
`
`71.
`
`There were two IP address-hopping schemes used by the AEC v3.0
`
`product; namely, “Proxy Chaining” and the “MultiProxy” scheme.
`
`72.
`
`The Aventail Proxy Chaining feature would forward connections for
`
`certain destinations through a succession of proxy servers. Ex. 1007 (Aventail) at
`
`67-68. Each step or “hop” is an authenticated and encrypted link between the
`
`originating destination and the next destination. The overall path would ultimately
`
`connect the client computer to the final destination (e.g., the Extranet Server). Ex.
`
`1007 (Aventail) at 63, 67.
`
`73.
`
`The Aventail MultiProxy feature functioned in an analogous manner,
`
`allowing Aventail Connect to make connections or “hops” through successive
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`20
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 20
`
`20
`
`
`
`proxy servers, where each formed an authenticated and encrypted link that
`
`connected the client computer to the final destination. Ex. 1007 (Aventail) at 63.
`
`In the MultiProxy scheme, the Aventail Connect client made connections to each
`
`proxy server in the chain individually, any or all of which could apply separate
`
`authentication, access control rules, and encryption, providing an additional level
`
`of security. Ex. 1007 (Aventail) at 63, 67.
`
`74. Both the Proxy Chaining and MultiProxy features meaningfully
`
`contributed to the security of the VPNs established between client computers and
`
`the private network. In fact, the Proxy Chaining and Multi-Proxy features were
`
`included in the AEC v3.0 product to give administrators more control over the
`
`routing of traffic between a client and a private network to improve the overall
`
`security of their systems. Ex. 1007 (Aventail) at 67. For example, the Proxy
`
`Chaining capability would maintain an authenticated and encrypted tunnel between
`
`each proxy server and the Aventail Extranet Server. Ex. 1007 (Aventail) at 67-68.
`
`The MultiProxy feature similarly would maintain authenticated and encrypted
`
`tunnels between a client computer and a secure target destination. Ex. 1007
`
`(Aventail) at 67.
`
`75.
`
`I understand that VirnetX has claimed the AEC v3.0 product did not
`
`use authentication tables to authenticate client computers that were trying to access
`
`a secure network. See Ex. 1052 (Keromytis Decl) at ¶¶ 46-47. That is incorrect.
`
`Declaration Of Chris Hopen
`Regarding U.S. Patent No. 6,502,135
`
`21
`
`Petitioner Apple – Ex. 1005
`
`Petitioner RPX Corporation - Ex. 1005, p. 21
`
`21
`
`
`
`76.
`
`The Extranet Server product used tables of locally stored data to
`
`authorize client computers attempting to gain access to a private network the
`
`Extranet Server was protecting. For example, each end user on a client computer
`
`running Aventail Connect had to present authentication credentials to the Extranet
`
`Server in order to establish a VPN between the client computer and the secure
`
`destination requested by the user. See Ex. 1007 (Aventail) at 139-152, 156. To
`
`validate those credentials, the Extranet Server would perform an authentication
`
`process on the server for each authorized user to prove their identity. Ex. 1007
`
`(Aventail) at 156. If the user on the client computer running Aventail Connect
`
`presented valid authentication credentials to the Extranet Server that user would be
`
`authenticated and a VPN established. Ex. 1007 (Aventail) at 139-152, 156.
`
`Otherwise, no VPN would be established and the requested connection to the
`
`secure destination would be denied.
`
`77.
`
`The Extranet Server also could be configured to defin