`
`
`
`
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`___________________
`
`Apple Inc.
`Petitioner,
`
`v.
`
`Virnetx, Inc. and Science Applications International Corporation,
`Patent Owners
`
`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 No. IPR2013-00348 and IPR2013-00349
`__________________________________________________________________
`
`
`DECLARATION OF JAMES CHESTER UNDER 37 C.F.R. § 1.132
`
`
`
`
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`1
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 1
`
`
`
`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 willful 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
`
`reexamination proceeding.
`
`James Chester
`
`
`
`/13-“. N/ 3
`Date
`
`Declaration Of James Chester
`
`Regarding US. Patent No. 7,490,151
`
`2
`
`Petitioner Apple — Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 2
`
`Petitioner RPX Corporation - Ex. 1006, p. 2
`
`
`
`
`
`
`
`
`INTRODUCTION
`A. Engagement
`1.
`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.
`3.
`
`Background and Qualifications
`
`I am a citizen of the United States, and reside in Florida.
`
`4. My c.v. is submitted herewith as Exhibit 1062.
`
`5.
`
`6.
`
`I am being compensated for my time at a rate of $375.00 per hour.
`
`I am presently CEO of a software development and consulting firm
`
`called Assured Products Group, which specializes in software development,
`
`consulting, and regulatory compliance.
`
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`3
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 3
`
`
`
`
`
`
`
`7.
`
`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.
`
`8.
`
`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 for remote access for IBM employees
`
`worldwide. CSC, DuPont, and a number of companies had deployed the solution
`
`based on Aventail marketing efforts and seminars given by Aventail and IBM
`
`during this period as well. Competitors quickly adopted the virtual secure
`
`network and communication architecture we employed with Aventail.
`
`9.
`
`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 VPN solutions we
`
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`4
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 4
`
`
`
`
`
`
`
`deployed for clients based on Aventail products were used by more than 65,000
`
`users in IBM alone during the period 1996 to 2000 around the world.
`
`10.
`
`In my role as Vice President of 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. These
`
`solutions were publically available and showcased to support commercial
`
`endeavors and as such were extensively covered in the trade press.
`
`C.
`Public Availability of the Aventail VPN Products
`11. Aventail distributed several VPN products during the period 1996 and
`
`2000. Each of these products included a server component and a client component.
`
`12. 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.
`
`13. Aventail distributed several versions of AutoSOCKS and
`
`MobileVPN/PartnerVPN products between 1996 and 2000. Each new version of
`
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`5
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 5
`
`
`
`
`
`
`
`each component had a higher version number. Numerous evaluation disks,
`
`technical write-ups, and associated marketing materials were available to any and
`
`everyone who asked for them to help promote awareness and customer adoption.
`
`Aventail followed this policy and actively promoted the product through
`
`evaluation copies between 1996 and 2000. Countless copies were provided to IBM
`
`and other system integrators to share with customers, partners, and supporting
`
`vendors across the United States and overseas.
`
`14. The Aventail products were distributed with installation discs and
`
`printed manuals for each of the software packages. For example, I received the
`
`Administrator’s Guide for version 2.1 of the Aventail AutoSOCKS client software
`
`this document on approximately December 1997.
`
`15. At the time I received the Administrator’s Guide for version 2.1 of the
`
`Aventail AutoSOCKS client software, 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 AutoSOCKS/VPN Server to IBM clients to whom we deployed
`
`VPN solutions, as well as IBM employees. By the spring of 1998 we were giving
`
`seminars and interviews on the solution and benefits.
`
`16. A second VPN solution Aventail distributed between 1996 and 2000
`
`was called the Aventail Extranet Center (AEC). This product included client
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`Petitioner Apple – Ex. 1006
`
`6
`
`Petitioner RPX Corporation - Ex. 1006, p. 6
`
`
`
`
`
`
`
`software called Aventail Connect and server software called Aventail Extranet
`
`Server.
`
`17.
`
`I recall that Aventail announced 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.
`
`18. 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.
`
`19. Exhibit 1007 is a copy of the Administrator’s Guide for Aventail
`
`Connect v3.01/2.51. I recall receiving Exhibit 1007 with the AEC v3.0 product no
`
`later than July 1998.
`
`20. At the time I received Exhibit 1007, 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 Aventail Connect Administrator’s Guide
`
`along the other printed materials that came with the Aventail Connect/VPN Server
`
`to IBM clients to whom we deployed VPN solutions, and to IBM employees using
`
`the Aventail Connect v3.01/v2.51 client.
`
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`7
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 7
`
`
`
`
`
`
`
`21. 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. By October
`
`1998 this approach was an active commercial offering and program staffed with
`
`dozens of program staff directing hundreds of technical implementation resources.
`
`It became a key element of all strategic decisions and showcasing activities for
`
`internal and external consumption. I shared and showcased this key initiative on a
`
`quarterly basis beginning November 1998.
`
`22. 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.
`
`23.
`
`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.
`
`24. At the time I received the Aventail Connect v3.1/2.6 Administrator’s
`
`Guide, 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
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`Petitioner Apple – Ex. 1006
`
`8
`
`Petitioner RPX Corporation - Ex. 1006, p. 8
`
`
`
`
`
`
`
`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. Numerous articles and go-
`
`to-market strategies showcased the technology and benefit for all size businesses
`
`and institutions. We developed, pursued, and closed numerous deals worldwide
`
`with the Aventail solution. Joint go-to-market and prepared symposium
`
`presentations were given by me and my staff on a routine basis, attended by
`
`thousands, with print and evaluation materials distributed as previously discussed.
`
`Numerous large, medium, and small system integrators across America saw the
`
`competitive advantage of this solution and were actively competing for
`
`commercial and federal business in the 1997-1998 timeframe.
`
`D. Relevant Background on TCP/IP Communications
`25. Two of the claims of the ’135 patent refer to IP hopping schemes or
`
`regimes. I have been asked to provide some background on IP hopping schemes.
`
`26. 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
`
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`9
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 9
`
`
`
`
`
`
`
`(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.
`
`27. 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.
`
`28. 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.
`
`29. 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:
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`10
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 10
`
`
`
`
`
`
`
`1.
`
`2.
`
`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.
`
`3.
`
`It discards the datagram.
`
`30. 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:
`
`1.
`
`2.
`
`3.
`
`A route that matches the destination IP address (host
`route).
`
`A route that matches the network ID of the destination IP
`address (network route).
`
`The default route.
`
`31.
`
`If a matching route is not found, the datagram is discarded.
`
`32. 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).
`
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`11
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 11
`
`
`
`
`
`
`
`33. 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 internetwork 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.
`
`34. 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 it’s 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.
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`12
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 12
`
`
`
`
`
`
`
`35. Any TCP/IP communication will inherently meet the requirement in
`
`the ’135 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.
`
`E. Observations of the Declaration of Dr. Jason Nieh in a Prior
`Reexamination
`
`36.
`
`I reviewed a declaration submitted by Dr. Jason Nieh in
`
`Reexamination Control No. 95/001,269 involving U.S. Patent No. 6,502,135
`
`(Exhibit 1051). 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.
`
`37. Dr. Nieh’s general conclusion is that the Aventail VPN products did
`
`not establish VPNs as they are defined in the claims of the ’135 patent. This is
`
`incorrect. Based on my 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 worldwide.
`
`38.
`
`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
`
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`13
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 13
`
`
`
`
`
`
`
`communicate with each other by encrypting traffic on insecure communication
`
`paths between the computers.” This is precisely what Exhibit 1007 shows client
`
`computers running Aventail Connect doing.
`
`39.
`
`Initially, Dr. Nieh states that he believes the Aventail Connect client
`
`software was simply a SOCKS v5 client. See Ex. 1051, 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.
`
`40. 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.
`
`41. 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.
`
`42. 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,
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`Petitioner Apple – Ex. 1006
`
`14
`
`Petitioner RPX Corporation - Ex. 1006, p. 14
`
`
`
`
`
`
`
`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.
`
`43. 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.
`
`44.
`
`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 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.
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`15
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 15
`
`
`
`
`
`
`
`45. For the Aventail Connect v3.01/2.5 client, this functionality is
`
`described on Page 14 of Exhibit 1007:
`
`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.
`
`46. Exhibit 1007 describes a VPN design made up of client computers
`
`running Aventail Connect v3.01/2.5 connecting to a private network through an
`
`Aventail VPN server. See Exhibit 1007 at pages 76 to 78. I note that Dr. Nieh did
`
`not discuss this section of Exhibit 1007 in his declaration.
`
`47. Page 76-77 of Exhibit 1007 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)
`
`
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`16
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 16
`
`
`
`
`
`
`
`48. Exhibit 1007 on page 77 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.
`
`49. 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.
`
`50. 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.
`
`I found nothing in the claims of the ’135 patent that require that a
`
`51.
`
`computer connected to a private network to communicate directly with other
`
`remote computers that are also connected to the network. Instead, all that is
`
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`17
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 17
`
`
`
`
`
`
`
`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..”
`
`52. Regardless, Exhibit 1007 shows that client computers running
`
`Aventail Connect v3.01/2.5 did have the ability to communicate with other
`
`computers on the network, including other remote users.
`
`53. For example, the figure on page 76 of Exhibit 1007 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 76-77 of Exhibit 1007:
`
`Depending on the security policy and the Aventail ExtraNet
`Server configuration, Aventail Connect will automatically
`proxy their [the client computer’s] 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.
`
`54. 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
`
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`18
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 18
`
`
`
`
`
`
`
`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.
`
`55. Exhibit 1007 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 1007 explains on page 94:
`
`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.
`
`56. 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.
`
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`19
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 19
`
`
`
`
`
`
`
`57. The second reason Dr. Nieh offers to support his belief that the
`
`Aventail VPN products did not establish VPNs was that “Aventail Connect’s
`
`fundamental operation is incompatible with users attempting to transmit data that is
`
`sensitive to network information.” See Ex. 1051 at paragraphs 23-25.
`
`58. 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 discloses that 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.
`
`59. Dr. Nieh has apparently misunderstood how client computers running
`
`Aventail Connect actually function.
`
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`20
`
`Petitioner Apple – Ex. 1006
`
`Petitioner RPX Corporation - Ex. 1006, p. 20
`
`
`
`
`
`
`
`60. As explained on pages 14 to 16 of Exhibit 1007, Aventail Connect
`
`would monitor DNS requests made by applications on the client computer. If the
`
`DNS request contained a 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
`
`1007 at page 15-16 (“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.
`
`61.
`
`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 list1, 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
`
`
`1 As explained in step 2(a) on page 12 of Exhibit 1007, if the DNS request did not include a
`host name, but was a real IP address (e.g., 1