`Tel: 571-272-7822
`
`Paper 8
`Entered: October 1, 2015
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`
`Case IPR2015-00867
`Patent 8,458,341 B2
`
`
`
`
`
`
`
`
`
`Before KARL D. EASTHOM, JENNIFER S. BISK, and
`GREGG I. ANDERSON, Administrative Patent Judges.
`
`BISK, Administrative Patent Judge.
`
`DECISION
`Denying Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`IPR2015-00867
`Patent 8,458,341 B2
`
`A. Background
`
`INTRODUCTION
`
`Petitioner, Apple Inc., filed a Petition (Paper 1, “Pet.”) requesting an
`
`inter partes review of claims 1–11, 14–25, and 28 (the “challenged claims”)
`
`of U.S. Patent No. 8,458,341 B2 (Ex. 1001, “the ’341 patent”). Patent
`
`Owner, VirnetX Inc., filed a Preliminary Response. Paper 6 (“Prelim.
`
`Resp.”).
`
`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). Upon consideration of the
`
`Petition and the Preliminary Response, and for the reasons explained below,
`
`we determine that the information presented does not show a reasonable
`
`likelihood that Petitioner would prevail with respect to any claim. See
`
`35 U.S.C. § 314(a). Accordingly, we deny the Petition to institute an inter
`
`partes review.
`
`B. Related Matters
`
`The parties indicate Patent Owner has asserted claims of its patents
`
`related to the ’341 patent against Petitioner and five other entities in
`
`“numerous lawsuits.” Pet. 6–7; Paper 5, 12–13. Petitioner also filed another
`
`petition seeking inter partes review of the ’341 patent—IPR2015-00866.
`
`Pet. 2. In addition, many other inter partes review and inter partes
`
`reexamination proceedings challenging related patents are currently, or have
`
`been recently, before the Office.
`
`C. The Asserted Grounds of Unpatentability
`
`Petitioner contends that claims 1–11, 14–25, and 28 of the ’341 patent
`
`are unpatentable under 35 U.S.C. § 103 based on the combination of
`
`2
`
`
`
`IPR2015-00867
`Patent 8,458,341 B2
`
`Aventail1 and RFC 2401,2 as well as Aventail, RFC 2401, and RFC 25433.
`
`Petitioner also provides testimony from Dr. Roberto Tamassia. Ex. 1005.
`
`D. The ’341 Patent
`
`The ’341 patent describes secure methods for communicating over the
`
`Internet. Ex. 1001, 10:9–11. Specifically, the ’341 patent describes “the
`
`automatic creation of a virtual private network (VPN) in response to a
`
`domain-name server look-up function.” Id. at 39:24–26. This automatic
`
`creation makes use of a modified Domain Name Server as opposed to a
`
`conventional Domain Name Server (DNS), which is described as follows:
`
`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:27–33.
`
`The modified DNS server may include both a conventional
`
`DNS and a DNS proxy. Id. at 40:20–22. The DNS proxy of the
`
`
`1 Aventail Connect v3.01/v2.51 Administrator’s Guide (1996–1999) (Ex.
`1009) (“Aventail”). Exhibits 1009–1011 all relate to the Aventail Connect
`application and are collectively referred to as “Aventail Connect” unless
`otherwise noted. See Aventail Connect v3.01/v2.51 User’s Guide (1996–
`1999) (“Aventail User Guide,” Exhibit 1010); Aventail ExtraNet Center v3.0
`Administrator’s Guide (NT and UNIX)(“Aventail ExtraNet,” Exhibit 1011).
`2 S. Kent & R. Atkinson, Security Architecture for the Internet Protocol,
`Request for Comments: 2401 (BBN Corp., November 1998) (Ex. 1008)
`(“RFC 2401”).
`3 M. Handley, et. al., SIP: Session Initiation Protocol, Request for
`Comments: 2543 (March 1999) (Ex. 1013) (“RFC 2543).
`
`3
`
`
`
`IPR2015-00867
`Patent 8,458,341 B2
`
`modified DNS server intercepts all 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–32. 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–52.
`
`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:32–38. The DNS proxy then returns to the user the resolved
`
`address passed to it by the gatekeeper, which need not be the actual
`
`address of the destination computer. Id. at 40:38–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 ’341 patent, “such that the
`
`true identity of the two nodes cannot be determined even if packets
`
`during the communication are intercepted.” Id. at 40:5–9.
`
`E. Illustrative Claim
`
`Claims 1 and 15 of the ’341 patent are independent. Claim 1 is
`
`illustrative of the claimed subject matter and recites:
`
`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:
`
`4
`
`
`
`IPR2015-00867
`Patent 8,458,341 B2
`
`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;
`
`request and a
`the
`interception of
`following
`receive,
`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
`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, 56:2–25.
`
`A. Claim Construction
`
`ANALYSIS
`
`We interpret claims of an unexpired patent using the broadest
`
`reasonable construction in light of the specification of the patent in which
`
`they appear. 37 C.F.R. § 42.100(b); see In re Cuozzo Speed Techs., LLC.,
`
`793 F.3d 1268, 1275–76 (Fed. Cir. July 8, 2015), reh’g en banc denied,
`
`2015 WL 4100060 (Fed. Cir. July 8, 2015). We presume a claim term
`
`carries its “ordinary and customary meaning,” which is “the meaning that
`
`the term would have to a person of ordinary skill in the art in question” at
`
`the time of the invention. In re Translogic Tech., Inc., 504 F.3d 1249, 1257
`
`(Fed. Cir. 2007) (citation and quotations omitted).
`
`5
`
`
`
`IPR2015-00867
`Patent 8,458,341 B2
`
`Petitioner and Patent Owner each proffer proposed constructions of
`
`several claim terms. For purposes of this decision, we determine that no
`
`claim terms require express construction.
`
`B. Prior Art Printed Publication Status of RFC 2401 and RFC 2543
`
`Patent Owner asserts that Petitioner fails to establish that RFC 2401
`
`and RFC 2543 were “sufficiently accessible to the public interested in the
`
`art” on their respective alleged publication dates. Prelim. Resp. 3–4.
`
`According to Patent Owner, Petitioner fails to show that RFC 2401 and RFC
`
`2543 constitute prior art printed publications, and they therefore are not
`
`properly relied upon for purposes of showing obviousness. Id. at 2–10. On
`
`this basis, Patent Owner argues that Petitioner has not satisfied its burden of
`
`showing a reasonable likelihood of prevailing with respect to any challenged
`
`claim of the ’341 patent.
`
`Because we determine that Petitioner does not show a reasonable
`
`likelihood that Petitioner would prevail with respect to any claim, we do not
`
`reach this issue.
`
`C. Obviousness Over Aventail and RFC 2401
`
`Petitioner alleges claims 1, 4, 5, 9–11, 14, 15, 18, 19, 23–25, and 28
`
`would have been obvious over Aventail and RFC 2401.4 Pet. 29–55.
`
`Petitioner’s evidence includes the Declaration of Dr. Roberto Tamassia (Ex.
`
`1005).
`
`
`4 The heading on page 29 of the Petition states that claims 1, 6–14, 19, 20,
`and 22–25 would have been obvious over Aventail and RFC 2401. Pet. 29;
`see also Pet. ii. However, because the subsequent analysis (Pet. 29–55)
`discusses claims 1, 4, 5, 9–11, 14, 15, 18, 19, 23–25, and 28, we presume the
`heading contains a typographical error.
`
`6
`
`
`
`IPR2015-00867
`Patent 8,458,341 B2
`
`1. Overview of Aventail
`
`Aventail is the Administrator’s Guide for the Windows version of an
`
`application called Aventail Connect. Ex. 1009. Aventail Connect is a
`
`secure proxy client based on SOCKS 5 (a security protocol targeted at
`
`securely traversing corporate firewalls). Id. at 1, 6. It sits between WinSock
`
`(Windows Sockets) and the underlying TCP/IP stack, where it can compress
`
`or encrypt data before routing it to the TCP/IP stack for transport over the
`
`network. Id. at 8–9.
`
`“When the Aventail Connect LSP receives a connection request, it
`
`determines whether or not the connection needs to be redirected (to an
`
`Aventail ExtraNet Server) and/or encrypted.” Id. at 10. To make this
`
`determination, Aventail Connect checks the requested hostname to see if it
`
`matches a redirection rule listed in a configuration file, if so, Aventail
`
`Connect creates a false DNS entry—called a HOSTENT—that it can later
`
`recognize during a connection request in which case the requested
`
`connection will be proxied. Id. at 11–12. When the requested connection
`
`has been completed, Aventail Connect notifies the requesting application,
`
`which may then transmit and receive data. Id. Aventail Connect may also
`
`encrypt data on its way to the server and decrypt it on return. Id.
`
`2. Overview of RFC 2401
`
`RFC 2401 describes the security services offered by the IPsec
`
`protocols, including “access control, connectionless integrity, data origin
`
`authentication, [and] . . . confidentiality (encryption).” Ex. 1008, 3–4.
`
`3. Claims 1 and 15
`
`Petitioner asserts that “the only distinction that may be found to exist
`
`between the systems and methods described in Aventail and the claimed
`
`7
`
`
`
`IPR2015-00867
`Patent 8,458,341 B2
`
`systems and methods is the nature of the VPN/secure communication link—
`
`in particular whether the VPN/secure communication link provides ‘end-to-
`
`end’ encryption.” Pet. 29. Petitioner relies on RFC 2401 for this limitation
`
`stating that it “expressly teaches schemes which provide end-to-end
`
`encryption.” Id. at 47.
`
`Petitioner relies on Aventail’s disclosure that the software establishing
`
`a connection receives a “HOSTENT” from Aventail Connect for the
`
`limitation “receiv[e/ing] . . . the requested IP address of the second network
`
`device” recited by claims 1 and 15 (“the receiving IP address limitation”).
`
`Pet. 40 (emphasis omitted) (citing Ex. 1009, 8–9, 11–12; Ex. 1005 ¶ 275).
`
`According to Petitioner, “Aventail explains that the Aventail Connect client
`
`uses the HOSTENT value to identify the remote host with which the user
`
`wishes to establish a connection.” Id.
`
`We agree with Patent Owner (Prelim. Resp. 22–24) that Petitioner has
`
`not shown sufficiently that Aventail discloses the receiving IP address
`
`limitation. The Petition states that “[t]he HOSTENT is a network address.”
`
`Pet. 40 (emphasis added). This statement, however, appears contrary to
`
`Aventail’s only disclosure related to HOSTENT—“Aventail Connect creates
`
`a false DNS entry (HOSTENT) that it can recognize during the connection
`
`request.” Ex. 1009, 11–12. As Patent Owner explains, a false DNS entry “is
`
`unequivocally not the IP address of the second network device.” Prelim.
`
`Resp. 22–23 (emphasis added).
`
`Petitioner’s explanation that HOSTENT “identifies the remote host”
`
`(Pet. 40) does not cure this problem because Petitioner does not explain how
`
`the false DNS entry identifies the remote host. Petitioner cites (id.) to
`
`several pages of Aventail (Ex. 1009, 8–9, 11–12), but the only relevant
`
`8
`
`
`
`IPR2015-00867
`Patent 8,458,341 B2
`
`disclosure states that HOSTENT is a signal to Aventail Connect to “forward
`
`the hostname to the extranet (SOCKS) server.” Ex. 1009, 11–12. Petitioner
`
`also cites (Pet. 40) to a paragraph of Dr. Tamassia’s Declaration (Ex. 1005
`
`¶ 275), which does not further clarify how HOSTENT identifies the remote
`
`host. Instead, this testimony simply reiterates that Aventail Connect creates
`
`a false DNS entry, called HOSTENT, that it can recognize during a
`
`connection request. Id.
`
`We are, therefore, not persuaded that Petitioner has shown a
`
`reasonable likelihood that claims 1 and 15 would have been obvious over
`
`Aventail and RFC 2401.
`
`4. Claims 4, 5, 9–11, 14, 18, 19, 23–25, and 28
`
`Claims 4, 5, 9–11, and 14 depend, either directly or indirectly, from
`
`claim 1 and claims 18, 19, 23–25, and 28 depend, either directly or
`
`indirectly, from claim 15. Thus, each of these claims requires the receiving
`
`IP address limitation. Petitioner’s arguments with regards to these claims,
`
`therefore, suffer from the same problems as claims 1 and 15.
`
`5. Conclusion
`
`Under these circumstances, we are not persuaded that Petitioner has
`
`shown a reasonable likelihood of prevailing in its assertion that claims 1, 4,
`
`5, 9–11, 14, 15, 18, 19, 23–25, and 28 would have been obvious over
`
`Aventail and RFC 2401.
`
`9
`
`
`
`IPR2015-00867
`Patent 8,458,341 B2
`
`D. Obviousness Over Aventail, RFC 2401, and RFC 2543
`
`Petitioner alleges claims 2, 3, 6, 7, 8, 16, 17, and 20–22 would have
`
`been obvious over Aventail, RFC 2401, and RFC 2543. 5 Pet. 56–60.
`
`Claims 2, 3, 6, 7, and 8 depend, either directly or indirectly, from claim 1
`
`and claims 16, 17, and 20–22 depend, either directly or indirectly, from
`
`claim 15. Thus, each of these claims requires the receiving IP address
`
`limitation. Petitioner’s arguments with regards to these claims, therefore,
`
`suffer from the same problems as claims 1 and 15. Under these
`
`circumstances, we are not persuaded that Petitioner has shown a reasonable
`
`likelihood of prevailing in its assertion that claims 2, 3, 6, 7, 8, 16, 17, and
`
`20–22 would have been obvious over Aventail, RFC2401, and RFC2543.
`
`CONCLUSION
`
`The Petition fails to show there is a reasonable likelihood that
`
`Petitioner would prevail with respect to at least one of the claims challenged
`
`in the Petition. See 35 U.S.C. § 314(a); 37 C.F.R. § 42.108.
`
`Accordingly, the Petition is denied, and no trial is instituted.
`
`ORDER
`
`
`
`
`
`
`5 The heading on page 56 of the Petition states that claims 2–5 and 15–18
`would have been obvious over Aventail, RFC 2401, and RFC 2543. Pet. 56;
`see also Pet. ii. However, because the subsequent analysis (Pet. 56–60)
`discusses claims 2, 3, 6, 7, 8, 16, 17, and 20–22, we presume the heading
`contains a typographical error.
`
`10
`
`
`
`IPR2015-00867
`Patent 8,458,341 B2
`
`PETITIONER:
`Jeffrey P. Kushan
`Thomas A. Broughan, III
`SIDLEY AUSTIN LLP
`jkushan@sidley.com
`tbroughan@sidley.com
`iprnotices@sidley.com
`
`
`
`PATENT OWNER:
`Joseph E. Palys
`Naveen Modi
`PAUL HASTINGS LLP
`josephpalys@paulhastings.com
`naveenmodi@paulhastings.com
`
`Jason Stach
`FINNEGAN, HENDERSON, FARABOW,
`GARRETT & DUNNER, L.L.P.
`jason.stach@finnegan.com
`
`
`
`11