EXHIBIT E3
`
`DECLARATION OF JAMES CHESTER
`
`Petitioner Apple Inc. — Exhibit 1022, Cover
`
`Petitioner Apple Inc. - Exhibit 1022, Cover
`
`

`
`In re U.S. Patent No. 7,490,151
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`) )
`
`) Group Art Unit: Central
`)
`Reexamination Unit
`
`Examiner:
`
`Confirmation No.:
`
`) )
`
`) )
`
`) ) ) )
`
`In re Patent No. 7,490,151
`
`Filed:
`
`September 30, 2002
`
`Issued:
`
`February 10, 2009
`
`Inventors:
`
`Munger et al.
`
`For:
`
`ESTABLISHMENT OF A SECURE
`
`COMMUNICATION LINK BASED
`
`ON A DOMAIN NAME SERVICE
`
`(DNS) REQUEST
`
`DECLARATION OF JAMES CHESTER UNDER 37 C.F.R. § 1.132
`
`I, JAMES SAMUEL CHESTER, do hereby declare and state:
`
`1.
`
`2.
`
`3.
`
`A.
`
`4.
`
`5.
`
`I am a citizen of the United States, and reside in Florida. My c.v. is attached as Exhibit
`A.
`
`I am being compensated for my time at a rate of $375.00 per hour.
`
`In addition to the documents provided as exhibits to this declaration, I have reviewed
`documents including the following:
`
`-
`
`-
`
`U.S. Patent No. 7,490,151 (the ‘ISI patent);
`
`Declaration of Jason Nieh from Reexamination Control No. 95/001 ,269.
`
`My Background
`
`I am presently CEO of a software development and consulting firm called Assured
`Products Group, which specializes in software development, consulting, and regulatory
`compliance.
`
`From March 1992 to August 2002, I was employed by the International Business
`Machines Corp. (IBM). During the period 1996 to 2002, I was responsible for global
`strategic initiatives overseeing design and implementation of secure networking services,
`architecture, and cost reductions for IBM worldwide and IBM clients. In that role, I
`evaluated network security products and services from many vendors, and for designing
`and implementing these products and services that IBM designed and implemented for its
`clients.
`
`Petitioner Apple Inc. — Exhibit 1022, p. l
`
`Petitioner Apple Inc. - Exhibit 1022, p. 1
`
`

`
`In re U.S. Patent No. 7,490,151
`
`6.
`
`7.
`
`8.
`
`B.
`
`9.
`
`Between 1996 and 2000, I recall receiving a number of VPN networking products from
`Aventail, Inc.
`I recall using these Aventail VPN products to develop virtual private
`networking solutions for several hundred IBM clients during this period as well as remote
`access systems used by IBM employees worldwide. CSC, DuPont, and a number of
`companies had deployed the Aventail solutions and I gave many seminars during this
`period describing secure communication designs that used the Aventail solutions.
`Competitors quickly adopted the virtual secure network and communication architecture
`we employed with Aventail.
`
`IBM was advancing the use of both hosted and distributed systems through secure
`networks to routinely communicate company private information internally as well as
`externally for mobile computing employees and employees assigned behind firewalls on
`customer premises.
`I estimate that solutions based on Aventail products were deployed
`to more than 65,000 users in IBM alone by the end of 1998, and were deployed to many
`thousands more during 1999.
`
`In my role as Vice President or Strategy and Strategic Initiatives, I oversaw and
`operationally deployed networking security solutions that leveraged the improvements
`that we saw in the 1990s in the core elements of networking security; namely,
`communications, routing, security, verification, and paths. In that role, I led activities for
`internal and external network design, development, and solutions. That included all
`aspects from access to verification to exchange.
`
`Aventail VPN Products Distributed Between 1996 and 2000
`
`Aventail distributed several VPN products during the period 1996 and 2000. Each of
`these products included a server component and a client component.
`
`10.
`
`One Aventail VPN solution included client software called AutoSOCKS which could be
`
`paired with two versions of VPN server software. One version of the Aventail server
`software was focused on remote employees and was called MobileVPN. The other
`package focused on non-employees and was called PartnerVPN. Both server products
`functioned identically in how they worked with the AutoSOCKS client to automatically
`establish VPNs between remote users and private network resources.
`
`11.
`
`Aventail distributed several versions of AutoSOCKS and MobileVPN/PartnerVPN
`
`products between 1996 and 2000. Each new version of each component had a higher
`version number.
`
`12.
`
`13.
`
`The Aventail products were distributed with installation discs and printed manuals for
`each of the software packages. Exhibit B is a copy of the Administrator’s Guide for
`version 2.1 of the Aventail AutoSOCKS client software.
`I received this document on
`
`approximately December 1997.
`
`At the time I received Exhibit B, I was under no obligation to keep this document secret
`or to not distribute it to others. In fact, we distributed the AutoSOCKS Administrator’s
`Guide with the other printed materials that came with the Aventail AutoSOCKSNPN
`Server to IBM clients to whom we deployed VPN solutions, as well as IBM employees.
`
`-2-
`
`Petitioner Apple Inc. — Exhibit 1022, p. 2
`
`Petitioner Apple Inc. - Exhibit 1022, p. 2
`
`

