throbber
Trials@uspto.gov
`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

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