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

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