`
`In re U.S. Patent No. 7,490,151
`
`By the spring of 1998 we were giving seminars and interviews on the solution and
`benefits.
`
`14.
`
`A second VPN solution Aventail distributed between 1996 and 2000 was called the
`
`Aventail Extranet Center (AEC). This product included client software called Aventail
`Connect and server software called Aventail Extranet Server.
`
`15.
`
`16.
`
`17.
`
`18.
`
`19.
`
`20.
`
`21.
`
`22.
`
`I recall that Aventail armounced its AEC v3.0 product in the fall of 1998, and began
`distributing this product no later than mid-January of 1999. Because IBM was the largest
`user of Aventail VPN products, we would be one of the first companies to receive new
`versions of the Aventail products; both evaluation and production products.
`I was
`personally involved in Aventail’s strategic planning and direction from March 1998.
`
`The AEC v3.0 product included version 3.01/2.51 of the Aventail Connect software, and
`version 3.0 of the Aventail Extranet Server.
`
`Exhibit C is a copy of the Administrator’s Guide for Aventail Connect v3.01/2.51.
`recall receiving Exhibit C with the AEC v3.0 product no later than July 1998.
`
`I
`
`At the time I received Exhibit C, I was under no obligation to keep this document secret
`or to not distribute it to others. Like earlier Aventail products, we distributed copies of
`the AutoSOCKS Administrator’s Guide along the other printed materials that came with
`the Aventail AutoSOCKS/VPN Server to IBM clients to whom we deployed VPN
`solutions, and to IBM employees using the Aventail Connect v3.01/v2.51 client.
`
`The AEC product was a very versatile and stable VPN solution. It received very good
`reviews from the technical press. We deployed VPN solutions based on this product to
`more than 20,000 IBM employees domestically by March 1998 and more than 65,000
`IBM employees worldwide by July 1998.
`
`Aventail distributed an updated version of the AEC product in the summer of 1999. This
`updated version was designated AEC v3.1, and included Aventail Connect v3.1/2.6 and
`Aventail Extranet Server v3 . 1.
`
`I recall receiving the AEC v3.1 product no later than the end of June of 1999. The
`product I received included the installation discs for the Aventail Connect v3.1/2.6 client
`software and V3.1 of the Aventail Extranet Server software. It also included printed
`manuals for these products, including the Aventail Connect v3.1/2.6 Administrator’s
`Guide, a copy of which is shown in Exhibit D.
`
`At the time I received Exhibit D, I was under no obligation to keep this document secret
`or to not distribute it to others. Again, as was the case with earlier Aventail products, we
`distributed copies of the AutoSOCKS Administrator’s Guide along the other printed
`materials that came with the Aventail AutoSOCKS/VPN Server to IBM clients to whom
`
`we deployed VPN solutions, and to IBM employees that were using the Aventail Connect
`v3.1/2.6 client. By the summer of 1999, this product was routinely packaged with IBM
`offerings in all business sectors worldwide. Competitors were deploying this product as
`well in the same timeframe.
`
`Petitioner Apple Inc. — Exhibit 1022, p. 3
`
`Petitioner Apple Inc. - Exhibit 1022, p. 3
`
`

