`571-272-7822
`
`
`
`
`
`
`
`Paper 39
`Date: Sept. 28, 2016
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`____________
`
`Case IPR2015-00870
`Patent 8,560,705 B2
`____________
`
`
`
`Before KARL D. EASTHOM, JENNIFER S. BISK, and
`GREGG I. ANDERSON, Administrative Patent Judges.
`
`EASTHOM, Administrative Patent Judge.
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`
`
`
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`
`I. INTRODUCTION
`Petitioner, Apple Inc., filed a Petition (Paper 1, “Pet.”) seeking an
`inter partes review of claims 1–30 of U.S. Patent No. 8,560,705 B2 (Ex.
`1050, “the ’705 patent”) pursuant to 35 U.S.C. §§ 311–319. After VirnetX
`Inc., Patent Owner, filed a Preliminary Response (Paper 6), we instituted an
`inter partes review of claims 1–30 (Paper 8, “Institution Decision” or “Inst.
`Dec.”).
`Subsequent to institution, Patent Owner filed a Patent Owner
`Response (Paper 23) (“PO Resp.”), and Petitioner filed a Reply (Paper 26)
`(“Pet. Reply”). Patent Owner also filed a Motion to Exclude evidence
`(Paper 30), Petitioner filed an Opposition (Paper 33), and Patent Owner filed
`a Reply to the Opposition (Paper 34). Petitioner relies on, inter alia, the
`“Declaration of Roberto Tamassia Regarding U.S. Patent Nos. 8,458,341,
`8,516,131, and 8,560,705.” Ex. 1005 (the “Tamassia Declaration”). Patent
`Owner relies on, inter alia, the “Declaration of Fabian Monrose, Ph.D.” Ex.
`2018 (the “Monrose Declaration”). The Board filed a transcription of the
`Oral Hearing held on June 27, 2016. Paper 38. This Final Written Decision
`issues concurrently with the final written decision involving the ’705 patent
`in Apple Inc. v. VirnetX Inc., IPR2015-00871 (PTAB Sept. 28, 2016) (Paper
`No. 39, “’871 FWD”) (generally “’871 IPR”).
`The Board has jurisdiction under 35 U.S.C. § 6(c). This Final Written
`Decision issues pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73. For
`the reasons that follow, we determine that Petitioner has shown by a
`preponderance of the evidence that claims 1–30 of the ’705 patent are
`unpatentable.
`
`
`2
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`
`A. The ’705 Patent (Ex. 1050)
`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.
`“A modified DNS server 2602 includes a conventional DNS server
`function 2609 and a DNS proxy 2610,” which may be “combined into a
`single server for convenience.” Id. at 39:67–40:2, 40:45–46. The DNS
`proxy of the modified DNS server intercepts all DNS lookup requests,
`determines whether the user has requested access to a secure site (using, for
`example, a domain name extension or an internal table of secure sites), and
`if so, determines 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 security privileges,
`the DNS proxy requests a gatekeeper to create a VPN between the user’s
`computer and the secure target site. Id. at 40:12–16. The DNS proxy then
`
`3
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`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.
`The VPN is “preferably implemented using the IP address
`‘hopping’ features,” (changing IP addresses based upon an agreed
`upon algorithm) described elsewhere in the ’705 patent, “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. The
`system may hide the identities (i.e., anonymity, a form of security) by
`encrypting parts of packets. See id. at 1:50–56, 9:41–10:17. Routers
`along the hopping path determine the “next-hop in a series of . . .
`router hops” (id. at 9:52–53) in the path, by authenticating or
`decrypting transmitted encrypted parts of packets to find the “next-
`hop” router address. See id. at 3:23–25, 10:2–17. Data messages in
`the packets also may be encrypted. See id. at 1:50–56, 4:10–12, 11:1–
`9.
`
`B. Illustrative Challenged 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 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;
`
`4
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`
`(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.
`Ex. 1050, 55:52–65.
`C. Instituted Grounds of Unpatentability
`We instituted on the following grounds asserted by Petitioner under
`35 U.S.C. § 103 for obviousness: claims 1–23 and 25–30 of the ’705 patent
`based on the combination of Beser (Ex. 1007)1 and RFC 2401 (Ex. 1008)2,
`and claim 24 as unpatentable based on the combination of Beser, RFC 2401,
`and Brand (Ex. 1012)3. Inst. Dec. 19.
`D. Claim Construction
`In an inter partes review, the Board construes claim terms in an
`unexpired patent under their broadest reasonable construction in light of the
`specification of the patent in which they appear. Cuozzo Speed Techs., LLC
`v. Lee, 136 S. Ct. 2131, 2144–46 (2016); 37 C.F.R. § 42.100(b). Under this
`standard, absent any special definitions, claim terms or phrases carry 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).
`The Board construed similar claim terms in Apple Inc. v. VirnetX Inc.,
`IPR2014-00237 (PTAB May 11, 2015) (Paper 41) (“’237 final written
`
`
`1 U.S. Patent No. 6,496,867 B1.
`2 S. Kent and R. Atkinson, Security Architecture for the Internet Protocol,
`Request for Comments: 2401, BBN Corp., November 1998.
`3 U.S. Patent No. 5,237,566.
`
`5
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`decision,” “’237 FWD,” or generally, “’237 IPR”) (on appeal at the Federal
`Circuit) and in Apple Inc. v. VirnetX Inc., IPR2014-00481 (PTAB Aug. 24,
`2015) (Paper 35) (“’481 final written decision,” “’481 FWD,” or generally,
`“’481 IPR”) (on appeal at the Federal Circuit). See also VirnetX, Inc. v.
`Cisco Systems, Inc., 767 F.3d 1308, 1317–19 (Fed. Cir. 2014) (addressing
`ancestor VirnetX patents having similar claim terms).
`1. Interception of a Request––Claims 1 and 16
`In the related ’237 IPR, as Petitioner and Patent Owner note, we
`construed the similar phrase “intercepting a request” as “receiving a request
`pertaining to a first entity at another entity.” ’237 FWD 10–12; PO Resp. 4;
`Pet. 8–10. Quoting Patent Owner in that proceeding, we noted that Patent
`Owner “disagrees with this construction” (’237 PO Resp. 23), but “believes
`that no construction is necessary” (id. at 26), because “it does not appear that
`the construction of ‘intercepting’ will bear on the outcome of the issues in
`this inter partes review” (id. at 23). ’237 FWD 11. The ’237 IPR and this
`proceeding involve the same issue with respect to this term and the asserted
`prior art.
`Patent Owner similarly states in the instant proceeding that “[n]o
`construction [is] necessary.” PO Resp. 4. Nevertheless, as it did in the ’237
`IPR, Patent Owner urges that if we construe the term, then we adopt Patent
`Owner’s construction: “receiving a request to look up an internet protocol
`address and, apart from resolving it into an address, preforming an
`evaluation on it related to establishing a secure communication link.” PO
`Resp. 4; ’237 PO Resp. 23.
`According to Patent Owner’s argument in the ’237 IPR, a disclosed
`modified DNS “appl[ies] an additional layer of functionality to a request to
`
`6
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`look up a network address beyond merely resolving it and returning the
`network address.” Id. at 25. Patent Owner’s arguments here are similar.
`For example, Patent Owner argues that its “alternative construction
`appropriately captures the notion of performing an additional evaluation on a
`request to look up an IP address related to establishing an encrypted
`communications channel, beyond conventionally resolving it and returning
`the address.” PO Resp. 4–5.4
`Both the arguments and record show that Patent Owner’s proposed
`construction adds unnecessary functionality to “intercepting a request” and
`violates the plain language of the claim. According to Patent Owner’s
`arguments, another recited phrase in claim 1 (and a similar phrase in claim
`16), captures the functionality, in particular, the “determination” clause of
`claim 1. See PO Resp. 5 (listing one example function to be incorporated as
`“determin[ing] that a device [] is available for the secure communication
`service”). In other words, the “determination” clause already covers
`functionality that Patent Owner urges is implicit in the intercepting phrase.
`See PO Resp. 4–5; Prelim. Resp. 31–32; ’237 PO Resp. 26, 29–30.
`The parties agree that “interception of a request” (at least) involves
`“receiving a request” at some intermediate device. PO Resp. 4; Pet. 9–10.
`Patent Owner’s proposed construction does not create any distinction
`
`
`4 Patent Owner also maintained in the ’237 IPR that “[t]he Decision’s
`construction addresses a common aspect of a conventional DNS and the
`disclosed embodiments, namely that a request to look up an address of one
`entity may be received at another entity. However, the construction
`overlooks the aspects distinguishing the ‘intercepting’ phrase from
`conventional DNS.” ’237 PO Resp. 26 (emphases added) (internal citation
`omitted).
`
`
`
`7
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`between receiving and intercepting. According to Petitioner’s proposed
`construction, an “interception” by (intermediate) proxy DNS includes
`“receiving” a request to look up an address for another (downstream) entity
`(i.e., the request pertains to that downstream entity). Furthermore, as quoted
`above, Patent Owner agreed in the ’237 IPR that Petitioner’s construction
`captured “the disclosed embodiments.” ’237 PO Resp. 26; supra note 4. In
`essence, Petitioner’s construction captures the notion of interception as
`disclosed in the ’705 patent, by requiring receiving to “pertain” to another
`entity.
`Patent Owner alleges that Dr. Tamassia adopted an “intended for”
`requirement in the “interception” clause. PO Resp. 33–34 & n.3. Patent
`Owner points to a portion of the ’237 IPR institution decision outlining a
`discussion by Dr. Tamassia. See id. at 33 (citing Ex. 1005 ¶ 122) n.3 (citing
`’237 IPR, Paper 15, 12). Petitioner disagrees with any intent requirement,
`and contends that Patent Owner mischaracterizes Dr. Tamassia’s testimony.
`See Pet. Reply 14–15.
`Patent Owner only addresses this “intent” requirement in an attempt to
`distinguish its claims over the prior art, and does not propose it as part of its
`claim construction. See PO Resp. 33–34. Furthermore, any alleged prior
`requirement of “intent” did not survive to the ’237 FWD. Compare ’237
`IPR, Paper 15 (institution decision), 13, with ’237 FWD 10–12. More
`importantly, Patent Owner does not allege or attempt to show that the ’705
`
`8
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`patent supports or requires such “intent” as part of the broadest reasonable
`construction of the interception term. The record does not support it.5
`Based on the foregoing discussion, the record shows that the
`additional functionality urged by Patent Owner should not be imported into
`the intercepting phrase and Petitioner’s construction tracks the claim and
`Specification. Accordingly, consistent with the ’237 FWD, the broadest
`reasonable construction of the term “interception of a request” is “receiving
`a request pertaining to a first entity at another entity.”
`2. Determination, in Response to the Request, Whether
`the Second Network Device is Available for Communication
`In the ’237 FWD, we interpreted the related phrase, “determining, in
`response to the request, whether the second network device is available for
`secure communication,” to mean “determining[, in response to the request,]
`if the second network device is accessible for use, at hand, or usable in a
`system that provides secure communication using that device.” ’237 FWD
`15.
`
`In the ’237 IPR, Patent Owner agreed that focusing on the requester’s
`security level, and by implication, the relative security levels of the requester
`and the device, is not required: The “‘determining’ phrase need not be
`limited to the Decision’s determining ‘permission level or security privileges
`of the requester.’” ’237 FWD 14 (emphasis by Board supplied in the ’237
`IPR) (quoting ’237 PO Resp. 29).
`
`
`
`
`5 Although not part of the claim construction, a requestor may “intend” for
`the entered domain name in a request to reach the target device, but the DNS
`intercepts it to perform the look-up.
`
`9
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`
`The Specification supports this interpretation:
`If access to a secure site has been requested (as determined, for
`example, by a domain name extension, or by reference to an
`internal table of such sites), DNS proxy 2610 determines whether
`the user has sufficient security privileges to access the site.
`Ex. 1050, 40:8–13.
`The first quoted sentence in the passage indicates that determining
`whether a device is “available for a secure communication service” is broad
`enough to mean determining whether the device is listed on a network
`database that a secure network uses to obtain access to secure target devices.
`Therefore, the quoted passage from the Specification, bolstered by Patent
`Owner’s arguments, indicates that determining if a secure device is listed in
`an “internal table” (or similar database/DNS structure) of secure sites is
`sufficient to constitute a determination of availability.
`As part of the disclosed process, the system returns a “resolved
`address” for the target device: “The address that is returned need not be the
`actual address of the destination computer.” Id. at 40:24–25. Furthermore,
`the determination does not require an actual look-up and resolution into an
`IP address to occur. See, e.g., Ex. 1001, 40:6–35 (returning a “host
`unknown” without necessarily looking up an IP address “if a user had
`requested lookup of a secure web site but lacked credentials”).
`Another passage describes a normal DNS “look-up function”:
`For DNS requests that are determined to not require secure
`services
`(e.g., an unregistered user),
`the DNS server
`transparently “passes through” the request to provide a normal
`look-up function and return the IP address of the target web
`server, provided that the requesting host has permissions to
`resolve unsecured sites. Different users who make an identical
`DNS request could be provided with different results.
`
`10
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`Id. at 39:56–63.
`In summary, according to disclosed embodiments in the ’705 patent
`Specification, a device may be determined to be available as a secure device
`that the system provides, for example, by determining that the device is
`listed for use as part of the secure system. According to one of the above
`disclosed examples, which is not limiting, different users may be denied or
`granted access depending on that particular user’s security privileges relative
`to the target’s security level, rendering that device available or unavailable
`to that user.
`Based on the foregoing discussion, according to the ’705 patent
`Specification and the arguments presented, “determination, in response to
`the request, whether a second network device is available for secure
`communication,” means “determination, in response to the request, if the
`second network device is accessible for use, at hand, or usable, in a system
`that provides secure communication using that device.”
`3. Secure Domain Name
`Claims 7 and 22 depend respectively from claims 1 and 16, and
`further specify that the domain name is a “secure domain name.” Relying,
`in part, on a related inter partes proceeding, Petitioner argues “secure
`domain name” is “a name that corresponds to a secure computer network
`address.” Pet. 15 (citing ’481 institution decision, 8; Ex. 1005 ¶ 141)
`(emphasis omitted); accord ’481 FWD 14–14 (same claim construction).6
`
`
`6 As indicated above, we refer to Apple Inc. v. Virnetx, Inc., IPR2014-00481
`(“’481 IPR”), slip. op. at 8 (PTAB Sept. 3, 2014) (Paper 11) (“’481
`institution decision”); see also ’481 IPR, slip op. at 13–14 (PTAB Aug. 24,
`2015) (Paper 35) (“’481 final written decision” or “’481 FWD”).
`
`11
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`Petitioner contends its proposed construction is consistent with the
`Specification. See Pet. 15 (citing Ex. 1050, 51:15–51 (arguing the disclosure
`“describes a ‘secure domain name’ as a domain name that corresponds to the
`secure network address of a secure server 3320”)). Petitioner relies on
`additional Specification disclosure in support of its construction. Id. (citing
`Ex. 1050, 40:6–13).
`Patent Owner acknowledges that the Board adopted Petitioner’s
`proposed construction in the ’481 IPR. PO Resp. 22. However, Patent
`Owner contends that “secure domain name” means “[a] non-standard
`domain name that corresponds to a secure computer network address and
`cannot be resolved by a conventional domain name service (DNS).” Id.
`(Table). Patent Owner argues multiple parties agreed upon its proposed
`construction in a related district court case. Id. (citing Ex. 2015, 19–20)
`(Virnetx Inc. v. Apple Inc., Case 6:10-cv-00417-LED (E.D. Tex., Dec. 21,
`2011) (Joint Claim Construction Chart). Patent Owner also cites to the
`Specification as further supporting its proposal and showing that the “secure
`domain name” is a “nonstandard domain name.” Id. (citing Ex. 1050, 7:29–
`31, 39–42, 50:31–46, 51:15–19, Figs. 33–34; 2018 ¶¶ 36–38). Patent Owner
`also cites the Monrose Declaration. Id. (citing Ex. 2018 ¶¶ 36–38).7 Dr.
`Monrose contends, inter alia (see note 7), that the ’705 patent discloses that
`“[t]o obtain the URL for a ‘secure domain name,’ ‘a secure domain name
`service (SDNS)’ must be queried.” Ex. 2018 ¶ 37 (citing Ex. 1050, 50:44–
`46; Figs. 33, 34).
`
`
`7 The cited portion of the Monrose Declaration lists examples in the ’705
`patent and prosecution history statements from a related patent as support for
`Patent Owner’s construction and mirrors Patent Owner’s arguments.
`
`12
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`
` Patent Owner further contends it disclaimed Petitioner’s proposed
`construction in a now completed inter partes reexamination of a related
`patent. PO Resp. 24 (citing Ex. 2016 (Control No. 95/001,270, U.S. Pat.
`No. 7,188,180, Response to Office Action, Apr. 19, 2010), 5; Ex. 2017
`(Right of Appeal Notice, Dec. 3, 2010), 4). Patent Owner stresses that claim
`construction requires consultation of the prosecution history. Id. at 14–15
`(citing Microsoft Corp. v. Proxyconn, Inc., 789 F.3d 1292, 1298 (Fed. Cir.
`2015); Straight Path IP Grp., Inc. v. Sipnet EU S.R.O., 806 F.3d 1356, 1362
`(Fed. Cir. 2015)). Patent Owner also appears to acknowledge that
`prosecution history disclaimers do not bind the PTO. See id. at 11 (citing
`Tempo Lighting, Inc. v. Tivoli, LLC, 742 F.3d 973, 978 (Fed. Cir. 2014) (The
`“court also observes that the PTO is under no obligation to accept a claim
`construction proffered as a prosecution history disclaimer, which generally
`only binds the patent owner.”)).
`Beginning with the claim language, dependent claims 7 and 22 recite
`that the domain name is a “secure domain name.” Petitioner’s proposed
`construction involves the plain meaning of those words, “a name that
`corresponds to a secure computer network address.” Any construction under
`the broadest reasonable standard should not obscure the clarity of the claim
`language. See Phillips v. AWH Corp., 415 F.3d 1303, 1314 (Fed. Cir. 2005)
`(en banc) (“In some cases, the ordinary meaning of claim language as
`understood by a person of skill in the art may be readily apparent even to lay
`judges, and claim construction in such cases involves little more than the
`application of the widely accepted meaning of commonly understood
`words.”). The Specification may set out a particular meaning of a claim
`term that diverges from its plain meaning so long as it does so “with
`
`13
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`reasonable clarity, deliberateness, and precision.” In re Paulsen, 30 F.3d
`1475, 1480 (Fed. Cir. 1994). “Without an express intent to impart a novel
`meaning to claim terms, an inventor’s claim terms take on their ordinary
`meaning.” York Prods., Inc. v. Central Tractor Farm & Family Ctr., 99
`F.3d 1568, 1572 (Fed. Cir. 1996).
`The ’705 patent describes as an “example,” replacing a standard top-
`level domain name like .com, with “a[n] s.com top-level domain name,
`where the ‘s’ stands for secure.” Ex. 1050, 50:35–38. It describes top-level
`domain alternatives: “Alternatively, software module 3409 can replace the
`top-level domain name of server 3304 with any other non-standard top-level
`domain name.” Id. at 50:38–40. The ’705 patent also states that “[b]ecause
`the secure top-level domain name is a non-standard domain name, a query to
`a standard domain name service (DNS) will return a message indicating that
`the universal resource locator (URL) is unknown.” Id. at 50:41–44
`(emphasis added).
`This latter disclosure about what a standard DNS may or may not
`return applies to the examples of non-standard top-level domain names, but
`Patent Owner does not urge a non-standard top-level domain name in its
`construction. The Specification also does not imply or expressly state that
`all of the disclosed “secure domain names” must include a “top-level”
`domain name, and it implies in other places that secure DNSs can resolve
`secure domain names using internal tables or similar databases––in other
`words, using a conventional look-up process. For example, the Specification
`states that “SDNS 3313 contains a cross-reference data base of secure
`domain names and corresponding secure network addresses. That is, for
`
`14
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`each secure domain name, SDNS 3313 stores a computer network address
`corresponding to the secure domain name.” Id. at 51:15–18.
`As Petitioner contends, this disclosure, and others, imply that a
`“secure domain name” is a domain name that “corresponds to the secure
`network address” for a secure device. See Pet. 15 (citing Ex. 1050, 51:6–
`42). Other disclosures support Petitioner’s broader construction: “An entity
`can register a secure domain name in SDNS 3313 so that a user who desires
`a secure communication link to the website of the entity can automatically
`obtain the secure computer network address for the secure website.” Id. at
`51:19–22. An entity can register “several secure domain names”
`representing a “hierarchy of access,” and “different priority level of access,”
`with fees varying for “a desired level of guarantee” for secure access. Id. at
`51:22–32. Furthermore, in addition to resolving names based on the name
`itself, “SDNS 3313 determines the particular secure computer network
`address based on the user’s identity and the user’s subscription level.” Id. at
`51:34–37.
`Therefore, based on the above-cited disclosures, although some of the
`disclosed examples that Patent Owner relies upon show that a conventional
`DNS does not return a secure address if it has a non-standard top-level
`domain name (e.g., .scom), the Specification in its entirety does not support
`the construction that requires a conventional DNS, or a secure DNS using a
`conventional process, not to return the secure domain names contemplated
`by the invention. The last few disclosures listed in the previous paragraph
`and others indicate that the security address returned does not depend solely
`on the type of secure domain name––it also depends at least partly on the
`user’s identity and/or subscription level. This implies further that a secure
`
`15
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`domain name need not be non-standard, because the resolution of it depends
`on other “non-standard” factors like the user’s identity or security level.
`Similarly, rather than a conventional domain name service not returning a
`secure address based solely on the name, the Specification states that a
`“DNS proxy” returns a “host-unknown” “if the user had requested look[-]up
`of a secure web site but lacked credentials to create such a connection.” Id.
`at 40:30–33 (emphases added). “In this manner, different users requesting
`access to the same [secure] DNS name could be provided with different
`look-up results.” Id. at 40:33–35 (emphasis added).
`According to the passage quoted above in previous Section I.D.2,
`requests for non-secure websites are “passe[d] through” to provide a
`“normal look-up function,” “provided that the requesting host has
`permissions to resolve unsecured sites” (again, so that “[d]ifferent users who
`make identical DNS requests get different results”). Ex. 1050, 39:58–63.
`This latter disclosure, describing a “normal look-up function,” for non-
`secure websites, does not imply or dictate that a request for secure access
`requires an unconventional DNS look-up function. Rather, as noted at the
`outset (Section I.A), and by way of example, the ’705 patent describes “the
`automatic creation of a virtual private network (VPN) in response to a
`domain-name server look-up function.” Ex. 1050, 39:4–6 (emphasis added).
`In one embodiment, “[a] specialized DNS server traps DNS requests” from
`users “for which secure communications are defined” and may return
`“different results” to an “identical DNS request” for setting up a VPN, id. at
`1050, 39:46–49,61–62. Eventually, a DNS proxy returns a “resolved
`address” (passed by a gatekeeper) that may or may not be the “actual
`address.” Id. at 40:21–25. In any case, a DNS proxy “determines “[i]f
`
`16
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`access to a secure site has been requested . . . by a domain name extension or
`by reference to an internal table of such sites.” Id. at 40:10–11.
`In addition to determining if a secure domain name has been
`requested “by reference to an internal table” (id.), the Specification
`combines conventional and proxy DNS functions––“combining the
`functions of the two servers” to form a “single server.” Ex. 1050, 40:47.
`Hence, the Specification contemplates using conventional DNS look-up
`functions for secure domain names by combining that functionality with
`different proxy DNS functions. According to a passage in the ’705 patent
`and testimony by Dr. Tamassia, a conventional DNS looks up an address for
`a name. See Ex. 1050, 50:39:7–10; Ex. 1005 ¶¶ 150, 164–66 (“much like a
`file system”), 341–44 (describing well-known DNS functionality as
`disclosed in Beser and the ’705 patent as providing a look-up function);
`infra note 17 (evidencing DNS functions).
`Furthermore, in one of Patent Owner’s related ancestor patents, U.S.
`Pat. No. 6,502,135, claim 1 requires “determining whether the DNS request
`transmitted in step (1) is requesting access to a secure web site.” (Emphasis
`added). This patent claim does not preclude a “non-conventional” DNS
`from resolving the access request for a secure web site. See, e.g., Mangrove
`Partners Master Fund, Ltd., v. Virnetx Inc., IPR2015-01046, slip op. at 6–7
`(PTAB Sept. 9, 2016) (Paper 71) (noting that Patent Owner characterized the
`DNS request or resolution in claim 1, in response to a question at oral
`argument, as something that could be “conventional - - non-conventional or
`whatever”).
`Therefore, Patent Owner’s construction and its prosecution history
`arguments (as discussed further below) obscure the clear meaning of the
`
`17
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`claim term––because they attempt to preclude the ability of a “conventional”
`DNS from resolving a “non-standard” name. As the record shows, the
`conventional DNS functionality at issue simply involves looking up names
`(using for an example an internal table or similar structure). Therefore, if a
`DNS resolves a non-standard name (whatever that means especially if not
`limited to a top-level domain name), the resolution itself would be
`“conventional,” whereas Patent Owner’s construction implies that any DNS
`that resolves a “non-standard” name cannot be “conventional.”
`As indicated above, Federal Circuit precedent indicates that
`prosecution history must be consulted in claim interpretation, but it does not
`necessarily bind the PTO. See Philips, 415 F.3d at 1317 (“[T]he prosecution
`history provides evidence of how the PTO and the inventor understood the
`patent. . . . Yet because the prosecution history represents an ongoing
`negotiation between the PTO and the applicant, rather than the final product
`of that negotiation, it often lacks the clarity of the specification and thus is
`less useful for claim construction purposes.”); Tempo Lighting, 742 F.3d at
`978 (The “court also observes that the PTO is under no obligation to accept
`a claim construction proffered as a prosecution history disclaimer, which
`generally only binds the patent owner.”).
`In this case, the Specification and plain meaning of the claims do not
`support the prosecution history arguments and those arguments obscure the
`plain meaning. See Phillips, 415 F.3d at 1316 (“The construction that stays
`true to the claim language and most naturally aligns with the patent’s
`description of the invention will be, in the end, the correct construction.”
`(citation omitted)). Attempting to support its claim construction arguments
`discussed above, Patent Owner contends that it disclaimed “a domain name
`
`18
`
`
`
`IPR2015-00870
`Patent 8,560,705 B2
`
`that just happens to be associated with a secure computer or just happens to
`be associated with an address requiring authorization” during an inter partes
`reexamination of a related patent, and that the Specification supports its
`construction. PO Resp. 23 (citing Ex. 2016, 5; 2017, 4). Patent Owner
`explains that its argument about what a “secure domain name just happens to
`be associated with” means that “a secure domain name cannot be resolved
`by a conventional domain name service.” Id. (citing Ex. 2017, 4); accord
`Ex. 2016, 6 (arguing “a secure domain name cannot be resolved by a
`conventional domain name service, for example,” relying on “the inventors .
`. . acting as their own lexicographers,” and citing disclosed ex