Trials@uspto.gov Paper 8
`Tel: 571-272-7822
`Entered: Oct. 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-00871
`Patent 8,560,705 B2
`____________
`
`
`
`Before KARL D. EASTHOM, JENNIFER S. BISK, and
`GREGG I. ANDERSON, Administrative Patent Judges.
`
`EASTHOM, Administrative Patent Judge.
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`
`I. INTRODUCTION
`Apple Inc. (“Petitioner”) filed a Petition (Paper 1, “Pet.”) pursuant to
`35 U.S.C. §§ 311–319 to institute an inter partes review of claims 1–30 of
`U.S. Patent No. 8,560,705 B2 (Ex. 1050, “the ’705 patent”). VirnetX Inc.
`(“Patent Owner”) filed a Preliminary Response. Paper 6 (“Prelim. Resp.”).
`We have jurisdiction under 35 U.S.C. § 314.
`For the reasons explained below, we institute an inter partes review of
`claims 1–30 of the ’705 patent. We have not yet made a final determination
`with respect to the patentability of any claim.
`
`A. Related Matters
`Petitioner fails to identify directly or generally any lawsuits where the
`’705 patent has been asserted against it.1 Patent Owner has asserted the ’705
`patent, or patents in the same family as the application that resulted in the
`’705 patent, against Petitioner in four different lawsuits. Paper 5, 12–13.2
`Petitioner also filed another petition seeking inter partes review of the
`’705 patent—IPR2015-00870 (“the ’810 IPR”). 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. Paper 5, 3–10.
`
`1 Petitioner is advised that its failure to identify any judicial or all
`administrative matters relating to the ’705 patent that would affect or be
`affected by a decision here may be considered a violation of 37 C.F.R.
`§ 42.8. See Pet. 2.
`2 Patent Owner is advised to be specific in addressing whether the
`challenged patent is actually the subject of the enumerated related litigation
`instead of stating the ’705 patent “and/or other patents that stem from the
`same applications that led to the ’705 patent.” In the future, this may be
`considered a violation of 37 C.F.R. § 42.8. See Paper 5, 12–13.
`
`
`
`
`2
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`
`B. The ’705 Patent
`
`The ’705 patent describes secure methods for communicating over the
`Internet. Ex. 1050, 9:41–46. Specifically, the ’705 patent describes “the
`automatic creation of a virtual private network (VPN) in response to a
`domain-name server look-up function.” Id. at 39:4–6. This automatic
`creation employs a modified Domain Name Server, which may include a
`conventional Domain Name Server (DNS):
`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:7–13.
`
`In addition to conventional DNS functionality, a modified DNS may
`include a DNS proxy. Id. at 39:67–40:2. In a described embodiment
`pertaining to Figure 26 (reproduced below), DNS proxy 2610 intercepts
`requests from client 2601 to determine whether client 2601 requests access
`to a secure site by using a domain extension or an internal table of such sites.
`Id. at 40:6–11. If not, DNS proxy 2610 passes the request to DNS server
`2609. Id. at 40:53–55. If client 2601 requests access to a secure site,
`gatekeeper 2603 may communicate with DNS proxy 2610 and facilitate a
`secure VPN link, such as by using “hopped” IP addresses. Id. at 41:14–22.
`
`
`
`
`
`3
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`
`A reproduction of Figure 26 of the ’705 patent follows:
`
`
`Figure 26 shows user computer 2601 (which includes a web browser),
`gatekeeper server 2603, modified DNS 2602, secure target site 2604, and IP
`hopping modules 2607 and 2608. Modified DNS 2603 includes both a
`conventional DNS server function 2609 and DNS proxy 2610. Conventional
`IP protocols allow access to unsecure target site 2611. Id. at 39:63–40:5.
`In general, DNS proxy 2610 intercepts DNS lookup requests,
`determines whether the user has requested access to a secure site, and
`if so, whether the user has sufficient security privileges to access the
`requested site. Id. at 40:6–16. 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:32–33. If
`the user has requested access to a secure site to which it has sufficient
`
`
`
`4
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`security privileges, the DNS proxy requests a gatekeeper to create a
`VPN link between the user’s computer and the secure target site. See
`id. at 40:12–16. 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:19–25. A requesting
`user may be required to match the security level of a host. Id. at 40:
`65–67.
`The VPN communication link is “preferably implemented using
`the IP address ‘hopping’ features of the basic invention” (i.e.,
`changing IP addresses based upon an agreed upon algorithm) “such
`that the true identity of the two nodes cannot be determined even if
`packets during the communication are intercepted.” Id. at 39:52–56;
`see id. at 41:14–22, 50:58–14, Fig. 33 (describing IP hopping
`techniques used for VPN communication link 3319). According to
`one example, after establishing VPN link 3321 between computers
`3301 and 3320 (see Fig. 33), “[f]urther communication occurs via the
`VPN, e.g., using a ‘hopping’ regime . . . . [over] VPN link 3321.” Id.
`at 52:4–6.
`
`C. Illustrative Claim
`Claims 1 and 16 of the ’705 patent are independent and of similar
`scope. Claim 1, illustrative of the challenged claims, follows:
`1. A client device comprising:
`
`(a) memory configured and arranged to facilitate a
`connection of the client device with a target device over a
`secure communication link created based on
`
`
`(i) interception of a request, generated by the client
`device, to look up an internet protocol (IP) address of the target
`
`
`
`5
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`
`Aventail
`
`Aventail (see note 3)
`
`device based on a domain name associated with the target
`device, and
`(ii) a determination as a result of the request that
`
`
`the
`target device
`is a device with which a secure
`communication link can be established;
`
`(b) an application program configured and arranged so as
`to allow participation in audio/video communications with the
`target device over the secure communication link once the
`secure communication link is established; and
`
`(c) a signal processing configuration arranged to execute
`the application program.
`D. References relied upon
`Petitioner relies on the following references. Pet. 2–3, Attachment B.
`Reference
`Description
`Publication or
`Exhibit No.
`Issue Date
`1996–1999
`
`Ex. 1009–
`10113
`Ex. 1008
`
`Nov. 1998
`
`RFC 2401 S. Kent and Randall
`Atkinson, RFC 2401,
`Security Architecture for
`the Internet Protocol,
`Network Working Group,
`Request for Comments
`US 5,237,566
`Brand
`RFC 2543 Handley et al., SIP: Session
`Initiation Protocol,
`Network Working Group,
`Request for Comments
`
`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).
`
`Aug. 17, 1993 Ex. 1012
`Mar. 1999
`Ex. 1013
`
`
`
`6
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`
`
`E. Asserted Grounds of Unpatentability
`Petitioner challenges claims 1–30 of the ’705 patent as unpatentable
`on the following grounds. Pet. 2–3.
`References
`Aventail, RFC 2401, and RFC 2543
`Aventail, RFC 2401, RFC 2543, and
`Brand
`
`Claims Challenged
`Basis
`§ 103(a) 1–23 and 25–30
`§ 103(a) 24
`
`
`II. ANALYSIS
`
`A. Claim Construction
`In an inter partes review, “[a] claim in an unexpired patent shall be
`given its broadest reasonable construction in light of the specification of the
`patent in which it appears.” 37 C.F.R. § 42.100(b); see In re Cuozzo Speed
`Techs., LLC, 793 F.3d 1268, 1275–76 (Fed. Cir. 2015); see also Office
`Patent Trial Practice Guide, 77 Fed. Reg. 48,756, 48,766 (Aug. 14, 2012)
`(Claim Construction). Under the broadest reasonable construction standard,
`claim terms 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). Any special definition for a claim term must be set forth in the
`specification with reasonable clarity, deliberateness, and precision. In re
`Paulsen, 30 F.3d 1475, 1480 (Fed. Cir. 1994). In the absence of such a
`special definition or other consideration, “limitations are not to be read into
`the claims from the specification.” In re Van Geuns, 988 F.2d 1181, 1184
`(Fed. Cir. 1993).
`
`
`
`7
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`
`At this stage of the proceeding, neither party has identified a term for
`construction that is dispositive on any of the challenges.
`B. The ’870 IPR
`Patent Owner argues the present case is redundant with the ’870 IPR,
`and the Board should deny institution on that basis. Prelim. Resp. 10–14.
`Patent Owner contends that “redundant 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.”
`Prelim. Resp. 11 (citation omitted).
`Patent Owner also contends that “[t]he ’870 Petition’s grounds of
`rejection simply substitute Aventail and RFC 2543 with Beser.” Prelim.
`Resp. 10. Although the grounds asserted here are similar to those asserted in
`the ’870 IPR, they are not the same. Beser has been involved in recent
`proceedings between the two parties. See, e.g., Apple Inc. v. VirnetX Inc.,
`Case IPR2014-00481 (PTAB Aug. 24, 2015) (Paper 35). Similarly,
`Aventail has been involved in litigation between the parties and prosecution
`at the Office. See infra note 6; PO Resp. 38, 44. Under the specific
`circumstances involved at this juncture, the Aventail-based grounds would
`not place a significant burden on the parties or the Board. Accordingly,
`Patent Owner has not shown a sufficient reason to deny the ’870 petition or
`this Petition. Accordingly, we decline to exercise our discretion to deny
`either.
`C. Prior Art Printed Publication Status of RFC 2401and RFC 2543
`Patent Owner asserts that Petitioner fails to provide evidence to
`establish that RFC 2401 and RFC 2543 would have been sufficiently
`accessible to the public interested in the art, in November 1998 and March
`
`
`
`8
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`1999, the dates recited on pages of the respective references. See Prelim.
`Resp. 2–3. According to Patent Owner, Petitioner fails to show that RFC
`2401 and RFC 2543 constitute prior art printed publications, and they are
`therefore not properly relied upon for purposes of showing obviousness. Id.
`at 2–6. 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 ’705 patent.
`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). We
`acknowledge Patent Owner’s arguments regarding RFC 2401 and RFC
`2543. However, 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. 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 ¶¶ 186–97 (discussing Request
`for Comment (“RFC”) publications). These indicia suggest that there is a
`reasonable likelihood the document was made available to the public (over
`the Internet), in order to obtain feedback prior to implementation of the
`standard it describes.
`On this record, we are persuaded that Petitioner has made a threshold
`showing that RFC 2401 and RFC 2543 constitute prior art printed
`
`
`
`9
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`publications.4 Accordingly, we consider the disclosure of RFC 2401 and
`RFC 2543 for the purposes of this decision.
`D. Failure to Allege With Particularity
`Patent Owner generally alleges certain parts of the Petition fail to
`meet the requirements of 35 U.S.C. § 314(a) and 37 C.F.R.
`§ 42.104(b)(4). Prelim. Resp. 14–15. Based on the discussion herein and a
`review the Petition and Preliminary Response, Patent Owner fails to show a
`deficiency.
`E. Analysis of Obviousness Grounds Based on
` Aventail, RFC 2401, and RFC 2543
`
`Petitioner alleges claims 1–23 and 25–30 would have been obvious
`over Aventail, RFC 2401, and RFC 2543. Pet. 27–51. Petitioner’s evidence
`includes the Declaration of Dr. Roberto Tamassia (“Tamassia Declaration,”
`Ex. 1005), which describes the Aventail system, RFC 2401, and RFC 2543.
`Ex. 1005 ¶¶ 160–273, 346–382.
`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
`
`
`4 To the extent that Patent Owner objects to the admissibility of this
`evidence, it will have the opportunity, after trial is instituted, to enter any
`objections to evidence. 37 C.F.R. § 42.64(b)(1). To the extent that Patent
`Owner continues to assert that Petitioner has not met its burden of showing
`that RFC 2401 and RFC 2543 are printed publications, it will have the
`opportunity to make arguments in its Patent Owner Response.
`
`
`
`
`10
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`Server will proxy mobile user traffic into the private network but only to
`those resources allowed.” Ex. 1009, 73.
`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/ICP 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 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
`
`
`
`11
`
`

`
`IPR2015-00871
`Patent 8,560,705 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. 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.
`
`2. RFC 2401
`RFC 2401 describes security services offered by IPSec protocols,
`including “access control, connectionless integrity, data origin
`authentication, [and] . . . confidentiality (encryption).” Ex. 1008, 3–4.
`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.
`
`
`
`12
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`
`4. Claims 1 and 16––Determination and Request
`Claim 1 of the ’705 patent recites a “determination as a result of the
`request that the target device is a device with which a secure communication
`link can be established.” According further to claim 1, the intercepted
`“request,” generated by the client device, constitutes a “request . . . to look
`up an internet protocol (IP) address of the target device based on a domain
`name associated with the target device.” Claim 16 recites similar
`limitations.
`Petitioner makes the following contentions regarding the
`determination and request clauses. In one configuration, Aventail Connect
`consults a table of redirection results to determine whether the request
`corresponds to a device known to be available via an Aventail ExtraNet
`Server. Pet. 22 (citing Ex. 1009, 8–12). In another configuration, all
`requests are proxied to the ExtraNet Server, which resolves the target host
`name. Id. (citing Ex. 1009, 12, 61). Under either configuration, Aventail
`Connect responds to the request by creating a “false” DNS entry and
`replying with the false entry, “HOSTENT,” to the requesting application, “in
`response to the request to lookup the domain name.” Id. at 23 (citing Ex.
`1009, 11–12; Ex. 1005 ¶ 275). The requesting client subsequently uses the
`false entry for a connection request, and recognizing the request as one to be
`proxied, Aventail Connect sends it the ExtraNet Server to resolve it. See id.
`at 22–23.
`In both configurations, either the client computer’s operating system
`handles known domain name requests, or Aventail Connect proxies the
`request to the ExtraNet Server. See id.; Ex. 1005 ¶ 264; Ex. 1009, 12.
`Petitioner’s declarant, Dr. Tamassia, provides a flowchart to support the
`
`
`
`13
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`contentions. Ex. 1005 ¶ 256. Near the end of the flow chart, to establish a
`VPN connection, Aventail Connect sends a hostname (a “fully qualified
`hostname” (Ex. 1009, 12)) to the Aventail ExtraNet server to access a
`resource. See Ex. 1005 ¶¶ 256, 265. In other words, “[t]he 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.” Ex. 1009, 12.
`In response, and addressing Dr. Tamassia’s flowchart, Patent Owner
`contends that “Petitioner’s expert agrees that the connection request only has
`an IP address and not a domain name.” PO Resp. 19 (citing Ex. 1005
`¶ 256).5 According to Patent Owner, a “proxy request” may include a
`domain name, but it is sent after the connection request and after the
`connection is completed, and therefore “is never matched against a
`redirection rules table.” Id. at 20 (citing Ex. 1009, 11–12). On the other
`hand, Patent Owner contends that “the matching of the host name against the
`redirection rules table occurs much earlier”––i.e., before the “proxy request”
`that also has the host name, and thus, those rules do not include determining
`encryption. See id. at 20.
`Patent Owner’s contentions are not persuasive on this record. The
`record does not reflect that Dr. Tamassia asserts that the connection request
`only has an IP address. Rather, Dr. Tamassia’s flow chart shows a branch at
`the top that signifies sending a “hostname” that Aventail Connect intercepts.
`See Ex. 1009 ¶ 256. In addition, according to Petitioner, Aventail Connect
`and/or the Aventail ExtraNet Server intercepts an initial request from the
`
`
`5 The parties generally refer to a host name and a domain name
`interchangeably. See Pet. 22–23; Prelim. Resp. 20–23; Ex. 1009, 11.
`
`
`
`14
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`client that includes either a domain name or an IP address. Pet. 36–38
`(citing Ex. 1009, 7–9, 72–73, 90–92; Ex. 1005 ¶¶ 247, 266); Pet. 39 (citing
`Ex. 1009, 11–12; Ex. 1005 ¶¶ 267–75). The domain name causes Aventail
`Connect to perform an IP lookup to determine if the request should be
`proxied. See Pet. 40 (citing Ex. 1009, 8–9, 11–12, 40; Ex. 1005 ¶ 275).
`In other words, in response to a domain name in the request, if the
`system is in the configuration wherein proxy is not enabled, but the
`redirection rules apply, Aventail Connect determines that the domain name
`must be proxied to the Aventail ExtraNet Server, which, on this record,
`constitutes a determination that the domain name corresponds to a secure
`private device connected to the Aventail ExtraNet Server. See Ex. 1009, 8–
`12, 72–73. Aventail implies that these redirection rules include determining
`if encryption applies. Ex. 1009, 10 (“When redirection and encryption are
`not necessary, Aventail Connect simply passes the connection request . . . to
`the TCP/IP stack.”). If proxy is enabled, or if proxy is not enabled but the
`redirection rules apply, a request includes a “fully qualified hostname” (Ex.
`1009, 12), that Aventail Connect “forward[s] (id. at 11) to the Aventail
`Server, which responds by determining, in conjunction with a SOCKS
`negotiation, whether the connection is allowed or denied. See Pet. 40 (citing
`Ex. 1009, 5, 12; Ex. 1005 ¶¶ 280–81); Ex. 1009, 11–12, 72–73. Therefore,
`the Aventail ExtraNet Server with a SOCKs negotiation determines based on
`the requested target host name that the client can connect to a specified
`secure target device in the VPN behind the Aventail ExtraNet Server and
`whether the connection supports encryption. See Ex. 1009, 10–12, 72–73;
`Ex. 1005 ¶¶ 203–06, 280–84. In either scenario, Aventail Connect may
`determine whether the connection should be encrypted, with Aventail
`
`
`
`15
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`Connect and Aventail ExtraNet Server interacting to establish the encrypted
`channel (if necessary). See Ex. 1005 ¶¶ 279–280 (citing Ex. 1009, 10, 12).
`Patent Owner also argues that “the mere fact that a remote host
`requires a proxied connection does not suggest that the remote host also
`requires an encrypted connection.” PO Resp. 21. Patent Owner reasons
`that “the remote host does not accept an encrypted connection.” Id. at 22.
`In other words, Patent Owner maintains that Petitioner has not shown that
`the Aventail system includes encryption beyond the Aventail ExtraNet
`Server. See id. at 21–23.
`The determination limitation recites a “determination that the second
`network device is available for a secure communications service.” Petitioner
`contends that even if Aventail does not explicitly disclose encryption (as a
`form of security) to the target hosts, RFC 2401 suggests the limitation in
`Aventail’s similar system––i.e., “end-to-end encryption, including one
`which provides this over firewall or proxy computers that sit between the
`origination destinations of the end-to-end communication path.” Pet. 44; see
`also Pet. 28–29 (citing Ex. 1008, 25–26), 43–44 (citing “Case 4”; Ex. 1005
`¶¶ 403–20).
`In general, the Aventail system provides security from client to target
`devices in a private network connected to and beyond the Aventail ExtraNet
`Server: “[B]ased 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. Also, “[w]hen 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 (in SSL).” Id.
`at 10; see also Ex. 1009, 73 (“Only traffic destined for the internal network
`
`
`
`16
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`is authenticated and encrypted; all other traffic passes through Aventail
`Connect unchanged.”). Petitioner also relies on Aventail’s disclosure that
`the ExtraNet Server “‘determine[s] which people and groups can access
`what machines and services based on where they came from, the time of
`day, how they authenticated, and encryption strength, etc.’” Pet. 40 (quoting
`Ex. 1011, 19). Dr. Tamassia states that “Aventail Connect will evaluate the
`redirection rule to determine if the target host is one for which proxy
`redirection (and an encrypted communication) through the Aventail
`ExtraNet Server is required.” Ex. 1005 ¶ 237 (citing Ex. 1009, 11).
`As discussed above, on this record, Aventail discloses encrypting
`select traffic at least up to the Aventail ExtraNet Server based on matching
`the client to host target resources, which specifies a certain matched security,
`including encryption. RFC 2401 discloses encrypting traffic beyond a
`firewall or gateway server to provide added security to the communication.
`Aventail discloses encryption and decryption by Aventail Connect, but does
`not mention a decryption feature at the ExtraNet Server, thereby suggesting,
`with RFC 2401, encryption beyond that server for targets to ensure security,
`and a corresponding determination that those hosts match a desired level of
`encryption. See Ex. 1009, 12, 59–67, 72; Ex. 1008, 3–4, 24–26; Pet. 45–46;
`Ex, 1005 ¶¶ 412–415, 420. On this limited record, we are persuaded that
`Petitioner has provided sufficiently an articulated reasoning with some
`rational underpinning to support the legal conclusion of obviousness as to
`the determination and request limitations. See KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398, 418 (2007) (citing In re Kahn, 441 F.3d 977, 988 (Fed. Cir.
`2006)).
`
`
`
`17
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`
`5. Claims 1, 6, 16, and 22––Direct Connection––Secure
`Communication Link, VPN Link
`In a claim construction discussion of a “secure communication link”
`and a “virtual private network link” (VPN link), Patent Owner contends that
`based on prosecution history and prior litigation of related patents, Patent
`Owner clearly disclaimed a VPN link that does not have a “direct”
`connection, that Patent Owner previously argued at the PTO that Aventail
`does not disclose a direct connection, and that the Federal Circuit and a
`district court recently determined that a secure communication link requires
`a direct connection in a related patent. See PO Resp. 38–39, 44–46 (citing
`Virnetx, Inc. v. Cisco Systems, Inc., 767 F.3d 1308, 1319 (Fed. Cir. 2014)).
`In Cisco, the court addressed a direct requirement imposed at the district
`court that neither party challenged on appeal. See Cisco, 767 F.3d at 1320.
`The Cisco court also noted that testimony at the district court showed that a
`direct connection does not preclude intervening routers, firewalls, and
`similar services or devices on networks such as the Internet (i.e., between the
`requesting client and target host). See id.
`Despite its proffered claim construction, Patent Owner does not
`specifically contend, in this proceeding, that Aventail fails to disclose or
`suggest a “direct” connection. On the other hand, Petitioner contends that
`“Aventail expressly teaches that ExtraNet Servers are capable of ‘directly’
`forwarding encrypted network traffic.” Pet. 46 (quoting figure Ex. 1009, 63;
`Ex. 1005 ¶¶ 417–20). Dr. Tamassia testifies that the SOCKS (Aventail
`ExtraNet) server as disclosed in Aventail can be a firewall, or behind the
`firewall as a dedicated server, similar to a gateway to a private network. See
`Ex. 1005 ¶¶ 200, 226. The reasoning of Cisco, 767 F.3d at 1320, indicates
`that a direct connection does not preclude such a forwarding server or
`
`
`
`18
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`similar corporate gateway device. Aventail also states that “no direct
`network connections between the public LAN and the private LAN can be
`created without being securely proxied through the Aventail ExtraNet
`Server.” Ex. 1009, 72 (emphases added). This statement implies further
`that the Aventail ExtraNet Server creates a direct, secure connection, in a
`secure communication link or VPN link, to target hosts in a private LAN.
`Therefore, on this preliminary record, we need not determine if a
`secure communication link as recited in claims 1 and 16, or a VPN link as
`recited in claims 6 and 21, requires a direct connection under a broadest
`reasonable construction of the terms, because Petitioner shows sufficiently
`that the Aventail ExtraNet Server operates similarly to a router, firewall, or
`gateway to a private corporate network, and thereby provides a direct
`connection under reasoning in Cisco. See Pet. 20; Ex. 1009, 72–73; Ex.
`1005 ¶¶ 200–07, 212, 220–26. Further, the record, which includes some
`related prosecution history and district court litigation, and the ’705 patent
`Specification, fails to illuminate a clear interpretation of what a “direct”
`connection requires. If a direct requirement becomes a dispositive issue
`with respect to Aventail, Patent Owner will have an opportunity to clarify
`the record in its Patent Owner Response.6
`
`
`6 With respect to a reexamination proceeding cited by Patent Owner, the
`examiner confirmed claims 1, 3, 4, 6–10, 12, and 18 in related U.S. Patent
`No. 6,502,135 over Aventail, because Aventail was not shown to be prior
`art. See PO Resp. 38 (citing Ex. 2011, 7); Reexamination Control. No.
`95/002, 269, Right of Appeal Notice, 4 (Oct. 29, 2010). Prior to that, the
`examiner found that Aventail anticipated claims 1, 3, 4, 6–10, 12, and 18.
`See Reexamination Control. No. 95/002, 269, Office Action (Jan. 15, 2010).
`In the district court litigation cited by Patent Owner, notwithstanding the
`district court’s findings, Patent Owner argued that it did not make a clear
`
`
`
`19
`
`

`
`IPR2015-00871
`Patent 8,560,705 B2
`
`
`6. Remaining Limitations in Claims 1 and 16, and Challenged
`D