`Tel: 571-272-7822
`
`
`Paper 9
`Entered: July 1, 2016
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`
`
`
`
`
`Before MICHAEL P. TIERNEY, KARL D. EASTHOM, and
`STEPHEN C. SIU, Administrative Patent Judges.
`
`EASTHOM, Administrative Patent Judge.
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`I. INTRODUCTION
`A. Background
`Petitioner, Apple Inc., filed a Petition (Paper 1, “Pet.”) requesting an
`inter partes review of claims 1–11, 14–25, 28, and 30 (the “challenged
`claims”) of U.S. Patent No. 8,504,696 B2 (Ex. 1001, “the ’696 patent”). See
`Pet. 6. Patent Owner, VirnetX Inc., filed a Preliminary Response. Paper 6
`(“Prelim. Resp.”).1
`We have authority to determine whether to institute an inter partes
`review. 35 U.S.C. § 314(b); 37 C.F.R. § 42.4(a). The standard for
`instituting an inter partes review is set forth in 35 U.S.C. § 314(a), which
`provides that an inter partes review may not be instituted “unless the
`Director determines . . . there is a reasonable likelihood that the petitioner
`would prevail with respect to at least 1 of the claims challenged in the
`petition.”
`After considering the Petition and Preliminary Response, we
`determine that Petitioner has established a reasonable likelihood of
`prevailing in showing the unpatentability of at least one of the challenged
`claims. Accordingly, we institute inter partes review.
`B. Related Matters
`Petitioner indicates that the ’696 patent “has not been asserted in
`litigation or the subject of other IPR proceedings.” Pet. 2. Petitioner
`concurrently filed a petition challenging the same claims and claim 29 in the
`
`
`1 Patent Owner persuasively points out that because Petitioner merely lists
`claim 29 as being challenged without providing an analysis for claim 29,
`“claim 29 is not subject to review in this proceeding.” Prelim. Resp. 5 n.1
`(citing Pet. 6).
`
`2
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`’696 patent in IPR2016-00331. See id. at 5. Petition and Patent Owner
`provide listings of district court actions, other inter partes review, and inter
`partes reexamination proceedings challenging related patents. See id. at 3–
`5; Paper 5, 3–15; see also VirnetX, Inc. v. Cisco Systems, Inc., 767 F.3d
`1308, 1317–19 (Fed. Cir. 2014) (addressing ancestor VirnetX patents having
`related terms).2
`
`C. References
`Petitioner relies on the following references.
`Reference
`Description
`Publication or
`Issue Date
`1996–1999
`
`Aventail Aventail (see n.3)
`
`RFC 2401 S. Kent & R. Atkinson, RFC
`2401, Security Architecture for
`the Internet Protocol, Network
`Working Group, Request for
`Comments
`
`Nov. 1998
`
`Exhibit
`No.
`Ex. 1009–
`10113
`Ex. 1008
`
`
`2 The ’696 patent is a continuation of an application, which is a continuation
`of U.S. Patent No. 7,921,211, which is a continuation of U.S. Patent No.
`7,418,504 (“’504 patent”), which is a continuation-in-part of U.S. Patent No.
`6,502,135––three of the four patents at issue in VirnetX. See VirnetX, 767
`F.3d at 1313. (The fourth patent at issue in VirnetX, is U.S. Patent No.
`7,490,151 (“’151 patent”), a division of the ’135 patent.)
`3 Exhibits 1009–1011 relate to an Aventail Connect software application and
`are collectively referred to as “Aventail” unless otherwise noted. See
`Aventail Connect v3.01/v2.51 Administrator’s Guide (“Aventail
`Administrator Guide,” Ex. 1009), Aventail Connect v3.01/v2.51 User’s
`Guide (1996–1999) (“Aventail User Guide,” Exhibit 1010), and Aventail
`ExtraNet Center v3.0 Administrator’s Guide (NT and UNIX) (“Aventail
`ExtraNet,” Exhibit 1011).
`
`3
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`Reference
`
`Description
`
`Publication or
`Issue Date
`Mar. 1999
`
`Exhibit
`No.
`Ex. 1013
`
`Yeager
`
`1996
`
`Ex. 1066
`
`RFC 2543 Handley et al., SIP: Session
`Initiation Protocol, Network
`Working Group, Request for
`Comments
`N. YEAGER & R.E. MCGRAW,
`WEB SERVER TECHNOLOGY,
`THE ADVANCED GUIDE FOR
`WORLD WIDE WEB
`INFORMATION PROVIDERS
`(Michael B. Morgan et al. eds.,
`1996)
`Pet. 6, Attachment B.
`Petitioner also relies on the Declaration of Roberto Tamassia (Ex.
`1005), the Declaration of the RFC Publisher for the Internet Engineering
`Task Force, an Organized Activity of the Internet Society, signed by Sandy
`Ginoza (“Ginoza Declaration” (Ex. 1060)), the Declaration of Christopher
`Hopen (“Hopen Declaration” (Ex. 1023)), the Declaration of Michael Fratto
`(“Fratto Declaration” (Ex. 1043)), and the Declaration of James Chester
`(“Chester Declaration” (Ex. 1022)). The latter three declarations were
`submitted in a related inter partes reexamination proceeding. See Pet. 18–19
`(listing reexamination 95/001,682).
`D. Asserted Grounds of Unpatentability
`Petitioner challenges claims of the ’696 patent as unpatentable on the
`following 35 U.S.C. § 103(a) grounds.
`References
`Aventail, RFC 2401
`
`Claims Challenged
`1, 4, 5, 9–11, 14–16, 19, 20, 24,
`25, 28, and 30
`Aventail, RFC 2401, and RFC 2543 2, 3, 6–8, 17, 18, and 21–23
`Aventail, RFC 2401, and Yeager
`15 and 30
`
`4
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`Pet. 6.
`
`E. The ’696 Patent
`The ’696 patent describes secure methods for communicating over the
`Internet. Ex. 1001, Abstract, 10:3–8. Specifically, the ’696 patent describes
`“the automatic creation of a virtual private network (VPN) in response to a
`domain-name server look-up function.” Id. at 39:23–25. This automatic
`creation employs a modified Domain Name Server, which may include a
`conventional Domain Name Server (DNS) and a DNS proxy (id. at 40:20–
`40:22):
`
`Conventional Domain Name Servers (DNSs) provide a
`look-up function that returns the IP address of a requested
`computer or host. For example, when a computer user types in
`the web name “Yahoo.com,” the user’s web browser transmits a
`request to a DNS, which converts the name into a four-part IP
`address that is returned to the user’s browser and then used by
`the browser to contact the destination web site.
`
`Id. at 39:26–32.
`The DNS proxy of the modified DNS server intercepts DNS
`lookup requests, determines whether the user has requested access to a
`secure site (using for example, a domain name extension or an internal
`table of secure sites), and if so, whether the user has sufficient security
`privileges to access the requested site. Id. at 40:26–35. If the user has
`requested access to a secure site to which it has insufficient security
`privileges, the DNS proxy returns a “‘host unknown’” error to the
`user. Id. at 40:49–53. If the user has requested access to a secure site
`to which it has sufficient security privileges, the DNS proxy requests a
`gatekeeper to create a VPN between the user’s computer and the
`secure target site. Id. at 40:31–42. The DNS proxy then returns to the
`
`5
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`user the resolved address passed to it by the gatekeeper, which need
`not be the actual address of the destination computer. Id. at 40:43–44.
`The VPN is “preferably implemented using the IP address
`‘hopping’ features,” (changing IP addresses based upon an agreed
`upon algorithm) described elsewhere in the ’696 patent, “such that the
`true identity of the two nodes cannot be determined even if packets
`during the communication are intercepted.” Id. at 40:4–8.
`F. Illustrative Challenged Claim 1
`Independent claims 1 and 16 recite the same limitations respectively
`in system and method format. Compare Ex. 1001, 56:8–23, with id. at 57:1–
`14. All other challenged claims depend from claims 1 or 16. Claim 1,
`illustrative of the challenged claims, follows:
`
`1. A system for connecting a first network device and a
`
`second network device, the system including one or more
`servers configured to:
`
`intercept, from the first network device, a request to look
`up an internet protocol (IP) address of the second network
`device based on a domain name associated with the second
`network device;
`
`determine, in response to the request, whether the second
`network device is available for a secure communications
`service; and
`
`initiate a virtual private network communication link
`between the first network device and the second network device
`based on a determination that the second network device is
`available for the secure communications service, wherein the
`secure communications service uses the virtual private network
`communication link.
`
`6
`
`Ex. 1001, 56:7–23.
`
`
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`G. Alleged Redundancy with IPR2016-00331
`
`Patent Owner argues that the present case is redundant with the
`petition filed in IPR2016-00331 (“’331 IPR”), and the Board should deny
`institution on that basis. Prelim. Resp. 34–38. Patent Owner contends that
`“[r]edundant grounds place a significant burden on the Board and the patent
`owner, and cause unnecessary delay that jeopardizes meeting the statutory
`deadline for final written decisions.” Id. at 35 (citation omitted). Patent
`Owner explains that one of the grounds in the ’331 IPR “simply substitutes
`Aventail with Beser.” Id. at 35.
`Although the grounds asserted here are similar to those asserted in the
`’331 IPR, they are not the same. Furthermore, Beser and Aventail have been
`involved in several recent proceedings between the two parties. See, e.g.,
`Apple Inc. v. VirnetX Inc., IPR2014-00237 (PTAB May 11, 2015) (Paper 41)
`(final written decision “’237 FWD”, or generally, “’237 IPR”); Apple Inc. v.
`VirnetX Inc., Case IPR2015-00811 (PTAB Sept. 11, 2015) (Paper 8); Apple
`Inc. v. VirnetX Inc., Case IPR2015-00812 (PTAB Sept. 11, 2015) (Paper 8);
`Apple Inc. v. VirnetX Inc., IPR2015-00870 (PTAB Oct. 1, 2015) (Paper No.
`8); Apple Inc. v. VirnetX Inc., IPR2015-00871 (PTAB Oct. 1, 2015) (Paper
`No. 8). Aventail also has been involved in litigation between the parties and
`prosecution at the Office. See IPR2015-00871, 8, 19 n.6 (Paper 8) (citing
`Reexamination Control. No. 95/002,269 and discussing a similar redundancy
`issue).
`Under the specific circumstances involved at this juncture, the Beser-
`based and Aventail-based grounds would not place a significant burden on
`the parties or the Board. Accordingly, Patent Owner has not shown a
`
`7
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`sufficient reason to deny this Petition or the petition in IPR2016-00331, and
`we decline to exercise our discretion to deny either. See 37 C.F.R.
`§ 42.108(a) (Board has discretion “to proceed . . . on all or some of the
`grounds of unpatentability asserted”).
`II. ANALYSIS
`A. Claim Construction
`In an inter partes review, the Board construes claims by applying the
`broadest reasonable interpretation in light of the specification. 37 C.F.R.
`§ 42.100(b); Cuozzo Speed Techs., LLC v. Lee, No. 15-446, 2016 WL
`3369425 (U.S. June 20, 2016). Under this standard, absent any special
`definitions, claim terms or phrases are given their ordinary and customary
`meaning, as would be understood by one of ordinary skill in the art, in the
`context of the entire disclosure. In re Translogic Tech., Inc., 504 F.3d 1249,
`1257 (Fed. Cir. 2007).
`Petitioner and Patent Owner each proffer proposed constructions of
`several claim terms. At this stage of the proceeding, neither party has
`identified a dispositive term for construction. For the purposes of this
`Decision, and on this record, we determine that no claim term needs express
`construction. See Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795,
`803 (Fed. Cir. 1999) (only those terms which are in controversy need to be
`construed and only to the extent necessary to resolve the controversy).
`B. Prior Art Printed Publication Status of
`Aventail, RFC 2401, and RFC 2543
`Patent Owner asserts that Petitioner fails to provide evidence to
`establish that Aventail Administrator Guide (Ex. 1009), RFC 2401 (Ex.
`1008), and RFC 2543 (Ex. 1013) would have been sufficiently accessible to
`
`8
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`the public interested in the art, on January 31, 1999, in November 1998, and
`in March 1999, the dates associated with, or recited on, pages of the
`respective references. See Prelim. Resp. 4–5, 19–25.4 According to Patent
`Owner, Petitioner fails to show that Aventail, RFC 2401, and RFC 2543
`constitute prior art printed publications; therefore, they cannot be used to
`show obviousness according. Id. at 19–25.
`The determination of whether a given reference qualifies as a prior art
`“printed publication” involves a case-by-case inquiry into the facts and
`circumstances surrounding the reference’s disclosure to members of the
`public. In re Klopfenstein, 380 F.3d 1345, 1350 (Fed. Cir. 2004).
`1. Aventail Administrator Guide
`The Aventail Administrator Guide is a colored brochure listing
`products and bearing a 1996–1999 copyright notice by Aventail
`Corporation, a website http://www.aventail.com, and the statement
`“[p]rinted in the United States of America.” Ex. 1009, i. Citing the Hopen
`Declaration, Petitioner contends that the Aventail Administrator Guide was
`shipped to customers with software products between “December 1998 and
`January of 1999.” Pet. 19 (citing Ex. 1058 ¶¶ 13–16). Mr. Hopen, testifies
`that as a former Aventail employee, he was involved in the design,
`development, and distribution of Aventail products, and that an estimated
`“thousands of copies” of the software products and manuals were distributed
`during the first six months of 1999. Ex. 1058 ¶¶ 4, 14–16. Petitioner also
`
`
`4 Although Patent Owner generally challenges the public availability of
`Aventail, the arguments appear to focus on Exhibit 1009: i.e., “a copy of
`Aventail Connect v3.01/2.51 Administrator’s Guide, which is Aventail.”
`Prelim. Resp. 21.
`
`9
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`relies on the Chester Declaration and Fratto Declaration. Mr. Chester,
`formerly of IBM, testified that he received the relevant Aventail products
`and brochures no later than the end of December 1998, and subsequently
`distributed the documents to customers and IBM employees in mid-January
`of 1999. Pet. 19: Ex. 1022 ¶¶ 14–18.
`Patent Owner contends that Mr. Hopen, Mr. Chester, and Mr. Fratto
`provide uncorroborated testimony, and that Mr. Fratto is biased against
`Patent Owner. See Prelim. Resp. 21–25. Patent Owner contends that
`testimony about thousands of copies during the first six months of 1999 do
`not establish a publication date of January 1999––the date upon which
`Petitioner relies as the latest publication date of the Aventail Administrator
`Guide. See id. at 22.
`On this preliminary record, the Aventail Administrator Guide itself
`bears indicia showing it is a product manual to be distributed with a
`commercial product. For example, it seeks customer feedback: “please e-
`mail comments to support@aventail.com. Your input is appreciated.” Ex.
`1009, 6. It provides contact information for “Aventail Technical Support.”
`Id. at 5. It lists Aventail protected trademarks and copyrights, the Aventail
`mailing and email addresses, and bears color indicia of the front of the
`brochure, all further evidencing that the Aventail Administrator Guide is the
`kind of document expected to be widely disseminated. Id. at Cover, i. In
`addition, Petitioner asserts that the effective filing date for the ’696 patent is
`no earlier than February 15, 2000. Pet. 10. Patent Owner does not appear to
`challenge this date, so it is unclear why Patent Owner contends that evidence
`about distribution of thousands of copies of Aventail products and brochures
`over the first six months in 1999 helps to show public unavailability of the
`
`10
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`Aventail Administrator Guide prior to the relevant filing date of the ’696
`patent. Furthermore, the Aventail documents cross-reference the products or
`brochures of each other as system components, further evidencing an intent
`to distribute, such that an interested artisan of ordinary skill would have been
`led to brochures about the system products. See, e.g., Ex. 1010, 5 (referring
`user’s to the “Administrator’s Guide” (Ex. 1009)); Ex. 1005 ¶ 116
`(discussing interrelationship).
`On this preliminary record, Petitioner has made a threshold showing
`that Aventail, including the Administrator Guide, constitutes a prior art
`printed publication.
`2. RFC 2401 and 2543
`RFC 2401 and RFC 2543 each include dates on each page, and the
`cover sheets bear the designations “Request for Comments” from the
`“Network Working Group,” discussing particular standardized security
`protocols for the Internet. Ex. 1008, 1; Ex. 1013, 1; see Pet. 27, 30. Each
`document describes itself as a “document [that] specifies an Internet
`standards track protocol for the Internet community, and requests discussion
`and suggestions for improvements. . . . Distribution of this memo is
`unlimited.” Ex. 1008, 1; Ex. 1013, 1; see also Ex. 1005 ¶¶ 117–126
`(discussing Request for Comment (“RFC”) publications). These indicia
`suggest that there is a reasonable likelihood the documents were made
`available to the public (over the Internet), in order to obtain feedback prior
`to implementation of the standard it describes.
`To bolster its showing, Petitioner provides evidence suggesting that
`RFC 2401 and RFC 2543 would have been accessible to the interested
`public. Petitioner relies on testimony of Dr. Tamassia, who describes the
`
`11
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`RFC publication process based partly on his reading of RFC 2026 (discussed
`further below). See Pet. 27, 30 (citing Ex. 1005 ¶¶ 117–128). Petitioner
`also relies on article dated March 15, 1999, referencing RFC 2401
`availability on a website. Pet. 28 (citing Ex. 1065, 3).
`Petitioner also explains that RFC 2401 describes the IPsec protocol
`promulgated by the Internet Engineering Task Force (IETF). Id. at 28.
`Petitioner provides a declaration by Sandy Ginoza, who, acting as a
`designated representative of the IETF, previously testified that RFC 2401
`and RFC 2543 were published on the RFC Editor’s website and were
`publicly available in November 1998. Id. at 27–28, 30 (citing Ex. 1060
`¶¶ 105–107, 168–170; Ex. 1063, 39:14–24). Petitioner provides additional
`documentary evidence, in the form of an August 16, 1999 magazine article
`(Ex. 1064, 9 (discussing RFC 2401 and IPsec protocols and stating “[a]ll of
`these documents are available on the IETF website”)), and the October 1996
`RFC 2026 publication (Ex. 1036, 5–6 (explaining that any interested person
`can obtain RFC documents from a number of Internet hosts using
`anonymous FTP, gopher, WWW, and other document-retrieval systems)).
`Pet. 28–30 (citing Ex. 1064, 9; Ex.1036, 5–6). The cited documents further
`corroborate the testimony of Sandy Ginoza and the above-noted indicia of
`availability on the face of RFC 2401 and RFC 2543.
`Patent Owner characterizes Petitioner’s showing as providing “naked
`assertions.” Prelim. Resp. 26. Patent Owner contends that Dr. Tamassia and
`Sandy Ginoza each lack personal knowledge about the publication of RFC
`2401 and RFC 2543, and challenges other evidence as too general and
`lacking a sufficient foundation. See Prelim Resp. 28–30 (discussing Pet. 25;
`Ex. 1036, 4–6)). Patent Owner does not contest Petitioner’s characterization
`
`12
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`of the two magazine articles, Exhibits 1064 and 1065, other than to refer to
`them as follows: “Exhibit 1064 is allegedly ‘an article from InfoWorld
`magazine (dated August 16, 1999)’ and Exhibit 1065 is allegedly ‘an article
`from NetworkWorld magazine (dated March 15, 1999).’” See Prelim. Resp.
`28–29.
`The parties agree that Exhibit 1036, RFC 2026, reflects “generally
`accepted practices” for RFC documents and states that “any interested
`person can obtain RFCs from a number of Internet hosts.” See Prelim Resp.
`30 (addressing Petitioner’s evidence). Patent Owner characterizes this
`evidence of “generally accepted practices” as providing “no assurance” that
`the general practices were actually applied to “RFC 2401.” Prelim. Resp.
`30.
`
`Showing public availability does not necessarily require establishing
`an assurance of actual dissemination of multiple copies. On this preliminary
`record, Petitioner has made a threshold showing that RFC 2401 and RFC
`2543 constitute prior art printed publications.
` C. Analysis of Obviousness Grounds
`Based on Aventail, RFC 2401, and RFC 2543
`1. Aventail
`Aventail describes an Aventail Connect Client and Aventail ExtraNet
`Server application that allows work stations to connect securely with a
`private network through the Aventail ExtraNet Server. Ex. 1009, 1, 7, 9, 10,
`72; Ex. 1011, 5, 9. “Based on the security policy, the Aventail ExtraNet
`Server will proxy mobile user traffic into the private network but only to
`those resources allowed.” Ex. 1009, 73.
`
`13
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`Aventail Connect resides between a WinSock application and an
`underlying TCP/IP stack. Id. at 9. WinSock, a Windows component,
`connects a Windows PC to the Internet using TCP/IP protocols. Id. at 7.
`Aventail Connect automatically routes traffic from WinSock to the Aventail
`ExtraNet Server, which is an extranet (SOCKS) server, in order to allow the
`workstations to use the SOCKS v5 protocol–– an Internet Engineering Task
`Force approved security protocol for securely traversing corporate firewalls.
`Id. at 6–7. In other words, Aventail Connect can be used in a network as a
`simple proxy client for managed outbound access and secure inbound
`access. Id. at 7. In addition, “Aventail Connect can establish an encrypted
`tunnel automatically.” Id. Aventail Connect also can compress or encrypt
`data before routing to the network. Id.
`In operation, when a calling application, for example, an e-mail
`application or a browser, requests to communicate with an external network
`destination, Aventail Connect receives or intercepts it. See Ex. 1009, 8, 11.
`If the destination matches a redirection rule domain name or a proxy option
`is enabled, Aventail Connect creates a false DNS that later will be
`recognized during a connection request as one to be proxied to the Aventail
`ExtraNet Server. See id. at 10–12. “When the Aventail Connect . . .
`receives a connection request, it determines whether or not the connection
`needs to be redirected (to an Aventail ExtraNet Server) and/or encrypted . . .
`.” Id. at 10.
`The system then performs a SOCKS TCP/IP handshake negotiation
`using the Aventail ExtraNet Server, and Aventail Connect notifies the
`calling application. Id. at 11–12. Ultimately, the calling application
`
`14
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`transmits and receives data using SOCKS. Id. The server may select an
`encryption module. Id. Aventail Connect decrypts any returned data. Id.
`“Only traffic destined for the internal network [behind the Aventail
`ExtraNet Server in the VPN] is authenticated and encrypted; all other traffic
`passes through Aventail Connect unchanged.” Id. at 73. “[N]o direct
`network connections between the public LAN and the private LAN can be
`created without being securely proxied through the Aventail ExtraNet
`Server.” Id. at 72. “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.” Id. at 73 (emphasis added).
`Client work stations must have Aventail Connect to connect to the
`extranet:
`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.
`
`Id. at 72–73.
`2. RFC 2401
`RFC 2401 describes security services offered by IPSec protocols,
`including “access control, connectionless integrity, data origin
`
`15
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`authentication, [and] . . . confidentiality (encryption).” Ex. 1008, 3–4.
`According to RFC 2401, one of the IPsec goals is to provide “confidentiality
`(encryption).” Id. at 4. Using IPsec protocols
`allows the user (or system administrator) to control the
`granularity at which a security service is offered. For example,
`one can create a single encrypted tunnel to carry all the traffic
`between two security gateways or a separate encrypted tunnel
`can be created for each TCP connection between each pair of
`hosts communicating across these gateways.
`
`Id. at 7.
`3. RFC 2543
`RFC 2543 describes a network-based secure video telephony
`architecture that supports both audio and video (i.e., multimedia). Ex. 1013,
`1, 137. These multimedia telephony sessions may use end-to-end
`encryption. Ex. 1013, 54.
`4. Claims 1 and 16––Intercept a Request and Determine
`Claim 1 recites the “intercept” and “determine” clauses as follows:
`
`one or more servers configured to:
`
`intercept, from the first network device, a request to look
`up an internet protocol (IP) address of the second network
`device based on a domain name associated with the second
`network device; [and]
`
`determine, in response to the request, whether the second
`network device is available for a secure communications
`service.
`
`
`
`Claim 16 recites similar limitations. Petitioner generally contends that
`Aventail describes “systems and methods highly analogous to the systems
`and methods disclosed in and claimed by the ’696 patent.” Pet. 32.
`Addressing the intercept clause of claim 1, Petitioner contends that Aventail
`
`16
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`employs an Aventail Connect software server running on a client device that
`looks up an IP address and intercepts the request from the client device. See
`id. at 35–36.5 Petitioner alternatively contends that an Aventail Extranet
`Server performs a name resolution of a connection request when it specifies
`a host name for a target device, thereby intercepting the request from the
`client device. See Pet. 37.
`With respect to the latter alternative, according further to Petitioner:
`Aventail . . . explains that the Aventail Connect client can be
`configured to route all connection requests to the Aventail
`Extranet server (“one or more servers”) for handling and
`resolution. Ex. 1009 at 61; see also id. at 12. The server in this
`configuration will receive the connection request containing
`either the IP address or the domain name of the destination
`computer from the client computer running Aventail Connect,
`and resolve these connection requests. Ex. 1009 at 12; see also
`Ex. 1009 at 61; Ex. 1005 at ¶¶ 196–199.
`
`Id.
`
`Aventail Connect consults a table of redirection results to determine
`whether the request corresponds to a target private device available via an
`Aventail ExtraNet Server. See Ex. 1009, 8–12. Aventail Connect also
`employs a proxy enabled option and proxies DNS requests to the ExtraNet
`Server, which resolves the target host name by returning an IP address. See
`Ex. 1009, 12, 61; Ex. 1005 ¶¶ 197–198 (testifying that enabling DNS Proxy
`
`
`5 Claim 15 depends from claim 1 and implies that a server need not be
`separate from the first network device or client machine. Claim 15 follows:
`“The system of claim 1, wherein the one or more servers configured to
`intercept the request are separate from the first network device.” Ex. 1001,
`56:65–67. Claim 30 depends from claim 16 and recites a similar limitation
`in method format. See id. at 58:28–30.
`
`17
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`functionality causes Aventail Connect to route all DNS requests that do not
`match a local domain string to the Aventail Extranet Server “for interception
`and resolution”); see also Ex. 1005 ¶ 189 (purported flow chart for
`Aventail’s system); Ex. 1009, 12 (“The false entry tells Aventail Connect
`that the DNS lookup must be proxied, and that it must send the fully
`qualified hostname to the SOCKS [Aventail ExtraNet] server with the
`SOCKS connection request.”).
`Relying on the Declaration of Fabian Monrose, Ph.D. from a prior
`related proceeding, Patent Owner contends that Aventail does not disclose
`the claimed “determine” function of claim 1. See Prelim. Resp. 7–10 (citing
`Ex. 2016). According to Patent Owner, Petitioner concedes that Aventail
`does not disclose end-to-end encryption––i.e., to a target device beyond
`Aventail’s Extranet (SOCKS) Server. See id. (Patent Owner and Petitioner
`refer to the terms “SOCKS server” and “Aventail Extranet Server”
`interchangeably. See id. at 5 n.2; Pet. 19.)
`To buttress its argument, Patent Owner explains further:
`The matching of a domain name may result in the connection
`being proxied. (Ex. 2016 at ¶ 36.) But the mere fact that a remote
`host accepts a proxied connection does not disclose or suggest
`that the remote host is one that is available for an encrypted
`connection. (Id.)
`
`Id. at 10.
`Patent Owner’s arguments are not persuasive. Challenged claim 1
`requires the server to be configured to “determine . . . whether the second
`network device is available for a secure communications service.”
`(Emphasis added). The ’696 patent is consistent with claim 1 and describes
`determining whether a device is available for a secure communication––not
`
`18
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`necessarily whether it includes encryption. See Ex. 1001, 40:1–15; accord
`VirnetX, Inc., 767 F.3d at 1323 (“But the patent consistently differentiates
`between ‘security’ and ‘encryption.’ Both the claims and the specification
`of the ’151 patent make clear that encryption is a narrower, more specific
`requirement than security.”).
`Even if claim 1 somehow requires end-to-end encryption (VirnetX
`implies otherwise, id.), the determine clause in claim 1 does not require a
`server to be configured to determine if each target device employs
`encryption, because, for example, devices on secure paths behind a firewall
`on internal company networks are secure without encryption. See id. at
`1322 (finding that with respect to related VirnetX patent claims, “paths
`beyond the VPN server may be rendered secure and anonymous by means of
`‘physical security’ present in the private corporate networks connected to by
`VPN on Demand,” and that the district court’s claim construction of VPN
`“does not require that traffic on a secure path be encrypted. Rather, the
`construction only requires encryption of traffic ‘on insecure paths.’”).
`Assuming claim 1 may require end-to-end encryption and determining
`if the target device uses encryption, Petitioner contends that it would have
`been obvious in view of RFC 2401 to require all devices behind a firewall,
`such as the Aventail ExtraNet Server, to include encryption (i.e., end-to-end
`encryption) in order to further ensure data security and to allow the end
`device to decrypt the data. See Pet. 42–46. In Aventail’s system, at least all
`originating users connected via proxy can be required to have encryption.
`“When the Aventail Connect . . . receives a connection request, it
`determines whether or not the connection needs to be redirected (to an
`Aventail ExtraNet Server) and/or encrypted . . . .” Ex. 1009, 10. “User
`
`19
`
`
`
`Case IPR2016-00332
`Patent 8,504,696 B2
`
`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 wit