throbber
Trials@uspto.gov
`Tel: 571-272-7822
`
`
`Paper 80
`Entered: Sept. 9, 2016
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`THE MANGROVE PARTNERS MASTER FUND, LTD., APPLE INC.,
`and BLACK SWAMP IP, LLC,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`____________
`
`Case IPR2015-010471
`Patent 7,490,151 B2
`____________
`
`Before MICHAEL P. TIERNEY, KARL D. EASTHOM, and
`STEPHEN C. SIU, Administrative Patent Judges.
`
`SIU, Administrative Patent Judge.
`
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and C.F.R. § 42.73
`
`
`The Mangrove Partners Master Fund, Ltd., Apple Inc., and Black
`Swamp IP, LLC (collectively, “Petitioner”) requested inter partes review of
`claims 1, 2, 6–8, and 12–14 of U.S. Patent No. 7,490,151 B2 (“the ’151
`
`
`1 Apple Inc. and Black Swamp IP, LLC, which filed petitioners in IPR2016-
`00063 and IPR2016-00167, respectively, have been joined as Petitioners in
`the instant proceeding.
`
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`patent”). We issued a Decision to institute an inter partes review (Paper 11,
`“Inst. Dec.”) of claims 1, 2, 6–8, and 12–14 of the ’151 patent as
`unpatentable under 35 U.S.C. 102 as anticipated by Kiuchi2 or under 35
`U.S.C. 103(a) over the combination of Kiuchi, RFC 1034,3 and Rescorla4 or
`the combination of Kiuchi and any one of Rescorla or RFC1034. Inst. Dec.
`3, 12; Paper 24 1–2.
`After institution of trial, VirnetX Inc. (“Patent Owner”) filed a Patent
`Owner’s Response (Paper 54 (redacted version), “PO Resp.” and Paper 54
`(non-redacted version)), to which Petitioner replied (Paper 58 (redacted
`version), “Pet. Reply”; Paper 56 (non-redacted version); and Paper 59, “Pet.
`Separate Reply”). Patent Owner and Petitioner also each filed a Motion to
`Exclude, a corresponding Patent Owner’s Opposition to Petitioner’s Motion
`to Exclude and Petitioner’s Opposition to Patent Owner’s Motion to
`Exclude, and corresponding Petitioner’s Reply to Patent Owner’s Opposition
`to Motion to Exclude and Patent Owner’s Reply to Petitioners’ Opposition
`of Motion to Exclude. Papers 64, 66, 68, 69, 70, 71. Patent Owner and
`Petitioner each also filed a Motion to Seal. Paper 47, 57. Oral argument
`was conducted on June 30, 2016. Transcripts of that argument has been
`made of record. Paper 79, “Tr.”; see also Paper 78.
`
`
`2 Takahiro Kiuchi and Shigekoto Kaihara, C-HTTP – The Development of a
`Secure, Closed HTTP-Based Network on the Internet, PROCEEDINGS OF THE
`SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY, IEEE 64-75
`(1996) (Ex. 1002, “Kiuchi”).
`3 P. Mockapetris, Domain names – Concepts and Facilities, Network
`Working Group, Request for Comments: 1034 (1987) (Ex. 1005, “RFC
`1034”).
`4 E. Rescorla and A. Schiffman, The Secure HyperText Transfer Protocol,
`Feb. 1996 (Ex. 1004, “Rescorla”).
`
`2
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`
`We have jurisdiction under 35 U.S.C. § 318(a). After considering the
`evidence and arguments of both parties, and for the reasons set forth below,
`we determine that Petitioner met its burden of showing, by a preponderance
`of the evidence, that claims 1, 2, 6–8, and 12–14 of the ’151 patent are
`unpatentable.
`
`
`RELATED MATTERS
`The ’151 patent is the subject of the following civil actions: (i) Civ.
`Act. No. 6:13-cv-00211-LED (E.D. Tex.), filed February 26, 2013; (ii) Civ.
`Act. No. 6:12-cv-00855-LED (E.D. Tex.), filed November 6, 2012; and (iii)
`Civ. Act. No. 6:10-cv-00417-LED (E.D. Tex.), filed August 11, 2010. Pet.
`1.
`
`The ’151 patent is also the subject of Reexamination Control Nos.
`95/001,697 and 95/001,714. Pet. 2.
`
`
`THE ’151 PATENT (EX. 1001)
`The ’151 patent discloses a system and method for automatic creation
`of a virtual private network (VPN) in response to a domain-name server
`look-up function. Ex. 1001, 36:58–60.
`
`
`ILLUSTRATIVE CLAIM(S)
`Independent claim 1 is representative of the claimed subject matter.
`Claim 1 is reproduced below:
`1.
`A data processing device, comprising memory
`storing a domain name server (DNS) proxy module that
`intercepts DNS requests sent by a client and, for each intercepted
`DNS request, performs the steps of:
`(i)
`determining whether the intercepted DNS request
`corresponds to a secure server;
`
`3
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`
`(ii) when the intercepted DNS request does not
`correspond to a secure server, forwarding the DNS request to a
`DNS function that returns an IP address of a nonsecure computer,
`and
`
`(iii) when the intercepted DNS request corresponds to a
`secure server, automatically initiating an encrypted channel
`between the client and the secure server.
`
`
`OVERVIEW OF PRIOR ART
`Kiuchi
`Kiuchi discloses closed networks (i.e., closed HTTP (Hypertext
`Transfer Protocol)-based network (C-HTTP)) of related institutions on the
`Internet. Ex. 1002, 64. A client and client-side-proxy “asks the C-HTTP
`name server whether it can communicate with the [specified] host” and, if
`“the query is legitimate” and if “the requested server-side proxy is registered
`in the closed network and is permitted to accept the connection,” the “C-
`HTTP name server sends the [requested] IP address.” Ex. 1002, 65. After
`confirmation by the C-HTTP name server “that the specified server-side
`proxy is an appropriate closed network member, a client-side proxy sends a
`request for connection to the server-side proxy, which is encrypted.” Id.
`The server-side proxy “accepts [the] request for connection from [the]
`client-side proxy” (Ex. 1002, 65) and, after the C-HTTP name server
`determines that “the client-side proxy is an appropriate member of the closed
`network,” that “the query is legitimate,” and that “the client-side proxy is
`permitted to access . . . the server-side proxy,” the “C-HTTP name server
`sends the IP address [of the client-side proxy].” Ex. 1002, 66. Upon receipt
`of the IP address, the server-side proxy “authenticates the client-side proxy”
`and sends a connection ID to the client-side proxy. After the client-side
`proxy “accepts and checks” the connection ID, “the connection is
`
`4
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`established,” after which time, the client-side proxy forwards “requests from
`the user agent in encrypted form using C-HTTP format.” Ex. 1002, 66.
`
`
`RFC1034
`RFC 1034 discloses that a “name server may be presented with a
`query” and that the name server may either “pursue[] the query for the client
`at another server” (recursive approach) or “refer[] the client to another server
`and lets the client pursue the query” (iterative approach). Ex. 1005, 4.
`
`
`Rescorla
`Rescorla discloses syntax for securing messages sent using Hypertext
`Transfer Protocol. Ex. 1004, 1.
`
`
`ANALYSIS
`Patentability issues
`As Petitioner explains, Kiuchi discloses, for example, a data
`processing device, comprising memory storing a domain name server (DNS)
`proxy module that intercepts DNS requests sent by a client. See, e.g., Pet.
`25-28; Ex. 1003 at 18, 20–22, 27, 28, 31; Ex. 1002, 64–66. Kiuchi also
`discloses determining whether the intercepted DNS request corresponds to a
`secure server (Pet. 28–29; Ex. 1003, 23, 24, 26; Ex. 1002, 65), when the
`intercepted DNS request does not correspond to a secure server, forwarding
`the DNS request to a DNS function that returns a IP address of a nonsecure
`computer (Pet. 29–30; Ex. 1003, 23; Ex. 1002, 65), and when the intercepted
`DNS request corresponds to a secure server, automatically initiating an
`encrypted channel between the client and the secure server (Pet. 30–32; Ex.
`1003 23–25, 28–31; Ex. 1002, 64–66).
`
`5
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`
`
`
`
`DNS Features
`Patent Owner argues that “Kiuchi does not disclose the recited DNS
`features” (PO Resp. 13) because “Kiuchi repeatedly differentiates its C-
`HTTP features from DNS.” PO Resp. 14 (citing Ex. 2038 41–42).
`Claim 1 recites a DNS request. The DNS request is “sent by a client,”
`potentially “corresponds to a secure server,” and may result in any one of a
`return of an IP address of a nonsecure computer or the initiation of an
`encrypted channel between the client and the secure server. Claim 1 does
`not appear to recite any other specific features of the DNS request.
`As Petitioner explains, Kiuchi discloses the “client-side proxy asks the
`C-HTTP name server whether it can communicate with the host specified in
`a given URL,” that the C-HTTP name server “examines whether the
`requested server-side proxy . . . is permitted to accept the connection from
`the client-side proxy,” and if so, “sends the IP address . . . of the server-side
`proxy.” Ex. 1002 65; Pet. 29.
`Patent Owner argues that the “request” of Kiuchi differs from the
`claimed “DNS request” because “Kiuchi explains that the C-HTTP name
`service is used ‘instead of DNS.’” PO Resp. 14. As Patent Owner points
`out, Kiuchi discloses that “[i]n a C-HTTP-based network” a “C-HTTP-based
`secure, encrypted name and certification service is used” “instead of DNS.”
`Ex. 1002, 64, Abstract. However, other than what is tantamount to a mere
`difference in nomenclature, Patent Owner does not point out specific
`differences between the “request” of Kiuchi and the “request” as claimed.
`As discussed above, Kiuchi discloses a “request” from a user agent (i.e.,
`“client”) that requests an IP address corresponding to a domain name with
`
`6
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`subsequent formation of an encrypted channel (i.e., secure communication
`link) between the user agent (i.e., “client”) and origin server (i.e., “the secure
`server”), which appears to be the same as the request as claimed with the
`only apparent difference being the use of the descriptor “DNS” recited in
`claim 1. Furthermore, Patent Owner has argued in related proceedings that
`its claimed “secure domain name” “cannot be resolved by a conventional
`domain name service.” See, e.g., Apple Inc. v. Virnetx Inc., IPR2015-00870,
`slip. op. at 22 (PTAB Jan. 25, 2016) (Paper 23) (citing related reexamination
`proceedings advancing the argument) (emphasis added). This further
`obscures what Patent Owner intends to cover by the term “DNS.”
`In addition, we credit testimony of Dr. Fabian Monrose that the claim
`term “domain name service request” “does not limit it to . . . specific RFCs”
`and Dr. Monrose’s observation of the lack of “any analysis as to [a domain
`name service request] being limited or not thereof to a specific RFC.” Ex.
`1036, 104:21-22, 105:18-19; see also Ex. 1036, 106:15-16 (“I haven’t
`provided any analysis that [a request as claimed] must comply with any
`RFC”). During oral argument, in response to a questions asking what a DNS
`requires, Patent Owner declined to define it, generally contending that
`whatever it is, Kiuchi does not disclose it. See Tr. 70:6–12 (“I think one of
`ordinary skill in the art would know that. But clearly when a reference
`specifically tells you it is not using DNS, you don’t even have to go down
`that road,” id. 71:8–9 (processing the DNS request in Patent Owner’s
`invention “might not be conventional”), id. 71:1–74:24, 84:4–24 (“It is still a
`DNS request. . . . whether you want to call it conventional - - non-
`conventional or whatever.”). Hence, we disagree with Patent Owner’s
`implied contention that renaming a request that requests an IP address
`corresponding to a domain name that is capable of requesting access to a
`
`7
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`secure web site (as disclosed by Kiuchi and as recited in claim 1) from
`“DNS request” to “C-HTTP-based . . . service . . . instead of DNS” alone is
`sufficient to create a patentable difference between requests that appear
`identical in all other respects.
`Patent Owner also argues that Kiuchi’s “request” differs from the
`claimed “request” because Kiuchi discloses “that the . . . DNS lookup is
`generated only if an error condition occurs in which C-HTTP connectivity
`fails.” PO Resp. 14. However, claim 1 does not appear to recite any
`specific steps to be performed with respect to an error condition or whether
`connectivity fails (or not) in conjunction with the (non-recited) error
`condition.
`
`Determining whether the DNS request corresponds to a Secure Server
`Petitioner explains that Kiuchi discloses “[t]he C-HTTP name server
`‘determin[es]’ whether the host in the C-HTTP name request sent by the
`client-side proxy is part of the closed network and whether the connection is
`permitted, and if so, returns an IP address and public key.” Pet. Reply. 8
`(citing Ex 1002 65). Hence Petitioner argues that Kiuchi discloses a client
`(i.e., client-side proxy) that sends a request to a domain name server (DNS)
`proxy module (i.e., C-HTTP name server) that returns a corresponding IP
`address. We agree with Petitioner. Ex. 1002, 65.
`Patent Owner argues “Kiuchi does not anticipate claim 1” because “it
`is the C-HTTP name server [of Kiuchi] . . . that examines whether the
`server-side proxy is registered in the closed network” (PO Resp. 17). Hence,
`Patent Owner does not appear to dispute that Kiuchi discloses a C-HTTP
`name server (or domain name server proxy module) that determines whether
`
`8
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`the DNS request corresponds to a secure server, as recited in claim 1, for
`example.
`
`Automatically initiating
`Patent Owner argues that Kiuchi fails to disclose automatically
`initiating an encrypted channel between the client and the secure server, as
`recited in claim 1, “because encryption does not extend to Kiuchi’s user
`agent” and “Kiuchi discourages end-to-end encryption, from a client to a
`target device.” PO Resp. 18. However, claim 1 does not recite “end-to-end
`encryption” or that encryption must extend to the user agent. For at least
`this reason, we are not persuaded by Patent Owner’s argument.
`In any event, as previously discussed, Kiuchi discloses establishing an
`encrypted channel between a client (i.e., “client-side proxy”) and a secure
`server (i.e., “server-side proxy”). Even assuming Patent Owner’s contention
`to be correct that one of skill in the art would have broadly but reasonably
`understood that a channel that is “between [A] and [B]” requires that the
`channel “extend[] from [A] and [B]” such that the channel “should be
`provided all the way from [one component] to [the other component]” (PO
`Resp. Br. 11), we agree that Petitioner has met its burden by a
`preponderance of the evidence that Kiuchi discloses an encrypted channel
`that extends from the client-side proxy (i.e., “client”) and the server-side
`proxy (i.e., “secure server”) or, alternatively, that an encrypted channel is
`“provided all the way from” the client-side proxy (i.e., “client”) to the server
`side proxy (i.e., “secure server”). See e.g., Paper 58 14; Ex. 1002 65-66.
`Patent Owner does not demonstrate persuasively a difference between such a
`channel and the encrypted channel between the client (“client-side proxy”)
`and secure server (“server-side proxy”) of Kiuchi.
`
`9
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`
`Client
`Patent Owner argues that Petitioner relies “on Kiuchi’s client-side
`proxy for the ‘client’ part of the claimed ‘encrypted channel’” but that
`Kiuchi’s client-side proxy cannot be equated with ‘the “client” part of the
`claimed “encrypted channel” because “Petitioner Black Swamp is already
`relying on the client-side proxy for the claimed ‘domain name server (DNS)
`proxy module’.” PO Resp. Br. 19 (citing IPR2016-00167 Pet. 13).
`Petitioner Black Swamp explains that Kiuchi discloses an embodiment in
`which the “client-side proxy asks the C-HTTP name server whether it can
`communicate with the host.” IPR2016-00167 Pet. 20. In other words, in
`this embodiment relied upon by Petitioner and contrary to Patent Owner’s
`assertion, Petitioner equates Kiuchi’s “C-HTTP name server” (and not the
`client-side proxy) with the claimed DNS proxy module. Patent Owner does
`not explain sufficiently a difference between Kiuchi’s client-side proxy and
`the claimed client with respect to this issue.
`Patent Owner also argues that “Kiuchi’s client-side proxy is not a
`user’s computer” because “Kiuchi does not disclose any user associated with
`the client-side proxy.” PO Resp. Br. 20. Hence, Patent Owner disputes
`Petitioner’s mapping of Kiuchi’s client-side proxy to the claimed “client.”
`Pet. Reply. 10–12. We are not persuaded by Patent Owner’s argument.
`Claim 1 recites “client” but does not recite “user’s computer.” To the
`extent that Patent Owner argues that Kiuchi’s client-side proxy is not a
`“client,” as recited in claim 1 and even assuming Patent Owner to be correct
`that a “client,” as recited in claim 1, must be “associated with” a user, we are
`not persuaded by Patent Owner that Kiuchi fails to disclose that the client-
`side proxy is “associated with” a user. For example, Kiuchi discloses that
`
`10
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`users within an institution (e.g., “hospitals and related institutions” – Ex.
`1002 64) are provided with access to “information [that is] shared among”
`institutions in which a “client-side proxy” receives a request for access from
`a user agent. One of skill in the art would have understood that in order for
`a user or “user agent” in an “institution” to provide a request to access
`information, the “user agent” (itself being “associated with” a user) would
`be “associated with” the “client-side proxy” to which the user agent sends a
`request. Otherwise, the user would be unable to send a request to the client-
`side proxy, the client-side proxy not being associated with the user in the
`first place. Hence, even assuming Patent Owner’s proposed definition to be
`correct that a “client” must be “associated with” a user, Patent Owner does
`not demonstrate sufficient differences between a “client-side proxy” of
`Kiuchi that is “associated with” a user (and receives a request from the
`associated user) and the claimed “client” that Patent Owner argues must be
`also be somehow “associated with” a user.
`Patent Owner argues that Kiuchi’s “client-side proxy” is distinct from
`the claimed “client” because, according to Patent Owner, Kiuchi provides
`“separate references to the ‘client’ and ‘client-side proxy.’” PO Resp. Br.
`21. We are not persuaded by Patent Owner’s argument at least because even
`assuming that Kiuchi refers to a “client” and “client-side proxy” separately
`as Patent Owner contends, Patent Owner does not point out sufficient
`differences between the “client-side proxy” of Kiuchi and a “client,” as
`recited in claim 1 for at least the previously stated reasons.
`Patent Owner argues that the Federal Circuit “found ‘evidence that the
`‘client’ of Kiuchi is actually a web browser, a component that is
`distinguishable from the client-side proxy.” PO Resp. 21 (citing VirnetX,
`Inc. v. Cisco Systems, Inc., 767 F.3d 1308, 1324 (Fed. Cir. 2014))).
`
`11
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`Presumably, Patent Owner argues that the “client-side proxy” cannot be
`equated with the “client,” as recited in claim 1, because the Federal Circuit
`held that the “web browser” of Kiuchi must be equated with the claimed
`“client.” We are not persuaded by Patent Owner’s implied argument.
`First, the Federal Circuit held that “the district court did not err in
`denying [Defendant’s] JMOL motion with respect to invalidity” because
`“there was evidence that the ‘client’ of Kiuchi is actually a web browser.”
`Cisco, 767 F.3d at 1324. We disagree with Patent Owner’s implied
`argument that the Federal Circuit held that 1) Kiuchi’s “web browser” must
`be equated with the claimed “client,” 2) Kiuchi’s “client-side proxy” must
`not be equated with the claimed “client,” and 3) Kiuchi’s “web browser”
`(which is supposedly mandated by the Federal Circuit to be exclusively
`equated with the claimed “client”) differs materially from the claimed
`“client” such that Kiuchi fails to disclose a “client.” Rather, the Federal
`Circuit actually held that there was sufficient “evidence” that Kiuchi
`discloses a web browser as a “client” such that the district court did not err
`in denying defendant’s JMOL motion. See id. This holding does not
`address whether Kiuchi’s client-side proxy (which Petitioner equates with
`the claimed “client” in this embodiment) is the same as or is different (and,
`if so, in what way) from the claimed “client.”
`Second, as Patent Owner points out, the district court and the Federal
`Circuit do not construe claim terms under a broadest reasonable
`interpretation standard as we do. PO Resp. Br. 21–22. Hence, even
`assuming that the Federal Circuit held that the claim term “client” must be
`construed a particular way under a claim construction standard other than the
`broadest reasonable standard, Patent Owner does not explain sufficiently
`
`12
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`how this would apply to the present proceedings in which a broadest
`reasonable standard is used.
`Patent Owner argues that despite the differing standards of claim
`construction, the Federal Circuit “has emphasized that the Board
`nevertheless has an ‘obligation to acknowledge that interpretation’ and ‘to
`assess whether it is consistent with the broadest reasonable construction of
`the term.” PO Resp. Br. 21–22 (citing Power Integrations, Inc. v. Lee, 797
`F.3d 1318, 1326 (Fed. Cir 2015)). We acknowledge the district court’s
`construction as being slightly narrower than our construction and as
`involving different evidence, arguments, and standards of proof. See
`Cuozzo Speed Techs., LLC v. Lee, 136 S. Ct. 2131, 2142–2146 (2016).
`Third, as previously discussed, Patent Owner contends that the
`Federal Circuit “found evidence that the ‘client’ of Kiuchi is actually a web
`browser, a component that is distinguishable from the client-side proxy.”
`Hence, the Federal Circuit states that the district court was presented with
`evidence that Kiuchi discloses a web browser that is a client and is not the
`same as the client-side proxy of Kiuchi. In other words, the Federal Circuit
`makes no comment on claim construction at all (under any standard, much
`less a broadest reasonable standard) since the “web browser” and the “client-
`side proxy” are both terms disclosed by Kiuchi and neither term is recited in
`claim 1, for example.
`
`
`Each Intercepted DNS Request
`Patent Owner argues that Kiuchi fails to disclose each step recited in
`claim 1 “for each intercepted DNS request.” PO Resp. Br. 24. As discussed
`above, Petitioner equates Kiuchi’s client-side proxy with the claimed
`
`13
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`“client.” Kiuchi discloses that the “client-side proxy asks the C-HTTP name
`server whether it can communicate with the host specified in a given URL,”
`in response, the C-HTTP name server “examines whether the requested
`server-side proxy is . . . permitted to accept the connection,” and, if so, “the
`C-HTTP name server sends the IP address and public key of the server-side
`proxy [to the client-side proxy]” (Ex. 1002 65), and subsequently, “the
`connection is established.” Ex. 1002 66. Kiuchi does not appear to also
`disclose that this process is not performed. Therefore, we are not persuaded
`by Patent Owner’s argument.
`Hence, Petitioner has met its burden of demonstrating by a
`preponderance of the evidence that claim 1 is unpatentable.
`
`
`
`Claims 2, 6–8, and 12–14
`Claim 2 recites determining whether the client is authorized to access
`the secure server. Patent Owner argues that Kiuchi only discloses “checking
`whether” a server “is registered in the network” but fails to disclose
`determining whether a client is “authorized” to access the secure server, as
`recited in claim 2, because “whether the server-side proxy [of Kiuchi] is
`permitted to connect says nothing as to the client computer’s authorization.”
`PO Resp. 26. However, Patent Owner does not assert or demonstrate
`sufficiently a difference between 1) determining if a device is “permitted” to
`connect (as disclosed by Kiuchi) and establishing a connection between a
`client and the server only if the device is determined to be “permitted” to
`connect and 2) determining if the client is “authorized” to access the secure
`server. One of skill in the art would have understood that a client that is
`determined to be “permitted to connect” also would be determined to be
`
`14
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`“authorized” to do so. Otherwise, the client would not be permitted to
`connect with the server, which would be contrary to the determination that
`the device is “permitted to connect.”
`Patent Owner does not provide additional arguments in support of
`claims 6–8 and 12–14 with respect to Kiuchi. PO Resp. Br. 25–26. As
`such, on this record, Petitioner has met its burden of demonstrating by at
`least a preponderance of the evidence that claims 2, 6–8 and 12–14 are
`unpatentable.
`
`Obviousness - Kiuchi and Rescorla and/or RFC 1034
`Patent Owner argues that Rescorla or RFC 1034 “do not remedy the
`deficiencies of Kiuchi.” PO Resp. Br. 28. However, as previously discussed
`and taking Patent Owner’s arguments into consideration, Petitioner has met
`its burden by demonstrating by at least a preponderance of the evidence that
`the disputed claims are unpatentable over Kiuchi. As such, no
`“deficiencies” of Kiuchi are identified. Therefore, we are not persuaded by
`Patent Owner’s argument.
`In any event, Petitioner relies upon Rescorla only to the extent that
`Kiuchi fails to disclose or suggest automatically initiating (or creating) a
`secure channel between a client and secure server or a secure channel
`“between” a client and a secure server. Pet 37–38. As discussed above, we
`agree with Petitioner that Petitioner has met its burden by demonstrating by
`at least a preponderance of the evidence that Kiuchi discloses these features.
`Petitioner relies upon RFC 1034 only in the event that the issue of
`whether Kiuchi only discloses “the allegedly ‘wrong’ network entity within
`Kiuchi’s architecture has responsibility for a given task” is raised. We do
`not identify an alleged “wrong” network entity performing a “responsibility
`
`15
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`for a given task.” At least for this additional reason, we are not persuaded
`by Patent Owner’s argument.
`Patent Owner also argues that it would not have been obvious to one
`of ordinary skill in the art to have combined the teachings of Kiuchi with
`any one or both of Rescorla and/or RFC1034 because there was a “long-felt
`need” for “ways to easily and conveniently establish secure communication
`links, such as VPN communication links,” “others attempted to create easy-
`to-enable secure communications [but] failed,” “the technology was . . . met
`with skepticism,” “the claimed inventions have experienced commercial
`success, with multiple companies licensing the technology,” and “[t]hose in
`the industry have also praised the inventions.” PO Resp. 29, 31, 32, 33, 34.
`Hence, Patent Owner argues secondary considerations to rebut the prima
`facie showing of obviousness.
`
`Long Felt Need
`Patent Owner argues that “[p]rior to the claimed inventions, it was
`widely recognized that providing secure remote access to a LAN or WAN
`was extremely difficult for IT support desks” and that the claimed invention
`“combine[s] both the ease of use and the security aspects of a VPN, without
`sacrificing one or the other . . . by automatically initiating an encrypted
`channel between a client and a secure server through a DNS process as
`claimed.” PO Resp. 29 (citing Ex. 2050, 8, 9, 11, 131-132).
`Based on the evidence of record, we are not persuaded by Patent
`Owner’s argument that “it was widely recognized that providing secure
`remote access . . . was extremely difficult.” Rather, Patent Owner’s
`evidence indicate that “[r]emote access . . . [is] insecure and unreliable” but
`that “[y]ou can solve the security problem using client-to-LAN virtual
`
`16
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`private network (VPN) technology.” Ex. 2050 ¶ 8 (citing Ex. B-4 at 1).
`Hence, rather than being “extremely difficult” to provide secure remote
`access, as Patent Owner alleges, Patent Owner’s declarant (Dr. Robert
`Dunham Hosrt III) points out that, in fact, it was known in the art that any
`security problems associated with remote access could be solved. Hence,
`solutions were known in the art that provided secure remote access. On this
`record, however, Patent Owner fails to demonstrate with specific and
`credible evidence that such solutions were “extremely difficult” to
`implement (see e.g., Ex. B-4 at 1) prior to the filing of the ’151 patent.
`Also, Patent Owner argues that there was a long felt need to combine
`both the ease of use and the security aspects of a VPN by automatically
`initiating an encrypted channel between a client and a secure server. As
`discussed above, Kiuchi predates the filing of the ’151 patent and also
`discloses this feature. Patent Owner does not explain how the claimed
`invention satisfies this alleged “long felt need” of providing secure remote
`access when Kiuchi, at least, already provided for secure remote access.
`Patent Owner also argues that “the Defense Advanced Research
`Projects Agency (‘DARPA’) funded various research programs to . . .
`provide easy-to-initiate secure communication links” and that “SAIC also
`spent significant resources of its own on their development [of “cutting edge
`technology].” PO Resp. 31. Patent Owner does not explain sufficiently how
`the amount of resources spent by either “DARPA” or “SAIC” for various
`research programs to further “information assurance and survivability” or
`“cutting edge technology” demonstrates a long felt need for the claimed
`invention. We are not persuaded by Patent Owner’s argument.
`
`Failure of Others
`
`17
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`
`Patent Owner argues that “Dynamic Coalitions,’ was specifically
`created to address the ability of the Department of Defense to quickly and
`easily set up secure communications over the Internet” but that “none of [the
`organizations operating under “Dynamic Coalitions”] came up with a
`solution . . . that was even close to providing the ease of use of the solutions
`provided in the claimed inventions of the ’151 patent.” PO Resp. 31-32
`(citing Ex. 2050, 4-5, 10, 11).
`We are cautioned by the Federal Circuit that, with respect to
`secondary considerations alleged by Patent Owner in response to a prima
`facie showing of obviousness, “the obviousness inquiry centers on whether
`‘the claimed invention as a whole’ would have been obvious.” WBIP, LLC
`v. Kohler Co., Appeal Nos. 2015-1038, 2015-1044, slip op. at 15 (Fed. Cir.,
`July 19, 2016). Looking at the “claimed invention as a whole,” we note that
`claim 1, for example, recites a data processing device that determines
`whether an intercepted DNS request corresponds to a secure server, forwards
`the DNS request to a DNS function that returns an IP address of a nonsecure
`computer (when the intercepted DNS request does not correspond to a
`secure server), and automatically initiating an encrypted channel between
`the client and the secure server when the intercepted DNS request
`corresponds to a secure server. As previously discussed in the record,
`Kiuchi discloses these features, either taken separately or as a “whole.”
`Patent Owner does not indicate a portion of the “whole” of the claimed
`invention that Kiuchi supposedly does not disclose. Not having identified
`sufficiently a part of the “whole” of the claimed invention that Kiuchi does
`not disclose, we conclude that Kiuchi discloses the “whole” of the claimed
`invention. Therefore, Patent Owner fails to show a nexus to its evidence of
`secondary considerations.
`
`18
`
`

`
`IPR2015-01047
`Patent 7,490,151 B2
`
`
`While Patent Owner argues that DARPA-sponsored entities were
`supposedly unable to provide “the ease of use of the solutions provided in
`the claimed inventions of the ’151 patent,” Patent Owner does not
`demonstrate persuasively and with credible evidence that Kiuchi, for
`example, was also unable to provide “the ease of use of the solutions
`provided in the claimed inventions of the ’151 patent.” As previously
`discussed, Kiuchi appears to have succeeded in providing such solutions.
`
`Skepticism
`Patent Owner argues that “a DARPA program manager informed one
`of the co-inventor

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