Trials@uspto.gov
`571-272-7822
`
` Paper No. 8
`Entered: September 11, 2015
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`____________
`
`Case IPR2015-00811
`Patent 8,868,705 B2
`____________
`
`
`
`Before KARL D. EASTHOM, JENNIFER S. BISK, and
`GREGG I. ANDERSON, Administrative Patent Judges.
`
`ANDERSON, Administrative Patent Judge.
`
`DECISION
`
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`

`
`IPR2015-00811
`Patent 8,868,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–34 of
`
`U.S. Patent No. 8,868,705 B2 (Ex. 1001, “the ’705 patent”). VirnetX Inc.
`
`(“Patent Owner”)1 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–34 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.2 Patent Owner has asserted the ’705
`
`patent, or patents in the same family as the application, which resulted in the
`
`’705 patent, against Petitioner in four different lawsuits. Paper 5, 12–13.3
`
`
`1 The Petition also names Science Application International Corporation as
`Patent Owner. However, the Patent Owner Preliminary Response names
`only VirnetX.
`2 Petitioner is advised that its failure to identify any judicial or all
`administrative matters relating to the ’705 patent which would affect or be
`affected by a decision here may be considered a violation of 37 C.F.R.
`§ 42.8. See Pet. 2.
`3 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, general
`statements such as this may be considered a violation of 37 C.F.R. § 42.8.
`See Paper 5, 12–13.
`
`
`
`
`2
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`
`Petitioner also filed another petition seeking inter partes review of the
`
`’705 patent—IPR2015-00810 (“the ’810 IPR”). Pet. 2.4 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.
`
`B. The ’705 Patent
`
`The ’705 patent describes a system and method for transparently
`
`creating an encrypted communications channel between a client device and a
`
`target device. Ex. 1001, Abstract, Figs. 26, 27 (elements 2601, 2604).
`
`Secure communication is based on a protocol called the “Tunneled Agile
`
`Routing Protocol” or “TARP.” Id. at 3:16–19. Once the encrypted
`
`communications channel is created, the devices are configured to allow
`
`encrypted communications between themselves over the encrypted
`
`communications channel. Id. at 40:65–41:9.
`
`
`4 Again, Petitioner potentially failed to meet its obligation under 37 C.F.R.
`§ 42.8. There are numerous other proceedings regarding related patents
`which may be affected by the decision in this proceeding which are not
`listed in the Petition. See Paper 5.
`
`
`
`3
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`
`Figure 26 is reproduced below.
`
`
`
`Referring to Figure 26, user’s computer 2601 is a conventional client, e.g., a
`
`web browser. Ex. 1001, 39:58–60. Gatekeeper server 2603 is interposed
`
`between modified Domain Name Server (“DNS”) 2602 and secure target
`
`site 2604. Id. at 39:62–66. The DNS includes both conventional DNS
`
`server function 2609 and DNS proxy 2610. Id. Conventional IP protocols
`
`allow access to unsecure target site 2611. Id. at 39:66–67.
`
`In one described embodiment, establishing the encrypted
`
`communications channel includes intercepting from the client device a
`
`request to look up an Internet Protocol (IP) address corresponding to a
`
`domain name associated with the target device. Ex. 1001, 40:1–19. It
`
`further includes determining whether the request to look up the IP address
`
`corresponds to a device that accepts an encrypted channel connection with
`
`
`
`4
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`the client device. Id. at 40:1–29. Gatekeeper 2603 facilitates and allocates
`
`the exchange of information for secure communication, such as using
`
`“hopped” IP addresses. Id. at 40:32–35.
`
`The DNS proxy server handles requests for DNS look-up for secure
`
`hosts. Ex. 1001, 40:43–45. If the host is secure, then it is determined
`
`whether the user is authorized to connect with the host. Id. at 40:51–53. If
`
`the user is authorized to connect, a secure Virtual Private Network (VPN) is
`
`established between the user’s computer and the secure target site. Id. at
`
`40:65–41:2.
`
`C. Illustrative Claim
`
`Petitioner challenges claims 1–34 of the ’705 patent. Claim 1 is an
`
`independent method claim and claim 21 is an independent system claim. All
`
`remaining claims depend directly or indirectly from claim 1 or 21. Claim 1
`
`is reproduced below.
`
`transparently creating an encrypted
` A method of
`1.
`communications channel between a client device and a target
`device, each device being configured to allow secure data
`communications between the client device and the target device
`over the encrypted communications channel once the encrypted
`communications channel is created, the method comprising:
`(1) intercepting from the client device a request to look up
`an Internet Protocol (IP) address corresponding to a domain
`name associated with the target device;
`(2) determining whether the request to look up the IP
`address transmitted5 in step (1) corresponds to a device that
`
`
`5 Patent Owner asserts “transmitted” was printed in error and that the
`limitation was amended to include “intercepted” instead of “transmitted.”
`Prelim. Resp. 30, n.3 (citing Ex. 1002, 638–639, 641, 655–656). Patent
`Owner represents the error will be corrected after this decision. Id.
`Petitioner uses the printed version, i.e., “transmitted.” Pet. 29, 35. The
`
`
`
`5
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`
`accepts an encrypted channel connection with the client device;
`and
`(3) in response to deterring in step (2), that the request to
`look up the IP address in step (2) corresponds to a device that
`accepts an encrypted communications channel connection with
`the client device, providing provisioning information required
`to initiate the creation of the encrypted communications channel
`between the client device and the target device such that the
`encrypted communications channel supports secure data
`communications transmitted between the two devices, the client
`device being a device at which a user accesses the encrypted
`communications channel.
`
`Ex. 1001, 55:43–67.
`
`D. References relied upon
`
`Petitioner relies on the following references. Pet. 2–3, Attachment B.
`
`Reference
`
`Description
`
`Aventail
`Connect
`
`Aventail Connect
`v3.01/v2.51
`Administrator’s Guide (see
`note 6)
`RFC 2401 S. Kent and Randall
`Atkinson, RFC 2401,
`Security Architecture for
`the Internet Protocol,
`Standards Track
`US 5,237,566
`
`Brand
`
`Publication or
`Issue Date
`1996–1999
`
`Exhibit No.
`
`Ex. 1009–
`10116
`
`Nov. 1998
`
`Ex. 1008
`
`Aug. 17, 1993 Ex. 1012
`
`
`difference in language is not dispositive of any argument made by either
`party at this stage of the proceedings.
`6 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 Administrator’s Guide (“Aventail
`Administrator Guide,” Ex. 1009), Aventail Connect v3.01/v2.51 User’s
`Guide (1996-1999)(Exhibit 1010), and Aventail ExtraNet Center v3.0
`Administrator’s Guide (NT and UNIX)(Exhibit 1011).
`
`
`
`6
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`
`Reference
`
`Description
`
`RFC 2543 Handley, M., et al., SIP:
`Session Initiation Protocol
`
`
`Publication or
`Issue Date
`March 1999
`
`Exhibit No.
`
`Ex. 1013
`
`E. Asserted grounds of unpatentability
`
`Petitioner challenges claims 1–34 of the ’705 patent as unpatentable
`
`on the following grounds. Pet. 2–3, 27–60.
`
`References
`Aventail Connect and RFC 2401
`
`Aventail Connect, RFC 2401, and
`RFC 2543
`Aventail Connect, RFC 2401, and
`Brand
`Aventail Connect, RFC 2401, RFC
`2543, and Brand
`
`Claims Challenged
`Basis
`§ 103(a) 1–3, 6, 14, 16–25, 28,
`31, 33–34
`§ 103(a) 8–10, 12, 15, 30, 32
`
`§ 103(a) 4, 5, 7, 26, 27, 29
`
`§ 103(a) 11, 13
`
`A. Claim Construction
`
`II. ANALYSIS
`
`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), reh’g en banc
`
`denied, 2015 WL 4100060 (Fed. Cir. July 8, 2015); see also Office Patent
`
`Trial Practice Guide, 77 Fed. Reg. 48756, 48766 (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
`
`
`
`7
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`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).
`
`Petitioner and Patent Owner each proffer proposed constructions of
`
`several claim terms. Patent Owner disputes that the term “provisioning
`
`information,” as it appears in claims 1, 9, and 21, is found in Aventail
`
`Connect under Petitioner’s proposed construction. At this stage of the
`
`proceeding, neither party has identified any other term for construction that
`
`is dispositive on any of the challenges. For the purposes of this Decision,
`
`and on this record, we determine that only the term “provisioning
`
`information” requires interpretation.
`
`The term “provisioning information” is not defined explicitly in the
`
`’705 patent. Petitioner proposes we construe “provisioning information” as
`
`“information that enables communication in a virtual private network, where
`
`the virtual private network uses encryption.” Pet. 11–13 (citing Ex. 1005
`
`¶ 76). In support of its position, Petitioner notes that in IPR2014-00481,
`
`whose claims recite provisioning information for a “virtual private network”
`
`rather than “encrypted communications channel,” the Board interpreted
`
`“provisioning information” as “information that is provided to enable or to
`
`aid in establishing communications to occur in the VPN.” Apple Inc. v.
`
`VirnetX Inc., IPR2014-00481, slip op. at 11 (Sept. 3, 2014)(Paper 11).
`
`Petitioner adopts the construction from IPR2014-00481 and adds “where the
`
`virtual private network uses encryption.” Pet. 13.
`
`
`
`8
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`
`Patent Owner proposes the following construction: “information that
`
`is used to establish an encrypted communications channel.” Prelim. Resp.
`
`38–40. Patent Owner notes that “virtual private network” is not a part of the
`
`claims. Id. at 40. Patent Owner cites to a computer dictionary that defines
`
`provisioning as “[s]etting up a telecommunications service for a particular
`
`customer,” and that “[c]ommon carriers provision circuits by programming
`
`their computers to switch customer lines into the appropriate networks.” Id.
`
`at 38–39 (citing McGraw-Hill Computer Desktop Encyclopedia (9th ed.
`
`2001)(Ex. 2007)).
`
`The claims do not recite or implicate in any way explicitly a VPN.
`
`This case differs from IPR2014-00481 in that respect. Further, nothing in
`
`the Specification limits the claimed invention to a VPN and VPN is not
`
`mentioned in the context of provisioning. Indeed, the Internet generally is
`
`identified as the network upon which the invention is employed. See Ex.
`
`1001, 8:16–17 (describing the Fig. 2). The claims recite, in pertinent part,
`
`an “encrypted communications channel . . . to allow secure data
`
`communications.” Ex. 1001, 55:43–46. Accordingly, applying the broadest
`
`reasonable interpretation, we construe “provisioning information” to mean
`
`“information that is provided to enable or to aid in establishing a secure
`
`communications channel.”
`
`B. The ’810 IPR
`
`Patent Owner argues the present case is redundant with the ’810 IPR
`
`and we should deny institution on that basis. Prelim. Resp. 6–10. In the
`
`instant case “Petitioner challenges claims 1–3, 6, 14, 16–25, 28, 31, and 33–
`
`34 of the ’705 patent as obvious over Aventail in view of RFC 2401, and
`
`claims 4, 5, 7, 26, 27, and 29 as obvious over Aventail, RFC 2401, and
`
`
`
`9
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`Brand.” Id. at 6–7. Patent Owner argues the petition in the ’810 case
`
`proposes all but the same grounds, “simply substitut[ing] Aventail with
`
`Beser, alleging that claims 1–4, 6, 8–26, and 28–34 are obvious over
`
`Aventail in view of RFC 2401, and that claims 5, 7,7 and 27 are obvious over
`
`Beser, RFC 2401, and Brand.” Id. at 7.
`
`Although the grounds asserted here are similar to those asserted in the
`
`’810 IPR, they are not the same. Given the lack of overlap between the
`
`references asserted and the claims against which the references are asserted,
`
`we decline to exercise our discretion under 35 U.S.C. § 325(d) to reject this
`
`Petition as related to “the same or substantially the same prior art or
`
`arguments” as presented in the ’810 IPR.
`
`C. Prior Art Printed Publication Status of RFC 2401
`
`Patent Owner asserts that Petitioner “does not provide evidence to
`
`establish that RFC 2401 would have been sufficiently accessible to the
`
`public interested in the art” on November 1998, the date recited on each of
`
`its pages. Prelim. Resp. 2–3. According to Patent Owner, Petitioner fails to
`
`show that RFC 2401 constitutes a prior art printed publication and is
`
`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
`
`
`7 In the ’810 IPR, though claim 7 is listed as part of the referenced ground
`under the “Identification of Claims Being Challenged,” the petition argues
`claim 11 instead. The ’810 IPR, Pet. 3, 51–52 (Paper 1).
`
`
`
`10
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`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 argument regarding RFC 2401. On its face,
`
`however, RFC 2401 is a dated “Request for Comments” from the “Network
`
`Working Group,” discussing a particular standardized security protocol for
`
`the Internet. Ex. 1008. Moreover, RFC 2401 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.” Id. at 1; see
`
`also Ex. 1005 ¶¶ 148–155 (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,8 we are persuaded that Petitioner has made a threshold
`
`showing that RFC 2401 constitutes a prior art printed publication.
`
`Accordingly, we consider the disclosure of RFC 2401 for the purposes of
`
`this decision.
`
`D. Failure to Allege With Particularity
`
`Patent Owner alleges certain parts of the Petition relating to
`
`“provisioning information” and “intercepting” fail to meet the particularity
`
`requirement of 35 U.S.C. § 312(a)(3) and 37 C.F.R. § 42.104(b)(4). Prelim.
`
`
`8 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 is a “printed publication,” it will have the opportunity to
`make this argument in its Patent Owner Response.
`
`
`
`
`11
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`Resp. 22–23. Patent Owner states that giving multiple examples to meet the
`
`limitations in question does not sufficiently identify with particularity in
`
`accordance with the rules. Id. at 22. Patent Owner also raises the issue with
`
`respect to step (3) of independent claim 1, and the alleged failure to show “in
`
`response to determining, in step (2).” Id. at 23.
`
`We are not persuaded that showing multiple instances of where an
`
`element is found in the cited prior art is a failure to adhere to Rule 104.
`
`Indeed, the more examples provided do not show a weakness in the Petition
`
`as Patent Owner alleges, but rather show the breadth of the disclosure of the
`
`particular limitation in the cited reference. As to alleged failure to show step
`
`(3) of independent claim 1, Petitioner does explain that Aventail Connect
`
`discloses “after determining whether the domain name lookup request
`
`corresponds to a remote host that requires an encrypted connection, a
`
`sequence of steps would establish the required connection between the client
`
`computer and remote host.” Pet. 35 (citing Ex. 1009, 6–8, 11–12, 30, 68–69,
`
`72–73, 90–101; Ex. 1005 ¶¶ 238–254)(emphasis added). This explanation is
`
`sufficient to meet the broadest reasonable interpretation of “in response to.”
`
`E. Analysis of Obviousness Grounds Based on
` Aventail Connect and RFC 2401
`
`Petitioner alleges claims 1–3, 6, 14, 16–25, 28, 31, and 33–34 would
`
`have been obvious over Aventail Connect and RFC 2401. Pet. 27–51.
`
`Petitioner’s evidence includes the Declaration of Roberto Tamassia
`
`(“Tamassia Declaration,” Ex. 1005), which describes Aventail Connect and
`
`RFC 2401. Ex. 1005 ¶¶ 160–273, 346–382.
`
`
`
`12
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`
`1. Aventail Connect
`
`Petitioner alleges Exhibits 1009–1011 are documentation for software,
`
`i.e., Aventail Connect, that were distributed together. Pet. 15–17 (citing
`
`Exs. 1022, 1023, 1043).9 The Tamassia Declaration describes the Aventail
`
`Connect documentation in the context of the Aventail Administrator Guide
`
`(Ex. 1009). Ex. 1005 ¶ 145. Patent Owner also relies on Exhibit 1009 for
`
`the description of Aventail Connect. Prelim. Resp. 12–15. Accordingly, we
`
`cite to Exhibit 1009 for its description of Aventail Connect.
`
`Aventail Connect is the client component of the Aventail ExtraNet
`
`Center. Ex. 1009, 7. Aventail Connect can be used in a network as a simple
`
`proxy client for managed outbound access, and for secure inbound access.
`
`Id. Aventail Connect is an application between WinSock and the underlying
`
`TCP/IP stack. Id. at 9. Aventail Connect can compress or encrypt data
`
`before routing to the network. Id. The routing is determined by rules
`
`described in the configuration file. Id.
`
`In a first step, Aventail Connect does a DNS lookup to convert the
`
`hostname to an IP address. Ex. 1009, 11. If the application knows the
`
`domain is one to which traffic is being proxied, a false DNS is created that
`
`can later be recognized during a connection request. Id. If a DNS proxy
`
`option is enabled, but the domain cannot be looked up, the application again
`
`creates a false DNS entry that it can recognize later, and returns this to the
`
`
`9 The exhibits are from inter partes reexamination 95/001697 requesting
`reexamination of US Patent 7,490,151, but do relate to the Aventail Connect
`documents. (Declaration of James Chester Under 37 C.F.R. § 1.132 (Ex.
`1022); Declaration of Chris A. Hopen Under 37 C.F.R. § 1.132 (Ex. 1023);
`and Declaration of Michael Allyn Fratto Under 37 C.F.R. § 1.132 (Ex.
`1043). At this stage of the proceedings, Patent Owner does not dispute that
`Aventail Connect is prior art to the ’705 patent.
`
`
`
`13
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`calling application. Id. at 12. The false entry tells Aventail Connect that the
`
`DNS lookup must be proxied, and that it must send the fully qualified
`
`hostname directly with the connection request. Id.
`
`In a second step, Aventail Connect requests a connection to the
`
`remote host. Ex. 1009, 12. The request is first checked to see if it contains a
`
`false DNS entry, as per the first step. Id. If a false DNS entry is present, the
`
`request is proxied. Id. If a routable IP address is present, the configuration
`
`file does not require it to be proxied, and there is no false DNS entry,
`
`WinSock application begins the TCP handshake. Id.
`
`Once the WinSock negotiation is completed, in a third step, the
`
`application transmits and receives data. Id. at 12. An encryption and
`
`decryption module can be selected. Id.
`
`2. 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 21
`
`The preamble of claim 1,10 recites, in pertinent part, “creating an
`
`encrypted communications channel between a client device and a target
`
`device.” Petitioner argues that Aventail Connect discloses a “scheme for
`
`creating private communication and data channels over the Internet”
`
`between “client computers (‘client devices’) and remote hosts (‘target
`
`device[s]’).” Pet. 29 (citing Ex. 1009, 12, 91–92). Petitioner also alleges
`
`
`10 Petitioner proceeds on the basis that the preamble is limiting and we agree.
`Unless otherwise noted, we address method claim 1. Petitioner contends
`claim 21 includes the same “operative limitations” as claim 1. Pet. 29.
`Patent Owner does not argue to the contrary.
`
`
`
`14
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`Aventail discloses that “Aventail Connect is designed to run transparently. . .
`
`.” Id. (citing Ex 1009, 7; Ex. 1005 ¶ 171).11
`
`Petitioner contends the communication in Aventail Connect can be
`
`encrypted. Pet. 29–30 (citing Ex. 1009, 1, 11–12, 72–73). Petitioner further
`
`argues Aventail Connect discloses “functionality for intercepting connection
`
`requests from the client computer to a remote host, and creating an
`
`encrypted channel between the client computer and the remote host.” Id.
`
`(citing Ex. 1009, 9–12, 73; Ex. 1005 ¶¶ 171–172, 214–216). While
`
`Petitioner contends that Aventail Connect alone discloses the “encrypted
`
`communications channel” of claims 1 and 21, Petitioner also asserts that
`
`encryption would have been obvious based on the combination of Aventail
`
`Connect and RFC 2401, which specifically discloses encryption. Id. at 30,
`
`39–42.
`
`Petitioner also argues that Aventail Connect discloses step (1) of
`
`claim 1, “intercept[ing] . . . a request to look up an [] IP address
`
`corresponding to a domain name associated with the target . . . .” Pet. 31–
`
`33. Petitioner cites Aventail Connect’s disclosure that a “client computer
`
`running Aventail Connect will transparently intercept each connection
`
`request made on the client.” Id. at 31 (citing Ex. 1009, 7–9, 72–73; Ex. 1005
`
`¶¶ 171–172, 209–216). Petitioner cites to Aventail Connect’s disclosure that
`
`to connect to a “Remote Host,” i.e., the recited “target device,” a Domain
`
`Name System (DNS) lookup converts the hostname into an Internet Protocol
`
`(IP) address. Id. (citing Ex. 1009, 8, 11, 91–92; Ex. 1005 ¶ 210). In
`
`
`11 The “system including a memory storage instructions” and “a server
`configuration” specific to system claim 21 are also alleged to be present in
`the RAM and Extranet server of Aventail Connect. Pet. 30–31 (citing Ex.
`1009, 11–13).
`
`
`
`15
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`addition and separate from the preceding, Petitioner cites to Aventail
`
`Connect’s disclosure that all connection requests to the Aventail Extranet
`
`Server contain either the IP address or the domain name of the destination
`
`computer, which are used for handling and resolution. Id. at 32 (citing Ex.
`
`1009, 12, 61, Ex. 1005 ¶¶ 225–228). Petitioner concludes that “[a] person of
`
`ordinary skill would recognize from the teachings in Aventail that, in this
`
`configuration, the Aventail Extranet Server will necessarily perform a name
`
`resolution of the connection request if the request specifies a host name,
`
`rather than an IP address of the target device.” Id. (citing Ex. 1005 ¶ 228).
`
`Step (2) of claim 1 recites “determining whether the request to look up
`
`the IP address transmitted in step (1) corresponds to a device that accepts an
`
`encrypted channel connection with the client device.” Petitioner contends
`
`that Aventail Connect “determines whether or not the connection needs to be
`
`… encrypted.” Pet. 33 (citing Ex. 1009, 10). Petitioner quotes from page 10
`
`of Aventail Connect that when a connection request is received “it
`
`determines whether or not the connection needs to be redirected (to an
`
`Aventail ExtraNet Server) and/or encrypted (in SSL).” Id. at 33–34.
`
`Specifically, Petitioner argues that if Aventail Connect’s table of redirection
`
`rules indicates the request needs to be proxied to the Aventail Extranet
`
`Server for handling, encryption of all communications occurs. Id. at 34
`
`(citing Ex. 1009, 73).
`
`Step (3) of claim 1 recites, in pertinent part, in response to step
`
`(2), “providing provisioning information required to initiate . . . [an]
`
`encrypted communications channel.” Petitioner argues that Aventail
`
`Connect discloses that encryption according to a known encryption
`
`standard, Secure Sockets Layer (SSL). Pet. 35–36 (citing Ex. 1009,
`
`
`
`16
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`12, 73, 110; Ex. 1005 ¶¶ 247–250). The Extranet server, according to
`
`Petitioner, can be configured to send a digital certificate to the client,
`
`which verifies the Extranet server. Id. at 36 (citing Ex. 1009, 47–51);
`
`see also Ex. 1009, 47–51. Petitioner argues the certificate and
`
`selection of the encryption method are each “provisioning
`
`information” as claimed because they are provided for use in
`
`establishing the encrypted link. Id. at 36. Petitioner cites to other
`
`disclosures of Aventail Connect to further support its contention that
`
`step (3) is taught by Aventail Connect. Id. at 36–38.
`
`Petitioner argues separately that the last portion of step (3), “the
`
`client device being a device at which a user accesses the encrypted
`
`communications channel,” is also taught by Aventail Connect. Pet.
`
`38–39. Specifically, Petitioner argues the workstations users of
`
`Aventail Connect access remote hosts using the encrypted connection
`
`described. Id. (citing Ex. 1009, 65).
`
`Petitioner acknowledges that “Aventail does not, however,
`
`expressly describe systems in which encrypted data sent by a client
`
`computer remains encrypted until it is received by the ultimate
`
`destination of that communication (so-called “end-to-end”
`
`encryption).” Pet. 39. Petitioner cites to RFC 2401 in its “Case 4”
`
`example, as teaching a configuration for sending encrypted network
`
`traffic through proxy or firewall computers, such as the Aventail
`
`Connect Extranet Server, without being decrypted, and then being
`
`decrypted remote computer. Id. at 40 (citing Ex. 1005 ¶ 364)(see Ex.
`
`1008, 25–26 (Case 4)).
`
`
`
`17
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`
`Petitioner argues that one of ordinary skill in the art would
`
`combine RFC 2401 with Aventail Connect because Aventail Connect
`
`shows encryption over at least part of the connection path while RFC
`
`2401 shows encryption over the entire connection path. Pet. 41
`
`(citing Ex. 1005 ¶¶ 365–382). Patent Owner does not argue to the
`
`contrary. On the record before us, we are persuaded that Petitioner
`
`has provided sufficiently an articulated reasoning with some rational
`
`underpinning to support the legal conclusion of obviousness. 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)).
`
`Patent Owner argues the “determining” of step (2) is not shown
`
`in the cited portions of Aventail Connect. Prelim. Resp. 12–18.
`
`Patent Owner argues as follows:
`
`First, a domain name is never specified in the connection
`request. Second, the mere inclusion of the remote host in the
`redirection table does not mean that the remote host will accept
`any encrypted connection because, as even Petitioner admits,
`Aventail does not teach an encrypted connection to the remote
`host.
`
`Prelim. Resp. 12. Patent Owner argues that, contrary to Petitioner’s
`
`position, the redirection rule table in Aventail Connect does not
`
`“determine if the remote host will accept an encrypted connection.”
`
`Id. at 17 (citing Pet. 34). Further, the acceptance of a proxied
`
`connection at the remote host, as shown in Aventail Connect, does not
`
`“suggest that the remote host is one that accepts an encrypted
`
`connection.” Id. at 17–18.
`
`
`
`18
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`
` The “determining” step states “determining whether the request to
`
`look up the IP address transmitted in step (1) corresponds to a device that
`
`accepts an encrypted channel connection with the client device.” All that is
`
`required is that the target device accepts an encrypted communication.
`
`Aventail Connect discloses that the connection request can be proxied and
`
`encrypted. See Pet. 33 (citing Ex. 1009, 73). Further, the Tamassia
`
`Declaration states, after analyzing Aventail Connect in detail, 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)(emphasis added). At this stage of the proceeding, and applying a
`
`reasonable likelihood standard of proof, Petitioner has shown that Aventail
`
`Connect determines whether the remote or target device accepts encrypted
`
`communication.
`
`Patent Owner argues Aventail Connect fails to disclose the claim
`
`limitation “provisioning information,” as Petitioner construes the term.
`
`Prelim. Resp. 20–22. Patent Owner’s related argument is that the Petition
`
`fails to meet the specificity requirement of 35 U.S.C. § 312(a)(3) and 37
`
`C.F.R. § 42.104(b)(4). Id. at 22–23.
`
`Patent Owner concedes that Petitioner cites to instances where
`
`Aventail Connect discloses what Patent Owner contends are “provisioning
`
`information.” Prelim. Resp. 20–21 (citing Pet. 35–38). However, Patent
`
`Owner contends the cited disclosures do not meet Petitioner’s proposed
`
`construction of the term, “information that enables communication in a
`
`virtual private network, where the virtual private network uses
`
`encryption.” Id. at 20 (citing Pet. 11–13). Patent Owner asserts that
`
`
`
`19
`
`

`
`IPR2015-00811
`Patent 8,868,705 B2
`
`Petitioner fails to show the information is “in a virtual private network.”
`
`Given our construction of “provisioning information” above, which excludes
`
`“virtual private network” from the c