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

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