`
`In re U.S. Patent No. 7,490,151
`
`C.
`
`Relevant Background on TCP/IP Communications
`
`23.
`
`24.
`
`25.
`
`26.
`
`27.
`
`Two of the claims of the ’15l patent refer to IP hopping schemes or regimes.
`been asked to provide some background on IP hopping schemes.
`
`I have
`
`The TCP/IP protocol was designed to employ flexible routing of traffic. IP packets are
`datagrams that contains source and destination IP addresses. These IP packets or
`datagrams traverse a network by being routed between devices (also called nodes).
`Under the design of the TCP/IP protocol, there is no requirement for an IP packet to take
`a pre-defined path from source to destination unless the IP packet is being routed over a
`statically configured network. IP packets thus can take multiple different paths to reach
`the same destination.
`
`Routes that an IP packet will take from source to destination are determined by each
`node/host as it processes the IP datagram. The destination IP of the datagram is
`compared to a locally maintained routing table, and the IP packet is forwarded as deemed
`appropriate.
`
`TCP/IP hosts use a routing table to maintain knowledge about other IP networks and IP
`hosts. Networks and hosts are identified by using an IP address and a subnet mask. In
`addition, routing tables are important because they provide needed information to each
`local host regarding how to communicate with remote networks and hosts. Because it is
`impractical for each computer on an IP network to maintain a routing table having entries
`for every other computer or network that communicates with it, a default gateway (IP
`router) is used instead.
`
`When a computer prepares to send an IP datagram, it inserts its own source IP address
`and the destination IP address of the recipient into the IP header. The computer then
`examines the destination IP address, compares it to a locally maintained IP routing table,
`and takes appropriate action based on what it finds. The computer does one of three
`things:
`
`a.
`
`b.
`
`It passes the datagram up to a protocol layer above IP on the local
`host.
`
`It forwards the datagram through one of its attached network
`interfaces.
`
`c.
`
`It discards the datagram.
`
`28.
`
`When the computer searches the routing table to identify a route for an IP packet, it will
`look for the closest match to the destination address. The most specific to the least
`specific route is searched for in the following order:
`
`a.
`
`b.
`
`A route that matches the destination IP address (host route).
`
`A route that matches the network ID of the destination IP address
`
`(network route).
`
`Petitioner Apple Inc. — Exhibit 1022, p. 4
`
`Petitioner Apple Inc. - Exhibit 1022, p. 4
`
`

`
`In re US. Patent No. 7,490,151
`
`c.
`
`The default route.
`
`29.
`
`30.
`
`31.
`
`32.
`
`33.
`
`If a matching route is not found, the datagram is discarded.
`
`Routing algorithms can be static or dynamic. A static route implies that every route is
`known and manually entered. Dynamic routing uses tables that are updated via different
`protocols. The two most commonly used protocols in the 1997-2000 time frame were the
`RIP protocol (see, Malkin, G., “RIP Version 2,” RFC 2453 (November 1998) (available
`at http://www.networksorcery.com/enp/rfc/rfc2453.txt)) and the OPSF protocol (see
`Moy, J., “OSPF version 2,” RFC 2328 (April 1998) (available at http
`://tools.ietf.org/html/rfc2328).
`
`Communications between networks relies upon traffic being routed from the source to the
`destination. In TCP/IP communications, the source will encapsulate a TCP message
`within an IP datagram; the header of the datagram will contain the source and destination
`addresses. The source will then encapsulate the IP datagram into a layer 2 frame for
`transmission across the intemetwork hop/link. IF the source does not know the route to
`the destination address, it will send the packet to its network gateway. From the gateway
`until the destination, each node will remove the IP datagram from its layer 2
`encapsulation. The destination address contained within the IP datagram header is then
`compared to the current node’s routing table and the best route is determined. The node
`will then re-encapsulate the IP datagram into a layer 2 frame and pass the datagram along
`the next hop/link of the network that best matches the destination address.
`
`Dynamic routing based on RIP or OPSF standards are inherently flexible. So, if one link
`the network goes down or becomes unavailable, the route can be changed. Routing tables
`are simply updated to provide the new routes, and the packets get sent along a different
`path to the destination. When IP packets are sent over the public Internet, and are not
`routed manually, they inherently will follow pseudorandom paths — the path is not
`defined until its actually taken by the IP packet, and each IP packet will likely travel on
`different paths even when the source and destinations are the same.
`
`Any TCP/IP communication will inherently meet the requirement in the ’ 151 patent
`claims that IP packets must be sent from a client computer to a secure destination by an
`“IP hopping” scheme or regime. As I explained above, IP hopping is integral to the
`design of TCP/IP communications, and occurs whenever an IP packet is sent from a
`source to a destination via a TCP/IP communication.
`
`D.
`
`Observations of the Declaration of Dr. Jason Nieh in a Prior Reexamination
`
`34.
`
`I reviewed a declaration submitted by Dr. Jason Nieh in Reexamination Control No.
`95/001,269 involving U.S. Patent No. 6,502,135, the parent of the ’ 151 patent.
`I believe
`several of Dr. Nieh’s statements in his declaration do not accurately describe how the
`Aventail products work or what is described in the Administrator’s Guide for Aventail
`Connect V3.1/2.6 (Exhibit D).
`
`35.
`
`Dr. Nieh’s general conclusion is that the Aventail VPN products did not establish VPNs
`as they are defined in the claims of the ’l35 patent. This is incorrect. Based on my
`
`-5-
`
`Petitioner Apple Inc. — Exhibit 1022, p. 5
`
`Petitioner Apple Inc. - Exhibit 1022, p. 5
`
`

