throbber
Filed on behalf of: VirnetX Inc.
`By:
`
`Joseph E. Palys
`Paul Hastings LLP
`875 15th Street NW
`Washington, DC 20005
`Telephone: (202) 551-1996
`Facsimile: (202) 551-0496
`E-mail: josephpalys@paulhastings.com
`
`
`
`Naveen Modi
`Paul Hastings LLP
`875 15th Street NW
`Washington, DC 20005
`Telephone: (202) 551-1990
`Facsimile: (202) 551-0490
`E-mail: naveenmodi@paulhastings.com
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`
`
`
`
`
`
`APPLE INC.,
`Petitioner
`
`v.
`
`VIRNETX INC.
`Patent Owner
`
`
`
`
`
`
`
`Case IPR2015-00866
`Patent No. 8,458,341
`
`
`
`
`
`
`
`
`
`
`
`
`PATENT OWNER’S DEMONSTRATIVE EXHIBITS
`
`
`
`

`
`Inter Partes Review of
`
`U.S. Patent N0. 8,458,341
`
`U.S. Patent No. 8,516,131
`
`U.S. Patent No. 8,560,705
`
`Case Nos. IPR2015-00866, -00868,
`
`-00870, and -00871
`
`Oral Hearing: June 27, 2016
`
`

`
`Instituted Grounds
`
`IPR2015—00866 (U.S. Patent No. 8,458,341)
`— Claims 1-11, 14-25, and 28 as obvious over Beser and RFC 2401
`
`IPR2015-00868 (U.S. Patent No. 8,516,131)
`
`— Claims 1-10, 13-22, and 25-27 as obvious over Beser and RFC
`2401
`
`IPR2015-00870 (U.S. Patent No. 8,560,705)
`
`— Claims 1-23 and 25-30 as obvious over Beser and RFC 2401
`
`— Claim 24 as obvious over Beser, RFC 2401, and Brand
`
`IPR2015—00871 (U.S. Patent No. 8,560,705)
`
`— Claims 1-23 and 25-30 as obvious over Aventail, RFC 2401, and
`RFC 2543
`
`— Claim 24 as obvious over Aventail, RFC 2401, RFC 2543, and
`Brand
`
`IPR2015-00810, Inst. Dec. at 23; IPR2015—O08l1, Inst. Dec. at 24; IPR2015-00812, Inst. Dec. at 14
`
`

`
`IPR2015-00866 (U.S. Patent No. 8,458,341)
`
`IPR2015-00868 (U.S. Patent No. 8,516,131)
`
`IPR2015-00870 (U.S. Patent No. 8,560,705)
`
`

`
`Claim 1 of the ’341 Patent
`
`1. A network device, comprising: a storage device storing an application program for a
`
`secure communications service; and at least one processor configured to execute the
`application program for the secure communications service so as to enable the network
`
`device to:
`
`send a request to look up an internet protocol (IP) address of a second network device
`based on a domain name associated with the second network device;
`
`receive, following interception of the request and a determination that the second network
`
`device is available for the secure communication service, an indication that the second
`
`network device is available for the secure communications service, the requested IP
`
`address of the second network device, and provisioning information for a virtual private
`network communication link;
`
`connect to the second network device, using the received IP address of the second
`
`network device and the provisioning information for the virtual private network
`communication link; and
`
`communicate with the second network device using the secure communications service via
`
`the virtual private network communication link.
`
`Ex. 1001, claim 1
`
`

`
`Claim 1 of the ’131 Patent
`
`1. A network device, comprising: a storage device storing an application program for a
`
`secure communications service; and at least one processor configured to execute the
`application program for the secure communications service so as to enable the network
`
`device to:
`
`send a request to look up an internet protocol (IP) address of a second network device
`based on a domain name associated with the second network device;
`
`receive, following interception of the request and a determination that the second network
`
`device is available for the secure communications service, an indication that the second
`
`network device is available for the secure communications service, the requested IP
`
`address of the second network device, and provisioning information for a secure
`communication link;
`
`connect to the second network device over the secure communication link, using the
`
`received IP address of the second network device and the provisioning information for the
`secure communication link; and
`
`communicate at least one of video data and audio data with the second network device
`
`using the secure communications service via the secure communication link.
`
`Ex. 1003, claim 1
`
`

