`Tel: 571-272-7822
`
`Paper 8
`Entered: September 16, 2015
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`
`Case IPR2015-00813
`Patent 8,850,009 B2
`
`
`
`
`
`
`
`
`
`Before KARL D. EASTHOM, JENNIFER S. BISK, and
`GREGG I. ANDERSON, Administrative Patent Judges.
`
`BISK, Administrative Patent Judge.
`
`DECISION
`Institution Denying Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`IPR2015-00813
`Patent 8,850,009 B2
`
`A. Background
`
`INTRODUCTION
`
`Petitioner, Apple Inc., filed a Petition (Paper 1, “Pet.”) requesting an
`
`inter partes review of claims 1–8, 10–20, and 22–25 (the “challenged
`
`claims”) of U.S. Patent No. 8,850,009 B2 (Ex. 1003, “the ’009
`
`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 ’009 patent against Petitioner and five other entities in
`
`“numerous lawsuits.” Pet. 5–6; Paper 4, 12–13. Petitioner also filed another
`
`petition seeking inter partes review of the ’009 patent—IPR2015-00812.
`
`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–8, 10–20, and 22–25 of the ’009
`
`patent are unpatentable under 35 U.S.C. § 103 based on the combination of
`
`2
`
`
`
`IPR2015-00813
`Patent 8,850,009 B2
`
`Aventail1 and RFC 24012, and Aventail, RFC 2401, and RFC 25433.
`
`Petitioner also provides testimony from Dr. Roberto Tamassia. Ex. 1005.
`
`D. The ’009 Patent
`
`The ’009 patent describes secure methods for communicating over the
`
`Internet. Ex. 1003, 10:16–17. Specifically, the ’009 patent describes “the
`
`automatic creation of a virtual private network (VPN) in response to a
`
`domain-name server look-up function.” Id. at 39:36–38. This automatic
`
`creation makes use of a modified Domain Name Server that may include 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:39–45.
`
`The modified DNS server may include both a conventional
`
`DNS and a DNS proxy. Id. at 40:33–35. 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 and R. Atkinson, Security Architecture for the Internet Protocol,
`Request for Comments: 2401, 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-00813
`Patent 8,850,009 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:39–45. 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:62–65.
`
`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:45–51. 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:51–57.
`
`The VPN is “preferably implemented using the IP address
`
`‘hopping’ features,” (changing IP addresses based upon an agreed
`
`upon algorithm) described elsewhere in the ’009 patent, “such that the
`
`true identity of the two nodes cannot be determined even if packets
`
`during the communication are intercepted.” Id. at 40:18–22.
`
`E. Illustrative Claim
`
`Claims 1 and 14 of the ’009 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-00813
`Patent 8,850,009 B2
`
`send a domain name service (DNS) request to look up a
`network address of a second network device based on an
`identifier associated with the second network device;
`
`receive, following interception of the DNS request and a
`determination that the second network device is available for
`the secure communications service: (1) an indication that the
`second network device
`is available
`for
`the secure
`communications service, (2) the requested network address
`of
`the second network device, and (3) provisioning
`information for an encrypted communication link;
`
`connect to the second network device over the encrypted
`communication link, using the received network address of
`the second network device and the provisioning information
`for the encrypted communication link; and
`
`communicate data with the second network device using the
`secure
`communications
`service via
`the
`encrypted
`communication link,
`
`the network device being a device at which a user uses the
`secure communications service to access the encrypted
`communication link.
`
`Ex. 1003, 56:22–48.
`
`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
`
`5
`
`
`
`IPR2015-00813
`Patent 8,850,009 B2
`
`the time of the invention. In re Translogic Tech., Inc., 504 F.3d 1249, 1257
`
`(Fed. Cir. 2007) (citation and quotations omitted).
`
`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 “does not provide evidence to
`
`establish that RFC 2401 and RFC 2543 would have been sufficiently
`
`accessible to the public interested in the art” on their respective alleged
`
`publication dates. Prelim. Resp. 3. According to Patent Owner, Petitioner
`
`fails to show that RFC 2401 and RFC 2543 constitute prior art printed
`
`publications and are therefore not properly relied upon for purposes of
`
`showing obviousness. Id. at 3–7. 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 ’009 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, 6–8, 10–14, 19, 20, and 22–25 would have
`
`been obvious over Aventail and RFC 2401. Pet. 31–55. Petitioner’s
`
`evidence includes the Declaration of Dr. Roberto Tamassia (Ex. 1005).
`
`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
`
`6
`
`
`
`IPR2015-00813
`Patent 8,850,009 B2
`
`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 14
`
`Petitioner asserts that “the only distinction that may be found to exist
`
`between the systems and methods described in Aventail and the claimed
`
`systems and methods is the nature of the secure communication link—in
`
`particular whether the secure communication link provides ‘end-to-end’
`
`encryption.” Pet. 31. Petitioner relies on RFC 2401 for this limitation
`
`7
`
`
`
`IPR2015-00813
`Patent 8,850,009 B2
`
`stating that it “expressly teaches schemes which provide end-to-end
`
`encryption.” Id. at 48.
`
`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 network address of the second
`
`network device” recited by claims 1 and 14 (“the receiving network address
`
`limitation”). Pet. 41 (citing Ex. 1009, 8–9, 11–12; Ex. 1005 ¶ 237).
`
`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. (citing Ex. 1009, 8–9, 11–12, 40; Ex.
`
`1005 ¶ 237).
`
`We agree with Patent Owner (Prelim. Resp. 19–20) that Petitioner has
`
`not shown sufficiently that Aventail discloses the receiving network address
`
`limitation. The Petition states that “[t]he HOSTENT is a network address.”
`
`Pet. 41. 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 network address of the second network device.”
`
`Prelim. Resp. 20 (emphasis added).
`
`Petitioner’s explanation that HOSTENT “identifies the remote host”
`
`(Pet. 41) does not cure this problem because Petitioner does not explain how
`
`the false DNS entry identifies the remote host. Petitioner cites (Pet. 41) to
`
`several pages of Aventail (Ex. 1009, 8–9 and 11–12), but the only relevant
`
`disclosure states that HOSTENT is a signal to Aventail Connect to “forward
`
`the hostname to the extranet (SOCKS) server.” Ex. 1009, 11–12. Petitioner
`
`8
`
`
`
`IPR2015-00813
`Patent 8,850,009 B2
`
`also cites (Pet. 41) to a paragraph of Dr. Tamassia’s declaration (Ex. 1005
`
`¶ 237), 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. Ex. 1005 ¶ 237.
`
`We are, therefore, not persuaded that Petitioner has shown a
`
`reasonable likelihood that claims 1 and 14 would have been obvious over
`
`Aventail and RFC2401.
`
`4. Claims 6–8, 10–13, 19, 20, and 22–25
`
`Claims 6–8 and 10–13 depend from claim 1 and claims 19, 20, and
`
`22–25 depend from claim 14. Thus, each of these claims requires the
`
`receiving network address limitation. Petitioner’s arguments with regards to
`
`these claims, therefore, suffer from the same problems as claims 1 and 14.
`
`5. Conclusion
`
`Under these circumstances, we are not persuaded that Petitioner has
`
`shown a reasonable likelihood of prevailing in its assertion that claims 1, 6–
`
`8, 10–14, 19, 20, and 22–25 would have been obvious over Aventail and
`
`RFC2401.
`
`D. Obviousness Over Aventail, RFC 2401, and RFC 2543
`
`Petitioner alleges claims 2–5 and 15–18 would have been obvious
`
`over Aventail, RFC 2401, and RFC2543. Pet. 55–59. Claims 2–5, either
`
`directly or indirectly, from claim 1 and claims 15–18 depend, either directly
`
`or indirectly, from claim 14. Thus, each of these claims requires the
`
`receiving network address limitation. Petitioner’s arguments with regards to
`
`these claims, therefore, suffer from the same problems as claims 1 and 14.
`
`9
`
`
`
`IPR2015-00813
`Patent 8,850,009 B2
`
`Under these circumstances, we are not persuaded that Petitioner has shown a
`
`reasonable likelihood of prevailing in its assertion that claims 2–5 and 15–18
`
`would have been obvious over Aventail, RFC2401, 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
`
`
`
`
`
`10
`
`
`
`IPR2015-00813
`Patent 8,850,009 B2
`
`PETITIONER:
`Jeffrey P. Kushan
`Scott Border
`Thomas A. Broughan, III
`SIDLEY AUSTIN LLP
`jkushan@sidley.com
`sborder@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