`Tel: 571-272-7822
`
`Paper 43
`Entered: August 30, 2016
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`
`Case IPR2015-00812
`Patent 8,850,009 B2
`
`Before KARL D. EASTHOM, JENNIFER S. BISK, and
`GREGG I. ANDERSON, Administrative Patent Judges.
`
`BISK, Administrative Patent Judge.
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a)
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`INTRODUCTION
`
` Background
`Petitioner, Apple Inc., filed a Petition (Paper 1, “Pet.”) requesting
`inter partes review of claims 1–8, 10–20, and 22–25 (the “challenged
`claims”) of U.S. Patent No. 8,850,009 B2 (Ex. 1003, “the ’009
`patent”). Patent Owner, VirnetX Inc., filed a Preliminary Response. Paper 6
`(“Prelim. Resp.”). We granted the Petition, instituting trial on whether
`claims 1–8, 10–20, and 22–25 are unpatentable as obvious over Beser1 and
`RFC 2401.2 Paper 8 (“Inst. Dec.”).
`During the trial, Patent Owner filed a Response (Paper 24, “PO
`Resp.”), and Petitioner filed a Reply (Paper 28, “Reply”). Additionally,
`Patent Owner filed a Motion to Exclude evidence. Paper 35. A consolidated
`hearing for oral arguments in this inter partes review and Cases IPR2015-
`00810 and IPR2015-00811 was held June 8, 2016. A transcript of the
`hearing appears in the record. Paper 42 (“Tr.”).
`This is a Final Written Decision under 35 U.S.C. § 318(a) and
`37 C.F.R. § 42.73. For the reasons set forth below, Petitioner has shown by
`a preponderance of the evidence that claims 1–8, 10–20, and 22–25 are
`unpatentable.
`
`
`1 U.S. Patent No. 6,496,867 B1 (Ex. 1007) (“Beser”).
`2 S. Kent and R. Atkinson, Security Architecture for the Internet Protocol,
`Request for Comments: 2401, BBN Corp., November 1998 (Ex. 1008)
`(“RFC 2401”).
`
`2
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`
` The ’009 Patent
`The ’009 patent describes secure methods for communicating over the
`Internet. Ex. 1003, 10:16–17. Specifically, the ’009 patent describes “the
`automatic creation of a virtual private network (VPN) in response to a
`domain-name server look-up function.” Id. at 39:36–38. This automatic
`process makes use of a modified Domain Name Server. In context, the ’009
`patent describes a conventional Domain Name Server (DNS) as follows:
`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:39–45.
`The modified DNS server may include both a conventional
`DNS and a DNS proxy. Id. at 40:33–35. The DNS proxy 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:39–45. 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:62–65. If the user has requested
`access to a secure site to which it has sufficient security privileges, the
`DNS proxy requests a gatekeeper create a VPN between the user’s
`computer and the secure target site. Id. at 40:45–51. The DNS proxy
`3
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`then 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:51–57.
`The VPN is “preferably implemented using the IP address
`‘hopping’ features” (changing IP addresses based upon an agreed
`upon algorithm), described elsewhere in the ’009 patent, “such that
`the true identity of the two nodes cannot be determined even if
`packets during the communication are intercepted.” Id. at 40:18–22.
`
` The Challenged Claims
`Claims 1 and 14 of the challenged claims are independent and similar
`in scope. Claims 2–8 and 10–13 depend either directly or indirectly from
`claim 1 and claims 15–20 and 22–25 depend either directly or indirectly
`from claim 14. Claim 1 is illustrative of the claimed subject matter and
`recites:
`1. A network device, comprising:
`a storage device storing an application program for a secure
`communications service; and
`at least one processor configured to execute the application
`program for the secure communications service so as to
`enable the network device to:
`send a domain name service (DNS) request to look up a network
`address of a second network device based on an identifier
`associated with the second network device;
`receive, following interception of the DNS request and a
`determination that the second network device is available for
`the secure communications service: (1) an indication that the
`second network device
`is available
`for
`the secure
`communications service, (2) the requested network address of
`4
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`the second network device, and (3) provisioning information
`for an encrypted communication link;
`connect to the second network device over the encrypted
`communication link, using the received network address of
`the second network device and the provisioning information
`for the encrypted communication link; and
`communicate data with the second network device using the
`secure
`communications
`service via
`the
`encrypted
`communication link,
`the network device being a device at which a user uses the secure
`communications
`service
`to
`access
`the
`encrypted
`communication link.
`Ex. 1003, 56:22–48.
`
`CLAIM CONSTRUCTION
`We interpret claims of an unexpired patent using the broadest
`reasonable construction in light of the specification of the patent in which
`they appear. 37 C.F.R. § 42.100(b); Cuozzo Speed Techs., LLC v. Lee, 136
`S. Ct. 2131, 2144–46 (2016). We presume a claim term carries its “ordinary
`and customary meaning,” which is “the meaning that the term would have to
`a person of ordinary skill in the art in question” at the time of the invention.
`In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007) (citation
`and quotations omitted). The Board construed claim terms similar to those
`at issue here in a proceeding challenging a patent related to the ’009 patent.
`Apple Inc. v. VirnetX Inc., IPR2014-00237 (PTAB May 11, 2015) (Paper
`No. 41) (final written decision “’237 FWD,” or generally, “’237 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).
`
`5
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`
` DNS Request
`The parties agree that the broadest reasonable interpretation of the
`term “DNS Request” is “a request for a resource corresponding to a domain
`name.” Pet. 10; Prelim. Resp. 24; PO Resp. 3. We agree this is a reasonable
`construction and adopt this definition for purposes of this Decision.
`
` Interception of the DNS Request
`Petitioner proposes we construe the term “interception of a DNS
`request” as including “receiving a DNS request pertaining to a first entity at
`another entity.” Pet. 10–11. In its Preliminary Response, Patent Owner
`argued that no construction was necessary for the term, but stated that if “the
`Board decides to provide a construction,” the proper definition is “receiving
`a request to look up an internet protocol address and, apart from resolving it
`into an address, performing an evaluation on it related to establishing an
`encrypted communication link.” Prelim. Resp. 25–28. Because the
`construction of this term was not dispositive to the Institution Decision, we
`did not expressly construe it at that time. Inst. Dec. 6.
`In its Response, Patent Owner continues to assert that “[n]o
`construction is necessary” for the term “interception of the DNS request.”
`PO Resp. 4. Patent Owner, however, also repeats its argument that if we do
`expressly construe this term, we should adopt the definition set forth in
`Patent Owner’s Preliminary Response. Id. at 4–5 (incorporating by
`
`6
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`reference arguments from the Preliminary Response Prelim. Resp. 25–28)3
`(citing Ex. 2016 ¶ 31).
`In a related proceeding, we construed the similar phrase “intercepting
`a request” as “receiving a request pertaining to a first entity at another
`entity.” ’237 FWD 10–12. In this proceeding, as in the ’237 IPR, we
`determine that this term requires construction to resolve an issue of
`patentability. For essentially the same reasons as those articulated in the
`’237 FWD, as explained below, we conclude that the term “interception of
`the DNS request” includes receiving a DNS request pertaining to a first
`entity at another entity.
`Patent Owner argues that the claimed embodiments of the ’009 patent
`“differ from conventional DNS, in part, because they apply an additional
`layer of functionality to a request to look up a network address beyond
`merely resolving it and returning the network address.” Prelim. Resp. 27.
`According to Patent Owner, “Petitioner’s construction overlooks the aspects
`distinguishing the ‘intercepting’ phrase from conventional DNS.” Id.
`Instead, Patent Owner asserts that its proposed construction “appropriately
`captures” the additional functionality. Id. at 27–28; PO Resp. 4–5.
`
`
`3 It is necessary for the panel to refer to Patent Owner’s arguments in the
`Preliminary Response in an effort to maintain a clear record. These
`arguments, however, are improperly incorporated by reference into Patent
`Owner’s Response. See 37 C.F.R. § 42.6(a)(3); Paper 9, 2–3. Patent Owner
`is cautioned that by incorporating arguments by reference, it runs the risk
`that they are disregarded.
`
`7
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`Patent Owner’s arguments and the record, however, show that Patent
`Owner’s proposed construction adds unnecessary functionality to
`“interception of a DNS request.” According to Patent Owner’s arguments,
`another recited phrase in claim 1 (and a similar phrase in claim 14), captures
`the functionality, in particular, the “determination” limitation of claim 1.
`See Prelim. Resp. 28 (listing one example function to be incorporated as “a
`determination is made that the request to look up the network address
`corresponds to a device that is available for the secure communications
`service” and “that ‘following’ this determination [limitation] ‘provisioning
`information’ required to initiate the encrypted communication link is
`provided”). In other words, the “determination” limitation already covers
`functionality that Patent Owner urges is implicit in the term at issue here.
`See Prelim. Resp. 27–28; PO Resp. 4–5.
`The parties agree that “interception of a request” (at least) involves
`“receiving a request” at some device. PO Resp. 4; Pet. 10–11. Patent
`Owner’s proposed construction, however, does not create any distinction
`between the receiving and intercepting of a request. According to
`Petitioner’s proposed construction, an “interception” by the proxy DNS
`includes “receiving” a request to look up an address for another entity. In
`essence, Petitioner’s construction captures the notion of interception as
`disclosed in the ’009 patent, by requiring receiving to “pertain” to another
`entity. Patent Owner, however, can point to nothing in its proposed
`definition that captures the notion of interception. See Tr. 34:19–37:11.
`Patent Owner alleges that Dr. Tamassia adopted an “intent”
`requirement in the “interception” clause—meaning a request must be
`8
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`“intended for” or “ordinarily received by” another entity than that
`which ultimately intercepts it. PO Resp. 31–32 & n.4. Petitioner
`disagrees with any intent requirement, and contends that Patent Owner
`mischaracterizes Beser’s disclosure. Reply 15–17.
`Patent Owner 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. 31–33; Tr. 31:1–34:18.
`And although Patent Owner points to language in the ’237 IPR’s
`institution decision using the “intended for” language (’237 IPR,
`Paper 15, 12), any alleged 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 ’009 patent supports or requires
`such “intent” as part of the broadest reasonable construction of the
`term “interception of a DNS request.” We cannot find support in the
`record for such a requirement.4
`Based on the foregoing discussion, the record shows that the
`additional functionality urged by Patent Owner should not be imported into
`the term “interception of the DNS request.” Moreover, Petitioner’s
`construction is consistent with the plain meaning of the term as well as with
`the language of the claim and Specification. Accordingly, the broadest
`
`
`4 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-00812
`Patent 8,850,009 B2
`
`
`reasonable construction of the term “interception of a DNS request” includes
`“receiving a DNS request pertaining to a first entity at another entity.”
`
`OBVIOUSNESS OVER BESER AND RFC 2401
` Level of Ordinary Skill in the Art
`Petitioner’s expert, Dr. Tamassia, states that a person of ordinary skill
`in the art would have “a good working knowledge of networking protocols,
`including those employing security techniques, as well as cryptographic
`methods and computer systems that support these protocols and techniques.”
`Ex. 1005 ¶ 110; see Pet. 8–9. Such a person would have gained this
`knowledge “either through several years of practical working experience or
`through education and training” or some combination of both. Id.
`Patent Owner argues that “Petitioner proposes a lower level of skill,
`but Patent Owner’s proposed level is the same level of skill that Petitioner
`and nearly a dozen other parties have consistently advocated in related
`litigation involving patents in the same family” as the ’009 patent. Prelim.
`Resp. 235 (citing Ex. 2005, 4; Ex. 2004, 5). Patent Owner’s expert, Dr.
`Monrose, states that “a person of ordinary skill in the art [at the relevant
`time] would have had a master’s degree in computer science or computer
`engineering, as well as two years of experience in computer networking with
`some accompanying exposure to network security.” Ex. 2016 ¶ 13. Dr.
`Monrose adds that his “view is consistent with VirnetX’s view that a person
`of ordinary skill in the art requires a master’s degree in computer science or
`
`
`5 Patent Owner does not appear to renew this argument in its Response. See
`PO Resp. 9–10 n.3.
`
`10
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`computer engineering and approximately two years of experience in
`computer networking and computer security.” Id.
`We are persuaded that Patent Owner’s description of the background
`of a person of ordinary skill in the art is not lower than or inconsistent with
`Petitioner’s description. Instead, Patent Owner’s definition requires a
`particular educational background, but appears to result in the same level of
`expertise as Petitioner’s definition. For purposes of this Decision, based on
`the testimony of the parties’ experts as well as our review of the ’009 patent
`and the prior art involved in this proceeding, we conclude that a person of
`ordinary skill in the art would have a master’s degree in computer science or
`computer engineering and approximately two years of experience in
`computer networking and computer security—or the equivalent, obtained
`through practical work experience and training.
`
` Tamassia Declaration6
`Petitioner supports the assertions in its Petition with a declaration by
`Dr. Roberto Tamassia. Ex. 1005. Patent Owner argues that the entirety of
`Dr. Tamassia’s declaration should be given little or no weight because “he
`failed to consider, let alone opine on, how any of the claim features are
`disclosed in asserted references.” PO Resp. 51.
`Petitioner responds that Dr. Tamassia has “offered probative
`testimony on many of the factual inquiries underpinning an obvious
`analysis” that “can certainly ‘assist the tier of fact to understand the evidence
`
`
`6 We address Patent Owner’s Motion to Exclude (Paper 35) certain
`paragraphs of Exhibit 1005 in a separate section, below.
`11
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`or determine a fact in issue.’” Reply 23 (citing Fed. R. Evid. 702).
`Petitioner adds that “no rule requires an expert to opine on the ultimate
`question of obviousness or on every potentially relevant fact at issue for his
`opinion to be admissible or entitled to weight.” Id.
`Patent Owner has not articulated a persuasive reason for giving Dr.
`Tamassia’s declaration, as a whole, little or no weight in our analysis. We
`agree with Petitioner that experts are not required to opine on every relevant
`factual and legal issue in order to be accorded substantial weight. The cases
`Patent Owner relies on do not persuade us otherwise. For example, Patent
`Owner cites Schumer v. Laboratory Computer Systems, Inc., 308 F.3d 1304,
`1315 (Fed. Cir. 2002), for the proposition that “expert testimony ‘must
`identify each claim element, state the witnesses’ interpretation of the claim
`element, and explain in detail how each claim element is disclosed in the
`prior art reference.’” PO Resp. 52. Patent Owner’s quotation, however,
`mischaracterizes Schumer by omitting introductory words necessary to the
`meaning of the quoted sentence. In its entirety, the quoted portion of
`Schumer states the following:
`Typically, testimony concerning anticipation must be testimony
`from one skilled in the art and must identify each claim element,
`state the witnesses’ interpretation of the claim element, and
`explain in detail how each claim element is disclosed in the prior
`art reference. The testimony is insufficient if it is merely
`conclusory.
`
`Schumer, 308 F.3d at 1315–16. The Federal Circuit then adds that it is not
`the task of the courts to “attempt to interpret confusing or general testimony
`to determine whether a case of invalidity has been made out” and “if the
`
`12
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`testimony relates to prior invention and is from an interested party, as here, it
`must be corroborated.” Id. So, instead of laying out a specific, required
`format for the content of all testimony regarding invalidity, as asserted by
`Patent Owner, this portion of Schumer confirms the unremarkable
`proposition that conclusory, overly general, confusing, and self-interested
`testimony should not be relied upon. Id.; see also Koito Mfg. v. Turn-Key-
`Tech, LLC, 381 F.3d 1142, 1152 (Fed. Cir. 2004) (“General and conclusory
`testimony, such as that provided by Dr. Kazmer in this case, does not suffice
`as substantial evidence of invalidity.”). Patent Owner has not shown that the
`whole of Dr. Tamassia’s testimony suffers from any of these failings.
` Under 37 C.F.R. § 42.1(d), we apply the preponderance of the
`evidence standard in determining whether Petitioner has established
`unpatentability. In doing so, it is within our discretion to determine the
`appropriate weight to be accorded the evidence presented, including expert
`opinion, based on the disclosure of the underlying facts or data upon which
`that opinion is based. Thus, we decline to make a determination about Dr.
`Tamassia’s opinion, as a whole. Rather, in our analysis we will consider, as
`it arises, relevant portions of Dr. Tamassia’s testimony and determine the
`appropriate weight to accord that particular testimony.
`
` Prior Art Printed Publication Status of RFC 2401
`Patent Owner asserts that Petitioner has not sufficiently established
`that RFC 2401 qualifies as a printed publication as of its alleged publication
`date. PO Resp. 42–43. We look to the underlying facts to make a legal
`determination as to whether a document is a printed publication. Suffolk
`
`13
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`Techs., LLC v. AOL Inc., 752 F.3d 1358, 1364 (Fed. Cir. 2014). The
`determination of whether a document is a “printed publication” under 35
`U.S.C. § 102(b) involves a case-by-case inquiry into the facts and
`circumstances surrounding its disclosure to members of the public. In re
`Klopfenstein, 380 F.3d 1345, 1350 (Fed. Cir. 2004). Public accessibility is a
`key question in determining whether a document is a printed publication and
`is determined on a case-by-case basis. Suffolk Techs., 752 F.3d at 1364. To
`qualify as a printed publication, a document “must have been sufficiently
`accessible to the public interested in the art.” In re Lister, 583 F.3d 1307,
`1311 (Fed. Cir. 2009).
`In our Decision to Institute, we found that RFC 2401 included indicia
`suggesting a reasonable likelihood that the document was made public
`because (1) RFC 2401 is a dated “Request for Comments” from the
`“Network Working Group,” discussing a particular standardized security
`protocol for the Internet, and (2) it describes itself as a “document [that]
`specifies an Internet standards track protocol for the Internet community,
`and requests discussion and suggestions for improvements. . . . Distribution
`of this memo is unlimited.” Inst. Dec. 7 (citing Ex 1008, 1). On this basis,
`we determined that Petitioner had met its burden for a threshold showing to
`proceed to trial. Id.
`In support of Petitioner’s position, Dr. Tamassia testifies that RFCs
`are “prepared and distributed under a formalized publication process
`overseen by one of several Internet standards or governing bodies,” such as
`the IETF. Ex. 1005 ¶ 148. Dr. Tamassia goes on to discuss an RFC that
`discusses the RFC development and publication process itself—RFC 2026,
`14
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`dated October 1996. Id. at ¶¶ 149–55; Ex. 1036. Dr. Tamassia states that
`“[t]he publication date of each RFC is contained in the RFC, typically in the
`top right corner of the first page of the document” and “[t]his is the date it
`was released for public distribution on the Internet.” Id. at ¶ 152. RFC 2026
`also explains that anyone can obtain RFCs from a number of Internet hosts
`and each RFC “is made available for review via world-wide on-line
`directories.” Ex. 1036, 4; see Ex. 1005 ¶¶ 148–49.
`Patent Owner argues that Petitioner cannot rely on evidence it has
`proffered to support this finding. First, Patent Owner argues that testimony
`by Dr. Tamassia should not be accorded any weight because Dr. Tamassia
`has not been established to have personal knowledge that RFC 2401 was
`actually released to the public in November 1998 nor has Dr. Tamassia
`“been established as someone familiar with, let alone an expert in, the
`workings of the internet Engineering Task Force (IETF)—the body
`responsible for the RFCs.” PO Resp. 44–45.7
`We find Dr. Tamassia’s testimony as to public accessibility of RFCs
`in general to be credible, especially given the independent support of RFC
`2026 (Ex. 1036), the contents of which Patent Owner does not challenge.
`As part of routine discovery (37 C.F.R. § 42.51(b)(1)(ii)), Patent Owner had
`
`
`7 Patent Owner also argues we should give Dr. Tamassia’s testimony on this
`issue no weight because the Petition does not cite to these paragraphs. PO
`Resp. 44 n.5. Patent Owner, itself, however, directed the Board’s attention
`to this testimony in its Preliminary Response (Paper 6, 3–4), and, thus,
`clearly has had adequate notice of its contents such that it may respond with
`no resulting prejudice.
`
`15
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`the opportunity to cross-examine Dr. Tamassia, but does not point us to any
`discussion of this issue. Moreover, RFC 2401’s contents are consistent with
`the publication process described by RFC 2026 and Dr. Tamassia, including
`the inclusion of a date “November 1998” on the top right corner of the first
`page of the document. In addition, this document—a request for suggestions
`and improvements for an Internet standards protocol, having no indication of
`being a mere draft or internal paper—is precisely the type of document
`whose very purpose is public disclosure.
`“A given reference is ‘publicly accessible’ upon a satisfactory
`showing that such document has been disseminated or otherwise made
`available to the extent that persons interested and ordinarily skilled in the
`subject matter or art exercising reasonable diligence, can locate it.” SRI
`Int’l, Inc. v. Internet Sec. Sys., Inc. 511 F.3d 1186, 1194 (Fed. Cir. 2008)
`(quoting Bruckelmyer v. Ground Heaters, Inc., 445 F.3d 1374, 1378 (Fed.
`Cir. 2006)). We find that Petitioner has established, by a preponderance of
`the evidence, that RFC 2401(dated November 1998) was sufficiently
`disseminated to persons of ordinary skill interested in computer networking
`and security to be deemed “publicly accessible” at the relevant time.
`Therefore, on this record, we determine RFC 2401 qualifies as a prior art
`printed publication under 35 U.S.C. § 102(b).
`
` Beser Disclosure
`Beser describes a system that establishes an IP (internet protocol)
`tunneling association on a public network between two end devices. See Ex.
`1007, Abs. Figure 1 of Beser is reproduced below.
`
`16
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`
`
`Figure 1 of Beser illustrates a network system, including public network 12,
`network devices 24 and 26, private network 20, trusted third-party network
`device 30, and modified routers or gateways 14 and 16. Ex. 1007, 3:60–
`4:19. Beser describes edge routers, such as network devices 14 and 16, as
`devices that route packets between public networks 12 and private networks
`20. Id. at 4:18–24. End devices 24 and 26 include network multimedia
`devices, VoIP devices, or personal computers. Id. at 4:43–54.
`Beser’s system “increases the security of communication on the data
`network” by providing and hiding, in packets, “private addresses” for
`
`17
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`originating device 24 and terminating device 26 on the network. See id. at
`Abs., Fig. 1, Fig. 6. To begin a secure transaction, requesting device 24
`sends a request to initiate a tunneling connection to network device 14. Id.
`at 8:21–47. This request includes a unique identifier for the terminating end
`of the tunneling association—terminating device 26. Id.at 7:64–8:3. The
`packets used to transfer this unique identifier across the public network
`“may require encryption or authentication to ensure that the unique identifier
`cannot be read on the public network.” Id. at 11:22–25. Beser discloses, as
`background prior art, known forms of encryption for the information inside
`these packets, including IP Security (“‘IPsec’”). Id. at 1:54–56. Once
`network device 14 receives the request, it passes the request on to trusted-
`third-party network device 30. Id. at 8:3–4, 8:48–9:5.
`Trusted-third-party network 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 device 16 and terminating device 26. See id. at 11:32–
`58. 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. 1007, 11:26–
`36, Figs. 1, 4, 5.8 As indicated, DNS 30 includes, in a directory database or
`
`
`8 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. 1007, 3:26–30.
`18
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`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 “IP
`58 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 16”––including domain names as unique identifiers, as
`noted above. Id. at 11: 2–5, 32–36, 48–55.
`Trusted-third-party network device 30 then assigns, by negotiation,
`private IP addresses to requesting network device 24 and terminating device
`26. Id. at 9:29–35, 12:17–19, Figs. 4, 5. In an exemplary embodiment,
`trusted-third-party network (DNS) device 30 performs the 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 11: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- Internet-Protocol)] association by methods
`known to those skilled in the art.” Id. at 12:33–37.
`The negotiated private IP addresses may be “inside the payload fields
`84 of the IP 58 packets and may be hidden from hackers on the public
`network 12.” Id. at 12:15–16. The IP packets “may require encryption or
`authentication to ensure that the unique identifier cannot be read on the
`19
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`public network 12.” Id. at 11:22–25; see also id. at 20:11–14 (disclosing
`encryption or authentication of first IP 58 packet to ensure hiding the
`address of the public IP address of network device 16). Beser also discloses,
`as background prior art, known forms of encryption for “the information
`inside the IP packets,” including IPsec. Id. at 1:54–56.
`
` RFC 2401 Disclosure
`RFC 2401 describes the security services offered by the IPsec
`protocols, including “access control, connectionless integrity, data origin
`authentication, [and] . . . confidentiality (encryption).” Ex. 1008, 3–4. RFC
`2401 describes IPsec further, as follows:
`IPsec allows the user (or system administrator) to control
`the granularity at which a security service is offered. For
`example, one can create a single encrypted tunnel to carry all the
`traffic between two security gateways or a separate encrypted
`tunnel can be created for each TCP connection between each pair
`of hosts communicating across these gateways.
`Id. at 7. The “security services use shared secret values (cryptographic keys)
`. . . . (The keys are used for authentication/integrity and encryption
`services).” Id.
`
` Claims 1 and 14
`Petitioner contends that the subject matter of independent claims 1
`and 14 of the ’009 patent would have been obvious over the combination of
`Beser and RFC 2401. Pet. 28–50; Reply 2–18. Petitioner supports its
`arguments with Declaration testimony of Dr. Tamassia. Ex. 1005. Although
`claim 1 recites “a network device” and claim 14 recites a “method executed
`by a first network device for communicating with a second network device,”
`
`20
`
`
`
`
`IPR2015-00812
`Patent 8,850,009 B2
`
`
`the two claims encompass substantially the same subject matter. Both
`Petitioner and Patent Owner argue claims 1 and 14 together. Pet. 28–50; PO
`Resp. 27–41; Reply 2–18. We, therefore, analyze the two independent
`claims together.
`
`1. Petitioner’