`
`Claim 1 of the ’0,705 Patent
`
`1. A client device comprising: (a) memory configured and arranged to facilitate a
`
`connection of the client device with a target device over a secure communication link
`created based on (i) interception of a request, generated by the client device, to look up an
`
`internet protocol (IP) address of the target device based on a domain name associated with
`the target device, and (ii) a determination as a result of the request that the target device is
`a device with which a secure communication link can be established;
`
`(b) an application program configured and arranged so as to allow participation in
`audio/video communications with the target device over the secure communication link
`once the secure communication link is established; and
`
`(c) a signal processing configuration arranged to execute the application program.
`
`Ex. 1050, claim 1
`
`

`
`PRIVATE
`
`NETWORK
`
`PUBLIC
`
`NETWORK
`
`1007 at Fig. 1; ’866 P.O. Resp. at 23; ’868 P.O. Resp. at 28; ’870 P.O. Resp. at 28
`
`

`
`PRIVATE
`NETWORK
`
`PUBLIC
`NETWORK
`
`TRUSTED-
`THIRD-PARTY
`NETWORK
`DEVICE
`
`TERMINATING
`TELEPHONY
`DEVICE
`25
`
`'
`
`'
`
`-
`
`SECOND
`NETWORK
`DEVICE
`1_6
`
`ASSOCIATE
`
`Ex. 1007 at Figs. 1, 6; ’866 P.O. Resp. at 23-24; ’868 P.0. Resp. at 28-29; ’870 P.O. Resp. at 28-29
`
`

