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