`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`I APPLE INC.,
`Petitioner,
`
`V.
`
`VIRNETX INC.,
`Patent Owner.
`
`Case IPR2014—O0237
`
`Patent 8,504,697
`
`PATENT OWNER VIRNETX INC.’S NOTICE OF APPEAL
`
`
`
`Case No. IPR2014—00237
`
`Patent No. 8,504,697
`
`Director of the United States Patent and Trademark Office
`
`c/o Office of the General Counsel
`
`Madison Building East, 10B2O
`600 Dulany Street
`Alexandria, VA 22314-5793
`
`Notice is hereby given, pursuant to 37 C.F.R. § 90.2(a), that Patent Owner
`
`VirnetX Inc. (“VirnetX”) appeals to the United States Court of Appeals for the
`
`Federal Circuit from the Final Written Decision entered on May 11, 2015 (Paper
`
`41) (the “Final Written Decision”) by the United States Patent and Trademark
`
`Office, Patent Trial and Appeal Board (the “Board”), and from all underlying
`orders, decisions, rulings, and opinions. A copy of the Final Written Decision is
`
`attached.
`
`In accordance with 37 C.F.R. § 90.2(a)(3)(ii), VirnetX indicates that the
`
`issues on appeal include, but are not limited to, the Board’s determination of
`
`unpatentability of claims 1, 3-11, 14-23, 25, and 28-30 of U.S. Patent No.
`8,504,697 under 35 U.S.C. § 102, the Board’s determination ofunpatentability of
`
`claims 1-11, 14-25, and 28-30 ofU.S. Patent No. 8,504,697 under 35 U.S.C. § 103,
`
`and any findings or determinations supporting or related to those rulings including,
`
`without limitation, the Board’s application of the broadest reasonable interpretation
`
`standard, the Board’s interpretation of the claim language, and the Board’s
`
`interpretation of the prior art.
`
`
`
`
`
`
`
`Case No. IPR2014-00237
`
`Patent No. 8,504,697
`
`Simultaneous with this submission, a copy of this Notice of Appeal is being
`
`filed with the Board and three copies of this Notice of Appeal and the required fee
`
`are being filed with the Clerk of Court for the United States Court of Appeals for
`
`the Federal Circuit.
`
`Respectfully submitted this 10th day of July, 2015.
`
`
`
`Naveen Modi
`
`Registration No. 46,224
`Paul Hastings LLP
`875 15th Street, N.W.
`Washington, DC 20005
`(202) 551-1700
`naVeenmodi@paulhastings.com
`
`Counselfor Vz'rnezXInc.
`
`
`
`Case No. IPR20l4—00237
`
`Patent No. 8,504,697
`
`CERTIFICATE OF SERVICE
`
`The undersigned certifies that, in addition to being filed electronically
`
`through the Patent Trial and Appeal Board’s Patent Review Processing System
`
`(PRPS), the original Version of this Notice of Appeal was filed by hand on July
`
`10th, 2015 with the Director of the United States Patent and Trademark Office, at
`
`the following address:
`
`Director of the United States Patent and Trademark Office
`
`c/o Office of the General Counsel
`
`Madison Building East, 1OB20
`600 Dulany Street
`Alexandria, VA 22314-5793
`
`The undersigned also certifies that three true and correct copies of this
`
`Notice of Appeal were filed by hand on July 10th, 2015, with the Clerk of Court
`
`for the United States Court of Appeals for the Federal Circuit at the following
`
`address:
`
`Clerk of Court
`
`United States Court of Appeals for the Federal Circuit
`717 Madison Place, N.W.
`Washington, DC 20439
`
`
`
`
`
`
`
`Case No. IPR2014—00237
`
`Patent No. 8,504,697
`
`
`
`The undersigned also certifies that a true and correct copy of this Notice of
`
`Appeal was served on July 10th, 2015 on counsel of record for Petitioner Apple
`
`Inc. by electronic mail (by agreement of the parties) and by courier at the following
`
`addresses:
`
`Jeffrey P. Kushan (jkushan@sidley.com)
`Joseph A. Micallef (jmicallef@sidley.com)
`Sidley Austin LLP
`1501 K Street, N.W.
`Washington, DC 20005
`
`Date: July 10, 2015
`
`By: g
`
`Naveen Modi
`
`.
`
`Registration No. 46,224
`Paul Hastings LLP
`875 15th Street, N.W.
`Washington, DC 20005
`(202) 551-1700
`naVeenmodi@paulhastings.com
`
`‘ Counselfor Vz'metXIrzc.
`
`
`
`
`
`Tria1s@uspto. gov
`571-272-7822
`
`Paper 41
`Date: May 11, 2015
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`
`Petitioner,
`
`V.
`
`VIRNETX INC.,
`Patent Owner.
`
`Case IPR2014-00237
`
`Patent 8,504,697 B2
`
`Before MICHAEL P. TIERNEY, KARL D. EASTHOM, and
`
`STEPHEN C. SIU, Administrative Patent Judges.
`
`EASTHOM, Administrative Patent Judge.
`
`FINAL WRITTEN DECISION
`
`35 US. C. § 3]8(a) and 37 CFR. § 42. 73
`
`
`
`IPR2014—00237
`
`Patent 8,504,697 B2
`
`I. BACKGROUND
`
`Petitioner, Apple Inc., filed a Petition (Paper 1,“Pet.”) seeking an inter
`
`partes review of claims 1~11, 14-25, and 28-30 of U.S. Patent No.
`
`8,504,697 B2 (EX. 1001, “the ’697 patent”) pursuant to 35 U.S.C. §§ 311-
`
`319. After VirnetX, Patent Owner, filed a Preliminary Response (Paper 12),
`
`we instituted an inter partes review of claims 1—1 1, 14-25, and 28-30
`
`(Paper 15, “Institution Decision” or “Inst. Dec.”).
`
`Subsequent to institution, Patent Owner filed a Patent Owner
`
`Response (Paper 30) (“PO Respf’), and Petitioner filed a Reply (Paper 33)
`
`(“Pet. Reply”) thereto. An Oral Hearing was conducted on February 9,
`
`2015, and then transcribed. See Paper 40.
`
`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-11, 14-25, and 28-30 of the
`
`’697 patent are unpatentable.
`
`A. The ’697Patent (Ex. I001)
`
`The ’697 patent describes secure methods for communicating over the
`
`internet. EX. 1001, 10:7——8. To provide a secure network, the ’697 patent
`
`system employs proxy domain name servers (DNS). The ’697 patent
`
`describes conventional DNSS as follows:
`
`Conventional Domain Name Servers (DNSS) provide a look-up
`function that returns the IP [Internet Protocol] 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
`
`
`
`IPR2014—00237
`
`Patent 8,504,697 B2
`
`and then used by the browser to contact the destination web
`site.
`
`Ex. 1001, 39:32-38.
`
`To set up the secure network or Virtual Private Network (“VPN”), a
`
`proxy DNS determines whether the user has requested accessto a secure site
`
`and may determine whether the user has sufficient security privileges to
`
`access that site. Ex. 1001, 40:31-37, 4126-64. To make both
`
`determinations, the proxy DNS provides DNS look-up functions for secure
`
`hosts. Id. at 40:31-37. The proxy DNS"may use a domain name extension
`
`or an internal table of sites, or may request security information about the
`
`user. Id. at 40:31-37, 41:14-27. If the user has requested access and has
`
`sufficient security privileges, the proxy DNS requests a gatekeeper to set up
`
`a secure communication link by passing a “resolved” address or “hopblocks”
`
`for the user and target addresses. See Ex. 1001, 40:37—~65, Fig. 27. Any of
`
`various packet fields can be “hopped,” for example, “IP source/destination
`
`addresses” or “a field in the header.” Ex. 1001, 41 :3 8—39. If the user lacks
`
`sufficient security privileges, the system returns a “HOST UNKNOWN”
`
`error message. Ex. 1001, Fig. 27.
`
`In essence, the system provides security through anonymity of IP
`
`addresses—the proxy server does not send back the true IP address of the
`
`target computer. See Ex. 1001, 40: 1—20. For example, the proxy server may
`
`receive the client’s DNS request, which forwards it to a gatekeeper, which
`
`returns a “resolved” destination address to the proxy based on a “resolved”
`
`name, which then forwards the “resolved address” back to the client “in a
`
`secure administrative VPN.” See Ex. 1001, 41:49-56.
`
`
`
`IPR2014—00237
`
`Patent 8,504,697 B2
`
`V
`
`B. Illustrative Claim
`
`Claim 1 of the ’697 patent is reproduced below:
`
`A method of connecting a first network device and
`1.
`a second network device, the method comprising:
`intercepting, from the first network device, a request to
`look up an internet protocol (IP) address of the second network
`device based on a domain name associated with the second
`
`network device;
`in response to the request, whether the
`determining,
`second network device is available for a secure communications
`
`A
`service; and
`initiating a secure communication link "between the first
`network device and the second network device based on a
`
`determination that the second network device is available for
`
`the secure communications service;
`wherein the secure communications service uses the
`
`secure communication link to communicate at least one of
`
`video data and audio data between the first network device and
`
`the second network device.
`
`Beser
`
`US 6,496,867 B1 Dec. 17, 2002
`
`(EX. 1009)
`
`C. Prior Art
`
`S. Kent and R. Atkinson, Security Architecture for the Internet Protocol,
`Request for Comments: 2401, BBN Corp., November 1998 (“RFC 2401”)
`(EX. 1010).
`
`D. Instituted Grounds of Unpatentabilny
`
`We instituted an inter partes review on the following grounds and
`
`claims.
`
`
`
`_
`
`Referferlgciesifl
`
`2
`it
`iBeserm
`Beser and RFC 2401
`
`g, M
`
`“ Basis pi
`§102
`§ 103
`
`ii
`
`~
`i
`it
`
`i,,, -{Claims Challeniged
`0
`1~11,i14;25,andi28é3di
`1-11, 14-25, and 28-30
`
`
`
`IPR2014-00237
`
`Patent 8,504,697 B2
`
`
`
`E. Claim Interpretation
`
`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. In re Cuozzo Speed Techs.,
`
`LLC, 778 F.3d 1271, 1281 (Fed. Cir. 2015); 37 C.F.R. § 42.100(b); Ofiice
`
`Patent Trial Practice Guide, 77 Fed. Reg. 48,756, 48,766 (Aug. 14, 2012).
`
`With the exception of slight modifications to some of the terms discussed
`
`below, we adopt and incorporate the claim constructions set forth in the
`
`Institution Decision. See Inst. Dec. 7-15.
`
`i. Secure Communication Link
`
`In the Institution Decision, we determined, under the broadest
`
`reasonable construction standard, that a “secure communication link,” as
`
`recited in claims 1 and 16, is “a transmission path that restricts access to
`
`data, addresses, or other information on the path, generally using obfuscation
`
`methods to hide information on the path, including, but not limited to, one or
`
`more of authentication, encryption, or address hopping.” Inst. Dec. 10.
`
`Patent Owner argues that the term “secure communication link” must
`
`include encryption. See, e. g., PO Resp. 10-19.
`
`Notwithstanding Patent Owner’s arguments that security requires
`
`encryption, the ’697 patent Specification states that “[a] tremendous variety
`
`of methods have been proposed and implemented to provide security and
`
`anonymity for communications over the Internet.” Ex. 1001, 1:35-37
`
`(emphasis added). The ’697 patent Specification also describes data security
`
`and anonymity as counterpart safeguards against eavesdropping that may
`
`occur while two computer terminals communicate over the Internet. See id.
`
`at 1:38-54. Security, in one context, may refer to protection of the data
`
`
`
`IPR2014—00237
`
`Patent 8,504,697 B2
`
`itself, to preserve the secrecyof its contents, while anonymity refers to
`
`preventing an eavesdropper from discovering the identity of a participating
`
`terminal. See id. at 1:40—56. Further according to the ’697 patent
`
`Specification, the concept of security generally includes “two security
`
`issues,” address (anonymity) and data security, with “a desire[] for the
`
`communications to be secure, that is, immune to eavesdropping.” Id. at
`
`1:42-43, 54-56.
`
`This understanding is also consistent with the Federal Circuit’s
`
`construction of this term in an appeal of a related case. Shortly after Patent
`
`Owner filed its Response, the Federal Circuit determined that the term does
`
`not require encryption in a related case involving VirnetX, Inc.’s patent
`
`claims of similar scope, based on similar arguments by VirnetX. See
`
`Virnetfifi Inc. V. Cisco Systems, Inc., 767 F.3d 1308, 1317-19 (Fed. Cir.
`
`2014).1 Relying on passages that also appear in the ’697 patent
`
`Specification in the same context, the court determined that a “secure
`
`communication link” (as used in the ’504 and ’21l ancestor patents, see note
`
`1), is “a direct communication link that provides data security and
`
`arzorzymity.” See Cisco, 767 F.3d at 1319. In Cisco, the court found that
`
`“[b]oth the claims and the specification of the ’ 151 patent make clear that
`
`encryption is a narrower, more specific requirement than security.” Id. at
`
`1323 (citing a passage in the ’151 patent at 1:49—50 that also appears in the
`
`1 The ’697 patent is a continuation of U.S. Patent No. 7,921,211 (“’21l
`patent”), which is a continuation of U.S. Patent No. 7,418,504 (“’504
`paten ”), which is a continuation—in-part of U.S. Patent No. 6,502,135 (“’ 135
`patent”), three of the four patents at issue in Cisco. See 767 F.3d at 1313.
`Also at issue in Cisco, is U.S. Patent No. 7,490,151 (“’15 1 patent”), a
`division of the ’ 135 patent.
`
`
`
`IPR2014-00237
`
`Patent 8,504,697 B2
`
`’697 patent at 1:57-60: “Data security is usually tackled using some form of
`
`data encryption.”
`
`Central to its claim construction, the court found, based on
`
`concessions or arguments by the parties, that the ordinary meaning of the
`
`term “security,” on that record, did not apply. See id. at 1317 (“There is no
`
`dispute that the word ‘secure’ does not have a plain and ordinary meaning in
`
`this context, and so must be defined by reference to the specification.”).
`
`In not requiring encryption, Cisco additionally found on that record
`
`that security includes “physical security.” See Cisco, 767 F.3d at 1322
`
`(“VirnetX provided substantial evidence for the jury to conclude that paths
`
`beyond the VPN server may be rendered secure and anonymous by means of
`
`‘physical security’ present in the private corporate networks connected to by
`
`VPN On Demand”). Underlying that finding, Cisco noted that “VirnetX’s
`
`expert testified that one of ordinary skill would understand that the path .
`
`.
`
`.
`
`within the private network[] would be secure and anonymous owing to the
`
`protection provided by the private network.” Id. at 1321.
`
`Of course, anonymity provides some security, as explained in Cisco.
`
`The claim construction in the Institution Decision also includes anonymity
`
`as a form of security, but not as a necessary requirement. Instead, our
`
`construction also includes address hopping, restricting access to addresses,
`
`and generally, obfuscation methods. This is not inconsistent with the
`
`Federal Circuit’s construction. In contrast to the broadest reasonable
`
`interpretation standard employed by the Board for an unexpired patent, the
`
`Federal Circuit employs a narrower claim construction standard when
`
`reviewing the construction of a claim applied by the district court. See In re
`
`Rambus, Inc., 694 F.3d 42, 46 (Fed. Cir. 2012) (contrasting the Board’s
`
`
`
`IPRZG 14-00237
`
`Patent 8,504,697 B2
`
`review of expired patents, which is “similar to that of a district court’s
`
`review,” with the Board’s review of unexpired patents, which involves the
`
`broadest reasonable interpretation standard); Cuozzo, 778 F.3d at 1281
`
`(broadest reasonable interpretation standard applies to AIA proceedings). In
`
`any event, anonymity is not a central issue, because the Beser reference
`
`discloses it and the parties do not raise it. See EX. 1009, Abstract, 12:16-19.
`
`Accordingly, in— this case, it is not necessary to determine if a secure
`
`communication link, under the broadest reasonable construction standard,
`
`necessarily includes anonymity (or a direct link).2
`
`Based on the foregoing discussion, the term may include encryption,
`
`anonymity, and physical security. Therefore, we slightly modify our
`
`construction of the term as set forth in our Institution Decision. The
`
`broadest reasonable construction of a “secure communication link” is “a
`
`transmission path that restricts access to data, addresses, or other
`
`information on the path, generally using obfuscation methods to hide
`
`information on the path, including, but not limited to, one or more of
`
`anonymity, authentication, or encryption.”
`
`ii) Virtual Private Network ( VPN) Communication Link
`
`Claims 3 and 17 respectively depend from claims 1 and 16 and further
`
`limit those claims by reciting “wherein the secure communication link is a
`
`virtual private network [(VPN)] communication link.” In the Institution
`
`Decision, we construed a VPN to include “a secure communication link that
`
`2Notwithstanding Cisco ’s “direct” component of a “secure communication
`link,” Patent Owner argues that it “do[es] not appear relevant to the parties’
`disputes.” PO Resp. 14 n.1. Similarly, the parties do not propose that
`anonymity is a requirement in their latest papers. See Pet. Reply 4
`(suggesting anonymity is not relevant); PO Resp. 19 (same).
`
`
`
`IPR2014—0023 7
`
`Patent 8,504,697 B2
`
`includes a portion of a public network.” Inst. Dec. 12. The construction was
`
`based largely on the finding that the parties did not provide a clear
`
`distinction between a secure and VPN communications link, evidence of
`
`ordinary meaning provided by Petitioner (see, e. g., Ex. 1073, 2-5), and the
`
`finding that the ’697 patent Specification “explains [that] a ‘secure
`
`communication link’ is ‘a virtual private communication link over the
`
`computer network?” Inst. Dec. 11 (quoting Ex. 1001, 6:63-65, also relying
`
`on Ex. 1073, Ex. 1024). By way of background, one commentator generally
`
`describes a VPN as a collection of devices that can communicate (i.e., a
`
`network) over a public network with a desired level of privacy obtained by
`
`controlling access and security of data (i.e., Virtually private). See EX. 1073,
`
`2-6.
`
`Patent Owner argues that “the term VPN is not in dispute here and is
`
`not a claim term,” so “the Board need not construe it.” PO. Resp. 19. Patent
`
`Owner characterizes the recited term, “a [VPN] communication link,” as
`
`“related [to] but different” from, a VPN. Id. Referring to a VPN
`
`communication link, Patent Owner urges that “the Board need not construe
`
`this term .
`
`.
`
`. and [its construction] does not appear to impact any of the
`
`issues in this case.” PO Resp. 21.
`
`Nevertheless, according to Patent Owner, Beser does not disclose a
`
`VPN. PO Resp. 54. This stance mandates a construction of the term on this
`
`record. Patent Owner maintains that a “VPN communication link” is “a
`
`communication path between computers in a Virtual private network.” PO
`
`Resp. 21. Regarding the construction of a “VPN” as “a secure
`
`communication link with the additional requirement that the link includes a
`
`portion of the public network” (Inst. Dec. 11-12), Patent Owner “does not
`
`
`
`IPR2O 14-00237
`
`Patent 8,504,697 B2
`
`dispute the ‘secure communication link’ aspect of the Decision’s
`construction,” except to the extent that it lacks the encryption and direct link
`
`requirements discussed above in the construction of a secure communication
`
`link. See PO Resp. 20 & n.4. As discussed above (note 2), Patent Owner
`
`maintains that the “direct” requirement is not at issue in this proceeding, and
`
`in line with Cisco, we determined that encryption is not a necessary
`
`requirement of a secure communication link.
`
`The parties do not set forth explicitly what a VPN constitutes. In
`
`Cisco, the court indicates, as construed in the ancestor ’504 patent (supra
`
`note 1), that a VPN provides anonymity: “Moreover, in several instances
`
`the specification appears to use the terms ‘secure communication link’ and
`
`‘VPN’ interchangeably, suggesting that the inventors intended the disputed
`
`term to encompass the anonymity provided by a VPN.” 767 F.3d at I318.
`
`Although a VPN as construed by Cisco includes anonymity, neither
`
`party argues for that requirement in their latest papers. And as noted, Patent
`
`Owner maintains that the construction of VPN “does not appear to impact
`
`any of the issues in this case.” PO Resp. 21. Claims 3 and 17 depend from
`
`claims 1 and 16, suggesting pursuant to claim differentiation that a VPN
`
`communication link is narrower than a secure communication link.
`
`Therefore, for purposes of this proceeding, the broadest reasonable
`
`construction of a “virtual private network communication link” is “a secure
`communication link that includes a portion of a public network,” as set forth
`
`in the Institution Decision. Inst. Dec. ll—l2.
`
`iii 2 Intercegting A Request
`
`In the Institution Decision, we construed “intercepting a request,” as
`
`recited in claim 1, as “receiving a request pertaining to a first entity at
`
`10
`
`
`
`IPR20 14-00237
`
`Patent 8,504,697 B2
`
`
`
`another entity.” Inst. Dec. 13. Claim 16 recitesa similar term (i.e.,
`
`“intercept .
`
`.
`
`. a request”). Patent Owner “disagrees with this construction”
`
`(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).
`
`Nevertheless, Patent Owner urges that if we construe the term, 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.” Id. at
`
`23.
`
`To support its proposed alternative construction, Patent Owner
`
`maintains 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.” Id. at 26 (emphases added)
`
`(citation omitted). According to Patent Owner, 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.” Id. at 25. As an “example, the DNS proxy 2610 may intercept the
`
`request and ‘determin[e] whether access to a secure site has been
`
`requested.”’ Id. (quoting Ex. 1001, 40:31-33).
`
`Patent Owner’s arguments and the record show that Patent Owner’s
`
`proposed construction adds unnecessary functionality to “intercepting a
`
`request.” According to Patent Owner’s arguments, and as Petitioner points
`
`out, another recited phrase in claim 1 (and a similar phrase in claim 16),
`
`11
`
`
`
`
`
`IPR2O 14-00237
`
`Patent 8,504,697 B2
`
`captures the functionality, in particular, the “determining .
`
`.
`
`. whether”
`
`phrase of claim 1, which is recited after the intercepting phrase. See Pet.
`
`Reply 4—5 (“Patent Owner’s illogical construction .
`
`.
`
`. is actually part of the
`
`next step of the claims”); see also PO Resp. 26 (“The independent claims
`
`also support this [functionality], for example, by reciting that a
`
`determination is made whether the second network is available for a secure
`
`communications service .
`.
`.
`.”)-. In other words, Patent Owner argues that
`the “determining .whether’’ clause covers functionality that it also urges
`is implicit in the intercepting phrase. See PO Resp. 26, 29-30. Based on the
`
`foregoing discussion, the record shows that the additional functionality
`
`urged by Patent Owner should not be imported into the intercepting phrase.
`
`Accordingly, as set forth in the Institution Decision, the broadest reasonable
`
`construction of the term “intercepting a request” is “receiving a request
`
`pertaining to a first entity at another entity.”
`
`iv) Determining, In Response To The Reguest, Whether
`The Second Network Device Is Available For Communication
`
`In the Institution Decision, we construed the above phrase, as recited
`
`in claim 1 (and similarly in claim 16), to “include[] determining, one or
`
`more of 1) whether the device is listed with a public internet address, and if
`
`so, allocating a private address for the second network device, or 2) some
`
`indication of the relative permission level or security privileges of the
`
`requester.” Inst. Dec. 15. Petitioner implicitly agrees with this construction.
`
`See Pet. Reply 5-6.
`
`Patent Owner asserts that this construction “imports unnecessary
`
`language into the claims.” PO Resp. 27. Patent Owner maintains that there
`
`is no reason to require “an allocation of a private address,” because that step
`
`does not aid in determining availability. See id. at 27-28. Patent Owner
`
`12
`
`
`
`IPR2014—00237
`
`Patent 8,504,697 B2
`
`also argues that the construction eliminates the requirement of the
`
`determination being made “in response to the request.” See id. at 30. Patent
`
`Owner also maintains that “[t]he claim language is plain on its face .
`
`.
`
`.
`
`.
`
`[and] does not require construction.” See id.
`
`Patent Owner’s arguments show persuasively that the preliminary
`
`construction was too narrow. The term “available” has an ordinary meaning
`
`of “accessible for use; at hand; usable.” Ex. 3004.3 Based on the arguments
`
`presented, the ordinary meaning of the term “available,” and the ’697 patent
`Specification, we modify our previous claim construction as follows: The
`
`term “determining, in response to the request, whether the second network
`
`device is available for secure communication,” means “determining, in
`
`response to a request, whether the second network device is accessible for
`
`use, at hand, or usable for a secure communication.”
`
`Interpreting the “determining” phrase, Patent Owner directs attention
`
`to a passage in the ’697 patent Specification, “‘determin[ing] whether access
`
`to a secure site has been requested.”’ PO Resp. 29 (quoting Ex. 1001,
`
`40:32—33, modified by Patent Owner). The sentence immediately following
`
`this cited passage supports the view that gauging the requester’s security
`
`privileges may help to determine whether a device is accessible:
`
`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. 1001, 40:33-37.
`
`3 THE AMERICAN HERITAGE DICTIONARY OF THE ENGLISH LANGUAGE 90
`
`(1975).
`
`13
`
`
`
`IPR2014—00237
`
`Patent 8,504,697 B2
`
`More importantly, 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.
`
`Patent Owner argues 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.’” PO Resp. 29 (emphasis added, citing EX. 2025 11 30).
`
`Therefore, the quoted passage from the Specification, bolstered by Patent
`
`Owner’s argument, 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.
`
`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.” Ex. 1001, 40:45~49.
`
`Another passage describes a normal DNS “look—up function”:
`
`For DNS requests that are determined to not require secure
`services (eg, 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.
`
`EX. 1001, 40:14-20.
`
`In summary, according to disclosed embodiments in the ’697 patent
`
`Specification, a device may be determined to be available as a secure device
`
`14
`
`
`
`IPR20 14-0023 7
`
`Patent 8,504,697 B2
`
`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 ’697 patent
`
`Specification and the arguments presented, “determining, in response to a
`
`request, whether a second network device is available for secure
`
`communication,” means “determining if the second network device is
`
`accessible for use, at hand, or usable, in a system that provides secure
`
`communication using that device.”
`
`11. ANALYSIS
`
`A. Beser
`
`Beser describes a system that establishes an IP (internet protocol)
`
`tunneling association between two end devices 24 and 26 on private
`
`networks, using first and second network devices 14 and 16, and trusted-
`
`third-party network device 30, over public network 12. See EX. 1009,
`
`Abstract, Fig. 1; Pet. 16.
`
`15
`
`
`
`IPR2014—00237
`
`Patent 8,504,697 B2
`
`Figure 1 of Beser follows:
`26
`
`
`
`Figure 1 above represents Beser’s system, which includes the Internet
`
`as public network 12, network end devices 24 and 26, private networks 20,
`
`trusted-third-party device 30, and modified router or gateway network
`
`devices 14 and 16-. See Ex. 1009, Abstract, 3:60-4:18.
`
`Beser’s system “increases the security of communication on the data
`
`network” by providing and hiding, in packets, “private addresses” for
`
`originating device 24 and terminating device 26 on the network. See id. at
`
`Abstract, Fig. 1, Fig. 6. To begin the process for a secure transaction, at step
`
`102, requesting device 24 sends to network device 14, as part of its request,
`
`an indicator that “may be a distinctive sequence of bits [that] indicates to the
`
`tunneling application that it should examine the request for its content and
`
`not ignore the datagram.” EX. 1009, 8:40-44, Figs. 1, 4. The request (which
`
`may include a series of packets) also includes a unique identifier, such as a
`
`domain name, employee number, telephone number, social security number,
`
`a public IP address 58, or other similar identifier, associated with
`
`terminating device 26. EX. 1009, 10:37—11:8, 11:9—12. At step 104,
`
`16
`
`
`
`
`
`IPR2014—00237
`
`Patent 8,504,697 B2
`
`network device 14 informs trusted—third—party network device 30 of the
`
`request. See id. at 7:64—8:7, 11:9-20, Fig. 4.
`
`Trusted—third~party device 30 contains a directory of users, such as a
`
`DNS, which retains a list of public IP addresses associated at least with
`
`second network devices 16 and terminating devices 26. See id at 11:32-58.
`
`At step 106 (and parallel step 116), DNS 30 associates terminating network
`
`device 26, based on its unique identifier (e.g., domain name, or other
`
`identifier) in the request, with a public IP address for router device 16 (i.e.,
`
`the association of the domain name with other stored information, including
`
`Internet addresses, shows they are connected together at the edge of public
`
`network 12). See Ex. 1009, 1112636, Figs. 1, 4, 5 .4 As indicated, DNS 30
`
`includes, in a directory database or otherwise, stored public IP addresses for
`
`router 16 and terminal device 26, and other data that associates devices 16
`
`and 26 together.
`
`'Id. at 11:48-52. In other words, trusted—third-party
`
`network device DNS 30, includes the “IP5 8 addresses for the terminating .
`
`.
`
`.
`
`device[s] 26,” and uses “data structures .
`
`.
`
`. known to those skilled in the art
`
`.
`
`.
`
`. for the association of the unique identifiers [for terminating devices 26]
`
`and IP 58 addresses for the .
`
`.
`
`. network devices 1 ”—including domain
`
`names as unique identifiers, as noted above. Id. at 11: 2—5, 32-36, 4855.
`
`At step 108 (or step 118), Beser’s system assigns, by negotiation,
`
`private IP addresses to requesting network device 24 and terminating device
`
`26. See id. at 1l:59—~12:19, 12:38—48, Figs. 4, 5. In an exemplary
`
`embodiment, trusted-third-party network (DNS) device 30 performs the
`
`4 Figure 5, which includes step 116, involves a specific Voice-over—Internet—
`Protocol (VoIP) application of the general process of Figure 4, which
`includes parallel step 106. See Ex. 1009, 3:26-30.
`
`17
`
`
`
`IPR2O 14-00237
`
`Patent 8,504,697 B2
`
`negotiation for private addresses in order to further ensure anonymity of end
`
`devices 24 and 26 (though device 30 need not be involved in the negotiation
`
`in one embodiment). Id. at 9:29-35, 12: 17—~19. The negotiated private IP
`
`addresses are “isolated from a public network such as the Internet,” and “are
`
`not globally routable.” Id. at l1:63—65. “These IP 58 addresses may be
`
`stored in network address tables on the respective network devices, and may
`
`be associated with physical or local network addresses for the respective
`
`ends of the VoIP [(Voice—over— l