`
`Beser’s Tunneling Method
`
`ORIGINATING
`TELEPHONY
`
`DEVICE
`2_4
`
`'
`
`-
`
`'
`
`‘
`
`,
`
`-
`
`.
`
`-
`
`TERMINATING
`TELEPHONY
`
`DEVICE
`26
`
`SECOND
`NETWORK
`DEVICE
`
`PUBLIC
`NETWORK
`
`Ex. 1007 at Figs. 1, 6; ’866 P.O. Resp. at 23-24; ’868 P.O. Resp. at 28-29; ’870 P.O. Resp. at 28-29
`
`

`
`Beser’s Tunneling Method
`
`At Step 114, a trusted-third-party network device 30 is
`informed of the request on the public network 12. The
`informing step may include one or multiple transfer of IP 58
`packets across the public network 12. The public network 12
`may include the Internet. For each transfer of a packet from
`the first network device 14 to the trusted-third-party network
`device 30, the Iirst network device 14 constructs an IP 58
`packet. The header 82 of the [P 58 packet includes the public
`network 12 address of the trusted-third-party network device
`30 in the destination address field 90 and the public network
`[2 address of the first network device 14 in the source
`
`address field 88. At least one of the IP 58 packets includes
`the unique identifier for the tertninating telephony device 26
`that had been included in the request message. The IP 58
`packets may require encryption or authentication to ensure
`that
`the unique identifier cannot be read on the public
`network 12.
`
`Ex. 1007 at 11:9-25; ’866 P.O. Resp. at 24; ’868 P.0. Resp. at 29; ’870 P.O. Resp. at 29-30
`
`

`
`Beser’s Tunneling Method
`
`ORIGINATING
`TELEPHONY
`
`DEVICE
`2_4
`
`'
`
`-
`
`'
`
`‘
`
`,
`
`-
`
`.
`
`-
`
`TERMINATING
`TELEPHONY
`
`DEVICE
`E
`
`_
`
`SECOND
`NETWORK
`DEVICE
`1_5
`
`PRIVATE
`NETWORK
`
`PUBLIC
`NETWORK
`
`1007 at Figs. 1, 6; ’866 P.O. Resp. at 23-24; ’870 P.O. Resp. at 28-29; ’870 P.O. Resp. at 28-29
`
`

`
`Beser’s Tunneling Method
`
`A public [P 58 address for a second network device 16 is
`associated with the unique identifier for the terminating
`telephony device 26 at Step 116. The second network device
`16 is associated with the terminating telephony device 26.
`This association of the public IP 58 address for the second .
`network device 16 with the unique identifier is made on the
`trusted-third-party network device 30. In one exemplary
`
`Ex. 1007 at 11:26-32; ’866 P.O. Resp. at 25; ’868 P.O. Resp. at 29; ’870 P.O. Resp. at 30
`
`

`
`Beser’s Tunneling Method
`
`PRIVATE
`NETWORK
`
`PUBLIC
`NETWORK
`
`ORIGINATING
`TELEPHONY
`DEVICE
`2_4
`
`TRUSTED-
`THIRD-PARTY
`NETWORK
`DEVICE
`
`TERMINATING
`TELEPHONY
`DEVICE
`26
`
`SECOND
`NETWORK
`DEVICE
`J2
`
`1.___n\
`NEGOTIATE ‘
`
`Ex. 1007 at Figs. 1, 6; ’866 P.O. Resp. at 23-24; ’868 P.O. Resp. at 28-29; ’870 P.O. Resp. at 28-29
`
`

`
`Beser’s Tunneling Method
`
`At Step I13, a first private IP 58 address on the First
`network device [4 and it seeotttl private IP 58 address on the on
`second network device are negotiated through the public
`network 12. Private IP 58 addresses are addresses that are
`
`reserved for use in private networks that are isolated from a
`public netwttrk such as the Internet. Private IP 58 atldresses
`
`58 addresses are assigned to the telephony devices (24, 26),
`viz.,
`the first private IP 58 address is assigned to the
`originating, telephony device 24 and the second private IP 58
`address is assigned to the temiinating telephony device .26.
`The assignment of private IP 58 addresses is discussed
`below. The negotiation ensures that neither the private nor
`any public It’ 58 addresses for the ends of the VuIP asso-
`eiation appear in the source 88 or destination 90 address
`fields of the IP 58 aekets that com a rise the negotiation. The
`
`Ex. 1007 at 11:59-64, 12:2—4; ’866 P.O. Resp. at 25; ’868 P.O. Resp. at 29; ’870 P.O. Resp. at 30
`
`

`
`TRUSTED-
`THIRD-PARTY
`NETWORK
`DEVICE
`
`__
`
`SECOND
`NETWORK
`DEVICE
`L5.
`
`PRIVATE
`NETWORK
`
`PUBLIC
`NETWORK
`
`1007 at Figs. 1, 6; ’866 P.O. Resp. at 23-24; ’868 P.O. Resp. at 28-29; ’870 P.O. Resp. at 28-29
`
`

`
`Beser’s Tunneling Method
`
`Of course, the sender may encrypt the information inside
`the II’ pzteketa hefore tt'au:~n1is:~ion, e.g_. with ll’ Security
`(“lPSec"). However, aecu mulating, all the packets from one
`source address may provide the hacker with suliicient infor-
`mation to decrypt the niessage. Moreover. encryption at the
`source and decryption at the destination may he infeasible
`for certain data format.~i. For example, .~t.treaining data llows,
`such as multimedia or Voice.-over—lnternet-Protocol
`
`(“VoIP"), may require a great deal of computing power to
`encrypt or decrypt the IP packets on the fly. The increased
`strain on computer power may result in jitter, delay, or the
`loss of some packets. The expense of added computer power at?
`might also dampen the customer's desire to invest in VolP
`equipment.
`
`packet that is transmitted on the public network. The tun-
`neled IP packets, however, may need to be encrypted before.
`the encapsulation in order to hide the Source IP address.
`Once again, due to computer power limitations, this liorm of
`tunneling may be inappropriate for
`the transmission of
`multimedia or VolP packets.
`
`1007 at 1:54-67, 2:12-17; ’866 P.O. Resp. at 22; ’868 P.O. Resp. at 26-27; ’870 P.O. Resp. at 27
`
`

`
`Beser’s Tunneling Method
`
`It is therefore desirable to establish a tunneling associa-
`tion that hides the identity of the originating and terminating
`ends of the tunneling association from the other users of a
`public network. Hiding the identities may prevent a hacker
`40 from intercepting all media flow between the ends.
`
`phony device and a terminating telephony device. The
`method and system described herein may help ensure that
`the addresses of the ends of the tunneling association are
`hidden on the public network and may increase the security
`of communication without an increased computational bur-
`den.
`
`5
`
`Ex. 1007 at 2:36-40, 3:4-9; ’866 P.O. Resp. at 23; ’868 P.O. Resp. at 27; ’870 P.O. Resp. at 28
`
`

`
`Claims 4-5 and 18-19 of the ’341 Patent
`
`4. The network device of claim 1, wherein the secure
`
`communications service includes a messaging service.
`
`5. The network device of claim 4, wherein the messaging
`service includes an e-mail service.
`
`18. The method of claim 15, wherein the secure
`
`communications service includes a messaging service.
`
`19. The method of claim 18, wherein the messaging service
`includes an e-mail service.
`
`Ex. 1001, claims 4-5, 18-19
`
`

`
`Claims 4-5 and 18-19 of the ’341 Patent
`
`App|e’s Petition:
`
`Transinitting email over a secure communication link or VPN was well-
`
`known at the time of the invention. See, e. g.. U.S. Patent No. 6.609.148 to Salo et
`
`al. (Ex. 1052) at Fig. SA-B (showing a messaging seiver being accessed via VPN
`
`and IPsec). 12:11-23 (describing messaging seivers providing email applications):
`
`Ex. 1009 at 72: Ex. 1005 at T} 350.
`
`A person of ordinaiy skill in the an would have
`
`found it obvious to send email through Bese1"s IP tunnel because it aheady
`
`transmits other types of communication data such as audio and video. and
`
`extending it to e-mail would have been an obvious design choice. Ex. 1005 at
`
`'1 350.
`
`’866 Pet. at 51; ’866 P.O. Resp. at 40-42
`
`

`
`13. The client device of claim 3, wherein the target device is
`
`a server.
`
`28. The method of claim 16, wherein the target device is a
`
`server.
`
`App|e’s Petition:
`
`A person of ordinaiy skill in the art would understand that a
`
`Web-TV device or a multimedia application-be used by connecting to and
`
`downloading content from a se1\'er. Ex. 1005 at ft 327.
`
`Ex. 1050, claims 13 and 28; ’87O Pet. at 54
`
`

`
`App|e’s expert:
`
`That person also would have lmderstood “multimedia
`
`applications" to include web browsers. audio and video players. photo browsers.
`
`and audio- and video—conferencing software. Web-TV devices and multimedia
`
`applications-be used to connect to and downloading from a sewer.
`
`Ex. 1005 at 1] 327; ’870 P.O. Resp. at 44-45
`
`

`
`App|e’s Petition:
`
`Indeed. Beser explains that
`
`the unique identifier associated with a teiminating end device can be a—
`
`-(Ex. 1007 at 10:39-41. 10:55-11:5). which would suggest to a person of
`
`ordinaiy skill in the an that the teuninating end device could be a sewer. See
`
`Ex. 1005 at ‘W 160-66.
`
`’870 Pet. at 54
`
`

`
`Claims 13 and 28 of the ’0,705 Patent
`
`App|e’s expert:
`
`164. The Domain Name System (DNS) translates hostnames (e. g..
`
`wvmnapple.co1n) into IP address (e.g.. 17.172.224.47) necessary to route
`
`communications to a destination. DNS is a distributed database that allows for
`
`address resolution Via a client-sei'\'er model. The servers in this model are
`
`programs called “name sei*vers" that make information from the database available
`
`to client programs called “resol\'ers.“ which are responsible for creating queries
`
`and submitting them to a name sewer‘.
`
`Ex. 1005 at $1 164; ’870 P.O. Resp. at 46
`
`

`
`IPR2015-00871
`
`U.S. Patent No. 8,560,705
`
`24
`
`

`
`Claim 1 of the ’0,705 Patent
`
`1. A client device comprising: (a) memory configured and arranged to
`facilitate a connection of the client device with a target device over a
`secure communication link created based on (i) interception of a request,
`generated by the client device, to look up an internet protocol (IP)
`address of the target device based on a domain name associated with
`the target device, and (ii) a determination as a result of the request that
`the target device is a device with which a secure communication link can
`be established;
`
`(b) an application program configured and arranged so as to allow
`participation in audio/video communications with the target device over
`the secure communication link once the secure communication link is
`
`established; and
`
`(c) a signal processing configuration arranged to execute the application
`
`program.
`
`Ex. 1050, claim 1
`
`

`
`Basic Configuration for Aventail
`
`1. The application does a DNS lookup to convert the hostname to an lP address.
`
`If the application already knows the IP address, this entire step is skipped.
`
`Otherwise, Aventail Connect does the followind:
`
`-
`
`lfthe hostname matches a local domain string or does not match a redi-
`
`rection rule, Aventail Connect passes the name resolution query
`through to the TCPIIF’ stack on the local workstation. The TCPIIP stack
`
`performs the tooltup as if Aventail Connect were not running.
`
`lfthe destination hostname matches a redirection rule domain name
`
`(ie, the host is part of a domain we are proxying traffic to) then Aventail
`
`Connect creates a false DNS entry CHOSTENT) that it can recognize
`
`during the connection request. Aventatl Connect will forward the host-
`
`name to the extranet (SOCKS) server in step 2 and the SOCKS sen/er
`performs the hostname resolution.
`
`If the DNS proxy option is enabled and the domain cannot be looked up
`
`directly. Aventail Connect creates a fake DNS entry that it can recog-
`nize later, and returns this to the calling application. The tatse entry tells
`
`Aventail Connect that the DNS lookup must be proxied, and that it must
`
`send the fully qualified hostname to the SOCKS server with the SOCKS
`connection request.
`
`IPR20l5—00871, Ex. 1009 at 11-12; P.O. Resp. at 27-29
`
`

`
`Basic Configuration for Aventail
`
`2. The application reguests a connection to the remote host. This causes the
`undeitying stack to begin the TCP handshake. when the handshake is com-
`plete, the application is notified that the connection is established and that
`data may now be transmitted and received. Aventail Connect does the follow-
`mg.
`
`a. Aventail Connect checks the connection reguest.
`-
`if the request contains a false DNS entry (from step 1), it will be
`proxied.
`
`lf the request contains a routable IP address, and the rules in the
`configuration file say it must be proxied, Aventail Connect will call
`WinSOC|l to begin the TCP handshake with the server designated
`in the configuration file.
`
`if the request contains a real IP address and the configuration file
`rule says that it does not need to be proxied, the request will be
`passed to Winsock and processing jumps to step 3 as if Aventail
`Connect were not running.
`
`b. when the connection is completed, Aventail Connect begins the
`SOCKS negotiation.
`
`-
`
`it sends the list of authentication methods enabled in the configu-
`ration file.
`
`Once the server selects an authentication method, Aventail Con-
`nect executes the specified authentication processing.
`
`it then sends the proxy request to the extranet (SOCKS) server.
`This includes either the IP address provided by the application or
`the DNS entry (hostname) provided in step 1.
`
`When the SOCKS negotiation is completed, Aventail Connect notifies
`the application. From the application's point of view, the entire SOCKS
`negotiation, including the authentication negotiation. is merely the TCP
`handshaking.
`
`IPR2015—00871, Ex. 1009 at 11-12; P.O. Resp. at 27-29
`
`

`
`3 The application transmits and receives data-
`
`It an encryption module is enabled and selected by the SOCKS server, Aven-
`
`tail Connect encrypts the data on its way to the server on behalf of the appli-
`cation. If data is being returned, Aventail Connect decrypts it so that the
`
`application sees cleartext data.
`
`IPR2015—00871, Ex. 1009 at 11-12; P.O. Resp. at 27-29
`
`

`
`Claim 1 of the ’0,705 Patent
`
`1. A client device comprising: (a) memory configured and arranged to
`
`(i) interception of a
`request, generated by the client device, to look up an internet protocol
`(IP) address of the target device based on a domain name associated
`with the target device, and (ii)
`
`(b) an application program configured and arranged so as to allow
`participation in audio/video communications with the target device over
`the secure communication link once the secure communication link is
`
`established; and
`
`(c) a signal processing configuration arranged to execute the application
`
`program.
`
`Ex. 1050, claim 1
`
`

`
`Apple's Petition:
`
`the remote host in the redirection rule table therefore enables Aventail C ormect to
`
`detemiine if the remote host will require an encrypted connection (“is a device with
`
`which a secure connnunicarion link can be e.s'rablishea”’).
`
`Inclusion of
`
`IPR20l5—00871, Pet. at 39-40
`
`

`
`Aventai|’s redirection rule:
`
`PW
`
`Redrrecbon
`
`Ruhr.-d ma
`
`Rt.-dmcl. all traffic through the cxtrmet server2
`
`Donotledirecl
`
`Roulenaflicchecflytamespedfieddesfinafion
`without being redirecned mrougn SOCKS.
`
`Denyse-Moe
`
`Denyaccm-ssIomespeal1edoesuna0on.The
`netwurlc cannecuon Is blocked Iocdly Instead of
`atthesewetlevel
`
`IPR20l5—00871, Ex. 1009 at 40; P.O. Resp. at 31-33
`
`

`
`Apple's Petition:
`
`A person of ordinary skill would thus have understood this
`
`SOCKS-negotiation disclosure in Aventail to be explaining the Extranet server
`
`would determine whether the client device is allowed (or denied) access to the
`
`target device to which the client device has requested a connection (also “a
`
`determination"). Ex. 1009 at 5. 12: Ex. 1005 1} 281.
`
`IPR20l5—00871, Pet. at 40
`
`

`
`Claims 4 and 20 of the ’O,705 Patent
`
`4. The client device of claim 3, wherein the establishment of
`
`the secure communication link is based on
`
`that the target device is a device
`with which a secure communication link can be established.
`
`20. The method of claim 16, wherein the establishment of
`
`the secure communication link is based on
`
`that the target device is a device
`with which a secure communication link can be established.
`
`Ex. 1050, claims 4 and 20
`
`

`
`Apple's Petition:
`
`As described above with respect to the detemlination element of the
`
`independent claims, see § IV.B- ID, Aventail discloses that an Extranet server
`
`(“server”) can determine whether a remote host (“target device”) is one with which
`
`a client device may establish a connection. Aventail in View of RFC 2401 and
`
`RPC 2543 would have therefore rendered obvious claims 4 and 20.
`
`IPR20l5—00871, Pet. at 50
`
`

`
`7. The client device of claim 3, wherein the domain name is
`
`a secure domain name.
`
`22. The method of claim 16, wherein the domain name is a
`
`secure domain name.
`
`Ex. 1050, claims 7 and 22
`
`

`
`App|e’s Petition:
`
`i is
`
`a printed publication that was distributed to the public without restriction no later
`
`than January 31, 1999. Enclosed with this request are declarations under 37 CFR§
`
`1-32 from three individuals having personal knowledge that Aventail was publicly
`
`distributed no later than January 31- 1999. The declarations were previously filed
`
`in inter parres reexamination 9S.H'00l682.
`
`IPR2015—00871, Pet. at 18; P.O. Resp. at 47-52
`
`

`
`Hopen Declaration
`
`- The version of Aventail Extranet Center relevant here is
`
`AEC V3.0, which allegedly included Aventail Connect
`V3.01/2.51.
`It was allegedly announced in Fall of 1998.
`
`13.
`
`The initial release version of the AEC product was version 3.0. The AEC v3.() product
`
`included version 3.01/2.51 of Aventail Connect and version 3.0 of the Aventail Extranet
`
`Server.
`
`The AEC V3.0 product with its client and server components was publicly distributed
`
`during no later than January of 1999.
`
`Exhibit E is a copy of the Aventail Connect V3.01/2.51 Administrator’s Guide that was
`
`distributed with the Aventail Connect V3.01/2.51 sofiwarc. Exhibit F is a copy of the
`
`Aventail Extranet Server V3.0 Administrator’s Guide that was distributed with the
`
`Aventail Extranet Server sofiware. Both of these documents were distributed without
`
`any confidentiality restrictions.
`
`10.
`
`In the fall of I998, Aventail armounced a product called the Aventail Extranet Center
`
`(“AEC"). §i_(hi_l)_it_D is a copy ofan October 12, 1998 Aventail press release announcing
`
`the Aventail Extranet Center product.
`
`IPR2015—00871, Ex. 1023 at 2; P.O. Resp. at 48-50
`
`

`
`The AEC v3.0 product with its client and server components was publicly distributed
`
`during no later than Januaryof 1999.
`
`I estimate that Aventail distributed thousands of copies of the AEC v3 .0 product
`
`(including the Administrator Guides for Aventail Connect and Extranet Center) during
`the first six months of 1999.
`
`IPR20l5-00871, Ex. 1023 at 2-3; P.O. Resp. at 50
`
`

`
`App|e’s Petition:
`
`In Exhibit 1022. James Chester. foimerly
`
`of IBM. testifies that he received Aventail no later than the end of December of
`
`1998. and subsequently distiibuted this document to customers and IBM
`
`employees in connection with deployment of VPN solutions to these entities and
`
`individuals i11 mid-Januaiy of 1999.
`
`IPR2015—00871, Pet. at 18
`
`

`
`Chester Declaration
`
`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.
`
`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.
`
`The ABC v3.0 product included version 3.0] /2.51 of the Aventail Connect software, and
`version 3.0 of the Aventail Extranet Server.
`
`Exhibitg is a copy of the Administrator’s Guide for Aventail Connect V3.01/2.51.
`recall receiving ExhibitQ with the AEC v3.0 product no later than July 1998.
`
`I
`
`It received very good
`The ABC product was a very versatile and stable VPN solution.
`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.
`
`IPR2015-00871, Ex. 1022 at 3; P.0. Resp. at 50
`
`

`
`
`
`Case No. IPR2015-00866
`
`CERTIFICATE OF SERVICE
`
`I hereby certify that on this 23rd day of June 2016, a copy of the foregoing
`
`Patent Owner’s Demonstrative Exhibits was served by electronic mail upon the
`
`following:
`
`
`
`Counsel for Apple Inc.:
`
`
`
`
`iprnotices@sidley.com
`Sidley Austin LLP
`1501 K Street NW
`Washington, DC 20005
`
`Dated: June 23, 2016
`
`Respectfully submitted,
`
` /Joseph E. Palys/
`Joseph E. Palys
`Registration No. 46,508
`
`
`
`Counsel for VirnetX Inc.

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket