`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.