`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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
`
`
`
`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
`
`
`
`/Ij‘(N/§
`Date
`
`Declaration Of James Chester
`
`Regarding US. Patent No. 7,490,151
`
`2
`
`Petitioner Apple — Ex. 1006
`
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`(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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`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.2.3.4), then no DNS resolution step is needed.
`Declaration Of James Chester
`Regarding U.S. Patent No. 6,502,135
`
`
`Petitioner Apple – Ex. 1006
`
`21
`
`
`
`
`
`
`
`
`
`that was successful, the VPN would be established between the client computer
`
`and the destination computer specified in the original connection request. See
`
`Exhibit 1007, pages 16 (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.
`
`62. As Exhibit 1007 explains on pages 15-16, 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
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