`
`In re U.S. Patent No. 7,490,151
`
`36.
`
`37.
`
`38.
`
`39.
`
`40.
`
`41.
`
`personal experience using these products, they were routinely used by remote users to
`establish VPNs, and that those VPNs met the requirements of the claims of the ’135
`patent.
`
`Initially, I understand that a court has interpreted certain phrases in the claims of the ’ 135
`patent, including “virtual private network” or “VPN.” The meaning of VPN was simply
`“a network of computers which privately communicate with each other by encrypting
`traffic on insecure communication paths between the computers.” This is precisely what
`Exhibit D shows client computers running Aventail Connect doing.
`
`Initially, Dr. Nieh states that he believes the Aventail Connect v3.1/2.6 client software
`was simply a SOCKS v5 client. See Nieh Declaration, paragraphs 11 to 14. Aventail
`Connect v3.1, like the earlier Aventail Connect v3.01/2.51 and the Aventail AutoSOCKS
`
`clients, did much more than handle SOCKS transactions.
`
`The Aventail Connect and Extranet Server, like the earlier Aventail VPN solutions, used
`well-established network security techniques. For example, the Reverse Address
`Resolution Protocol (RARP) has been in existence since June 1984, while session IDs
`and session synchronization have been in existence since the 1960s.
`
`Client computers running each of the Aventail clients (i.e., Aventail Connect and
`Aventail AutoSOCKS) could automatically establish VPNs that allowed a remote user to
`gain access to secure resources on a private network. These products all worked by
`transparently intercepting and evaluating DNS and TCP/IP connection requests made on
`the client computer.
`
`The Aventail clients could be configured in one of two ways. First, they could be
`configured to determine if a connection request specified a destination that required a
`VPN (e.g., a secure website on a private network). If so, the client would automatically
`re-route that connection to a VPN server, manage authentication of the user with the VPN
`server, and encrypt/decrypt the outgoing and incoming network traffic.
`
`Second, the Aventail clients could be configured to route all DNS requests containing
`hostnames that could not be resolved on the local computer to a VPN server. In this
`configuration, the client computer would establish a connection to the VPN server,
`authenticate itself with the server, and if that was successful, it would then send the
`hostname from the original DNS request to the VPN server. The VPN server (i.e.,
`Aventail Extranet Center or Aventail MobileVPN/PartnerVPN) would then resolve the
`hostname (if necessary) and then determine if a VPN was needed between the requesting
`client and the destination. If no VPN was required, the VPN server would return the
`resolved IP address back to the client.
`
`42.
`
`In either configuration, if a connection request was not seeking access to a secure
`destination requiring a VPN, it would just be handed off to the normal TCP/IP handling
`procedures of the client computer for handling. So, for example, if the VPN server had
`done the hostname resolution and returned a resolved IP address, WinSock and the
`
`Petitioner Apple Inc. — Exhibit 1022, p. 6
`
`Petitioner Apple Inc. - Exhibit 1022, p. 6
`
`

