Trials@uspto.gov Paper 39
`Tel: 571-272-7822
`Entered: 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-00871
`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
`
`
`Tel: 571-272-7822
`Entered: 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-00871
`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-00871
`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. Pet. 2–3. After
`VirnetX Inc., Patent Owner, filed a Preliminary Response (Paper 6, “Prelim.
`Resp.”), we instituted an inter partes review of claims 1–30 (Paper 8,
`“Institution Decision” or “Inst. Dec.”). Inst. Dec. 2.
`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-00870 (PTAB Sept. 28, 2016) (Paper
`No. 39, “’870 FWD”) (generally “’870 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-00871
`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 “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 returns to
`
`
`
`3
`
`
`
`IPR2015-00871
`Patent 8,560,705 B2
`
`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 . . . IP address ‘hopping’
`features,” (changing IP addresses based upon an agreed upon algorithm)
`described in the ’705 patent, “such that the true identity of the two nodes
`cannot be determined even if packets during the communication are
`intercepted.” See 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;
`
`(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
`
`
`
`4
`
`
`
`IPR2015-00871
`Patent 8,560,705 B2
`
`
`(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 Aventail1 (Ex. 1009–11), RFC 24012 (Ex.
`1008), and RFC 25433 (Ex. 1013), and claim 24 as unpatentable based on
`the combination of Aventail (Ex. 1009–11), RFC 2401 (Ex. 1008), RFC
`2543 (Ex. 1010), and Brand (Ex. 1012).4 Inst. Dec. 21.
`II. ANALYSIS
`A. 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
`
`
`1 Exhibits 1009–1011 correspond to manuals that collectively describe an
`Aventail Connect client and ExtraNet Server software application. We refer
`collectively to the three manuals as “Aventail” unless otherwise noted. See
`Aventail Connect v3.01/v2.51 Administrator’s Guide (Ex. 1009), Aventail
`Connect v3.01/v2.51 User’s Guide (1996–1999) (Ex. 1010), and Aventail
`ExtraNet Center v3.0 Administrator’s Guide (NT and UNIX) (“Aventail
`ExtraNet Admin. Guide”) (Ex. 1011).
`2 S. Kent and Randall Atkinson, RFC 2401, Security Architecture for the
`Internet Protocol, Network Working Group, Request for Comments (Nov.
`1998).
`3 Handley et al., RFC 2543, SIP: Session Initiation Protocol, Network
`Working Group, Request for Comments (Mar. 1999).
`4 U.S. Pat. No. 5,237,566 (Aug. 17, 1993).
`
`
`
`5
`
`
`
`IPR2015-00871
`Patent 8,560,705 B2
`
`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
`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. 9–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.
`Similar to its position in the ’237 IPR proceeding, Patent Owner states
`in the instant proceeding that “no construction [is] necessary.” PO Resp. 4;
`’237 PO Resp. 23 (“no construction is necessary”). Nevertheless, as it did in
`the ’237 IPR, Patent Owner urges that if we construe the term, then we adopt
`
`
`
`6
`
`
`
`IPR2015-00871
`Patent 8,560,705 B2
`
`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 in the ’237 IPR, a disclosed modified
`DNS “appl[ies] an additional layer of functionality to a request to look up a
`network address beyond merely resolving it and returning the network
`address.” ’237 PO Resp. 25. Patent Owner’s arguments are similar in
`material respects in the instant proceeding. 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.5
`The arguments and record shows 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
`“a determination is made as a result of the request [to look up an IP address]
`that the target device is a device with which a secure communication link
`
`5 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) (citation omitted).
`
`
`
`
`7
`
`
`
`IPR2015-00871
`Patent 8,560,705 B2
`
`can be established”) (addition by Patent Owner). 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. 27–
`30; ’237 PO Resp. 26, 29–30.
`The parties agree that “interception of a request” (at least) involves
`“receiving a request” at some intermediate device. See PO Resp. 4; Pet. 9–
`10. Patent Owner’s proposed construction does not create any distinction
`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 5. In
`essence, Petitioner’s construction captures the notion of interception as
`disclosed in the ’705 patent, by requiring receiving to “pertain” to another
`entity.
`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, as set forth in 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,]
`
`
`
`8
`
`
`
`IPR2015-00871
`Patent 8,560,705 B2
`
`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.6
`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).
`The Specification supports this interpretation:
`If access to a secure 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 structure) of secure sites is sufficient
`to constitute a determination of availability.
`
`
`6 We consider the phrase “in response to the request” in the ’237 IPR to have
`been omitted inadvertently from the claim construction in that case without
`consequence.
`
`
`
`9
`
`
`
`IPR2015-00871
`Patent 8,560,705 B2
`
`
`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. 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.
`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.”
`
`
`
`10
`
`
`
`IPR2015-00871
`Patent 8,560,705 B2
`
`
`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 the related ’481 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 final written decision, 13–14 (same claim
`construction).7 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.
`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”
`
`7 As indicated above, reference is to Apple Inc. v. VirnetX, Inc., IPR2014-
`00481 (“’481 IPR”), slip op. at 8 (PTAB Sept. 3, 2014) (Paper 11) (“’481
`institution decision”); and ’481 IPR, slip op. at 13–14 (PTAB Aug. 24,
`2015) (Paper 35) (“’481 final written decision”).
`
`
`
`11
`
`
`
`IPR2015-00871
`Patent 8,560,705 B2
`
`corresponds to 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. at 22–23 (citing Ex. 2018 ¶¶ 36–
`38).8 Dr. Monrose contends, inter alia (see note 8), 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).
`Patent Owner further contends it disclaimed Petitioner’s proposed
`construction in a now completed inter partes reexamination of a related
`patent. PO Resp. 23 (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 11, 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
`
`
`8 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-00871
`Patent 8,560,705 B2
`
`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
`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).
`
`
`
`13
`
`
`
`IPR2015-00871
`Patent 8,560,705 B2
`
`
`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
`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.” Ex.
`1050, 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.
`
`
`
`14
`
`
`
`IPR2015-00871
`Patent 8,560,705 B2
`
`
`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 secure DNS using a conventional look-up
`function not to return the secure domain names contemplated by the
`invention. The 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 domain name
`need not be non-standard, because the resolution of it depends on other
`“non-standard” factors like the user’s identity. Similarly, rather than a
`conventional domain name not returning a secure address based solely on
`the name, the Specification states that a “DNS proxy” returns a “host-
`unknown” “[i]f the user had requested lookup 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 II.A.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
`
`
`
`15
`
`
`
`IPR2015-00871
`Patent 8,560,705 B2
`
`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 communication services 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
`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 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. See also supra note 5 (conventional DNS
`part of disclosed embodiments). 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 ¶¶ 164–66 (“much like a file
`system”), 341–44 (describing well-known DNS functionality as disclosed in
`the ’705 patent as providing a look up function); infra note 17 (evidencing
`DNS functions).
`
`
`
`16
`
`
`
`IPR2015-00871
`Patent 8,560,705 B2
`
`
`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
`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 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
`
`
`
`17
`
`
`
`IPR2015-00871
`Patent 8,560,705 B2
`
`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
`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). 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. at 23; see also id. at 24 (citing Ex.
`2017, 4); accord Ex. 2016, 6 (Patentee arguing during prosecution that “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 examples in the ’180 patent of non-
`standard top-level domain names) (emphasis added).
`But as explained above, this argument presents unclear distinctions
`that obscure the meaning of the challenged claims when viewed in light of
`
`
`
`18
`
`
`
`IPR2015-00871
`Patent 8,560,705 B2
`
`the Specification’s disclosure of secure domain names. Contrary to t
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