`
`In re U.S. Patent No. 7,490,151
`
`TCP/IP stack on the client computer would then just establish a connection to the
`specified IP address without the Aventail client being involved any further.
`
`43.
`
`For the Aventail Connect v3.1/2.6 client, this functionality is described on Page 9 of
`Exhibit D:
`
`When the Aventail Connect LSP receives a connection request, it
`determines whether or not the connection needs to be redirected (to an
`Aventail ExtraNet Server) and/or encrypted (in SSL). When redirection
`and encryption are not necessary, Aventail Connect simply passes the
`connection request, and any subsequent transmitted data, to the TCP/IP
`stack.
`
`44.
`
`Exhibit D describes a VPN design made up of client computers running Aventail Connect
`v3.1/2.6 connecting to a private network through an Aventail VPN server. See Exhibit D
`at pages 76 to 78.
`I note that Dr. Nieh did not discuss this section of Exhibit D in his
`declaration.
`
`45.
`
`Page 77 of Exhibit D explains this VPN implementation as follows:
`
`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
`allowed. The client workstations we focus on in this section are Microsoft
`
`Windows based PCs. (emphasis added)
`
`46.
`
`Exhibit D on pages 12 to 13 also explains that client computers running Aventail Connect
`will automatically handle authentication of the remote user, as well as encryption of the
`traffic between the remote user’s computer and the private network:
`
`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.
`
`47.
`
`All of this functionality was also present in Aventail Connect v3.01/2.6 and AutoSOCKS
`v2.1. See Exhibit B at pages 7 to 9 and 37 to 39; Exhibit C at 11 to 12 and 72 to 74.
`
`Petitioner Apple Inc. — Exhibit 1022, p. 7
`
`Petitioner Apple Inc. - Exhibit 1022, p. 7
`
`

`
`In re U.S. Patent No. 7,490,151
`
`48.
`
`Dr. Nieh provides three general reasons why he believes that Aventail Connect and
`Aventail Extranet Server did not create VPNS within the meaning of the ‘ 135 patent
`claims.
`
`49.
`
`First, in paragraph 20, Dr. Nieh states:
`
`Aventail has not been shown to demonstrate that computers connected via
`the Aventail system are able to communicate with each other as though
`they were on the same network. Aventail discloses establishing a point-to-
`point SOCKS connection between a client computer and a SOCKS server.
`According to Aventail, the SOCKS server then relays data received to the
`intended target. Aventail does not disclose a VPN, where data can be
`addressed to one or more different computers across the network,
`regardless of the location of the computer.
`
`50.
`
`51.
`
`52.
`
`53.
`
`I found nothing in the claims of the ’l35 patent that require that a computer connected to
`a private network to communicate directly with other remote computers that are also
`connected to the network. Instead, all that is required for there to be a VPN is “a network
`of computers which privately communicate with each other by encrypting traffic on
`insecure communication paths between the computers..”
`
`Regardless, Exhibit D shows that client computers running Aventail Connect v3.1/2.6 did
`have the ability to communicate with other computers on the network, including other
`remote users.
`
`For example, the figure on page 77 of Exhibit D shows a remote user using a client
`computer running Aventail Connect to gain access to and to interact with different
`computers on a private network. Network traffic from the remote computers is sent into
`the private network, and handled by the rules and policies governing all network traffic
`on that private network. As explained on page 77 of Exhibit D:
`
`Depending on the security policy and the Aventail ExtraNet Server
`configuration, Aventail Connect will automatically proxy their [the client
`computer’s] allowed application traffic ing 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 allowed.
`
`This explanation makes it clear that a remote user running Aventail Connect could
`interact with any resources on the private network that the user was authorized to access.
`It also shows that a mobile user connected through Aventail Connect will be equivalent to
`a local user on the private network — both the remote and local users will be able to send
`and receive traffic to and from destinations on the private network. So, if network
`policies allowed a user to route network traffic to other users on the private network
`(including remote users), a remote user connected to that network through the Aventail
`VPN solution will be able to communicate to those other users.
`
`Petitioner Apple Inc. — Exhibit 1022, p. 8
`
`Petitioner Apple Inc. - Exhibit 1022, p. 8
`
`

`
`In re U.S. Patent No. 7,490,151
`
`54.
`
`Exhibit D also describes the ability of client computers running Aventail Connect to
`dynamically navigate resources made available on a private network via the “Secure
`Extranet Explorer” capability of Aventail Connect. As Exhibit D explains on page 95:
`
`Secure Extranet Explorer (SEE) allows you to view your Extranet
`Neighborhood, which is accessed through the Extranet Neighborhood icon
`on your desktop. The Extranet Neighborhood user interface resembles that
`of Network Neighborhood. However, while Network Neighborhood
`displays all computers on your local network, Extranet Neighborhood
`allows you to browse, copy, move, and delete files from remote computers
`via the Aventail Connect extranet connection. With Extranet
`
`Neighborhood, all interaction with the remote server can be secured.
`Network administrators determine which local and remote computers are
`available to users.
`
`So, if a private network had the appropriate policies in place, a remote user would be able
`to view and access resources on any of the computers on the network, including those on
`other remote computers/servers.
`
`The second reason Dr. Nieh offers to support his belief that the Aventail VPN products
`did not establish VPNs was that “Aventai1 Connect’s fundamental operation is
`incompatible with users attempting to transmit data that is sensitive to network
`information.” See Nieh Declaration at paragraph 24-25.
`
`Dr. Nieh incorrectly suggests that applications making DNS requests will try to make
`connections using the “false network information” that Aventail Connect uses to flag
`connection requests requiring a VPN. Specifically, Dr. Nieh says that:
`
`24. Because Aventail discloses that Aventail Connect operates between
`these layers, Aventail Connect can intercept DNS requests requested by
`the user. Aventail Connect intercepts certain DNS requests, and returns a
`false DNS response to the user if the requested hostname matches a
`hostname on a user—defined list. Accordingly, Aventail discloses that the
`user will receive false network information from Aventail Connect for
`these hostnames.
`
`25. If the client computer hopes to transfer to the target data that is
`sensitive to network information, this falsification of network information
`would prevent the correct transfer of data. A client and target connected
`according to Aventail would be unable to transfer data as they otherwise
`would have been had they been on the same network. Thus, Aventail has
`not been shown to disclose a VPN
`
`Dr. Nieh has apparently misunderstood how client computers running Aventail Connect
`actually function.
`
`As explained on pages 11 to 13 of Exhibit D, Aventail Connect would monitor DNS
`requests made by applications on the client computer. If the DNS request contained a
`
`55.
`
`56.
`
`57.
`
`58.
`
`59.
`
`-9-
`
`Petitioner Apple Inc. — Exhibit 1022, p. 9
`
`Petitioner Apple Inc. - Exhibit 1022, p. 9
`
`

`
`In re U.S. Patent No. 7,490,151
`
`hostname instead of a literal IP address, and that hostname specified a secure destination
`that required a VPN, then Aventail Connect would insert a false hostname into the DNS
`request. See, e. g., Exhibit D at page 12 (“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”) Similarly, if the Aventail Connect client computer was
`configured to proxy all non-local DNS requests to a separate computer for resolution,
`Aventail Connect would return a false DNS entry that it could recognize later to the
`requesting application.
`
`In a second step, Aventail Connect would evaluate the connection request to see if it had
`to be redirected to the VPN proxy server. If a connection request contained the “false”
`information inserted in step 1 or because the real IP address was on a redirection list], the
`Aventail Connect client would establish a connection to the VPN proxy server (i.e.,
`Aventail Extranet Server). The VPN Server and the Aventail Connect Client would then
`perform authentication, and if that was successful, the VPN would be established
`between the client computer and the destination computer specified in the original
`connection request. See, Exhibit D, pages 12-13 (steps 2 and 3). False hostnames thus
`were used by Aventail Connect to flag DNS requests requiring redirection to a VPN
`server during the TCP connection process, and would not cause client computers to
`attempt to connect to “false” destinations.
`
`As Exhibit D explains on pages 12-13, this entire process is transparent to the client
`computer: “From the application’s point of view, the entire SOCKS negotiation
`including the authentication negotiation, is merely the TCP handshaking.” In other
`words, the application on the client computer requesting a connection would not act on
`the “false hostname” information, but would simply see a connection being established
`with the destination specified in the connection request.
`
`I also recall based on my personal experiences using Aventail Connect v3.1/2.6 (and with
`earlier versions dating back to 1997) that client computers running Aventail Connect
`were able to transfer data to a private network as if they had been on the same network,
`and that the false hostname inserted in DNS requests by Aventail Connect did not impede
`or disrupt the secure communications between the client and the private network,
`specifically useful with large host applications, including expense reports, technical
`journals, images, program specific communications and operations management.
`
`Dr. Nieh’s third reason why he believes that Aventail Connect did not establish VPNS is
`that he believes computers running Aventail Connect “do not communicate directly with
`each other.” This is incorrect. As explained above, Exhibit D shows traffic from a client
`computer running Aventail Connect being automatically proxied ing the private network.
`What the network does with that traffic at that point was dictated by the policies that were
`enforced on the network. If those policies permitted a user to interact with another
`
`As explained in step 2(a) on page 12 of Exhibit D, if the DNS request did not include a host
`name, but was a real IP address (e.g., 1.2.3.4), then no DNS resolution step is needed.
`
`60.
`
`61.
`
`62.
`
`63.
`
`1
`
`-10-
`
`Petitioner Apple Inc. — Exhibit 1022, p. 10
`
`Petitioner Apple Inc. - Exhibit 1022, p. 10
`
`

`
`In re U.S. Patent No. 7,490,151
`
`64.
`
`65.
`
`66.
`
`67.
`
`68.
`
`69.
`
`computer attached to the private network through Aventail Connect, then that traffic
`would be routed to that computer. This capability was particularly useful for employees
`at customer locations behind external firewalls.
`
`In addition, as I explained in paragraphs 50 to 54 above, the Secure Extranet Explorer
`functionality of Aventail Connect described on pages 95 to 106 of Exhibit D enabled
`remote users running Aventail Connect on client computers to see, navigate to and access
`resources on other remote computers.
`
`If Dr. Nieh’s belief is that a client computer could not establish a VPN if it did not send
`its network traffic “directly” to another computer (i.e., not via a gateway computer or
`other intermediary computer), then no VPN could ever be established. Any form of
`network traffic is inherently routed over intermediary nodes; this is a central feature of
`the TCP/IP protocol. A client computer does not have to establish a direct connection to
`a destination computer in order to establish a secure connection to a destination
`computer; the fact that its traffic will pass through an intermediary computer, such as the
`Aventail VPN server as described on pages 76 to 78 of ibit D, is simply irrelevant.
`
`In the Aventail VPN solution — like other types of VPN solutions — an intermediary
`computer (e.g., a proxy server or gateway) evaluates incoming traffic, blocks
`unauthorized traffic, and regulates authentication, encryption and transit of the incoming
`and outgoing traffic. The communication between a remote user on a client computer
`occurs via the intermediary computer (e.g., the VPN server) to the destination on the
`private network.
`
`Dr. Nieh apparently has confused the issue of network communication with the issue of
`how network traffic is routed. Exhibit D plainly shows client computers running
`Aventail Connect communicating privately with destination computers on the private
`network via insecure communication paths (i.e., over public networks, such as the
`Internet). These communications are encrypted, and enable the client computer to gain
`access to resources on a private network.
`
`Dr. Nieh also expresses his opinion that Exhibit D does not disclose a virtual private
`network according to claim 10 of the ’135 patent. This claim defines a VPN system. Dr.
`Nieh does not include any particular reasons to support his conclusion, other than to refer
`to his other opinions in the declaration. See Nieh Declaration at Paragraphs 28 and 29.
`
`Finally, Dr. Nieh inaccurately discusses DNS resolution on client computers running
`Aventail Connect software.
`In paragraph 30, he describes requirements listed in claim 10
`of the ’135 patent. One of these is that “a DNS proxy ...retums the IP address for the
`requested domain name if it is determined that access to a non-secure web site has been
`requested.” Dr. Nieh then states in paragraph 32 that Aventail Connect will not do this
`because “if the hostname matches a local domain string or does not match a redirection
`rule, Aventail Connect passes the name resolution