Trials@uspto.gov
`Tel: 571-272-7822
`
`Paper 39
`Entered: September 28, 2016
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`
`Case IPR2015-00866
`Patent 8,458,341 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 39
`Entered: September 28, 2016
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`
`Case IPR2015-00866
`Patent 8,458,341 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-00866
`Patent 8,458,341 B2
`
`INTRODUCTION
`
` Background
`Petitioner, Apple Inc., filed a Petition (Paper 1, “Pet.”) requesting
`inter partes review of claims 1–11, 14–25, and 28 (the “challenged claims”)
`of U.S. Patent No. 8,458,341 B2 (Ex. 1001, “the ’341 patent”). Patent
`Owner, VirnetX Inc., filed a Preliminary Response. Paper 6 (“Prelim.
`Resp.”). We granted the Petition, instituting trial on whether claims 1–11,
`14–25, and 28 are unpatentable as obvious over Beser1 and RFC 2401.2
`Paper 8 (“Inst. Dec.”).
`During the trial, Patent Owner filed a Response (Paper 23, “PO
`Resp.”), and Petitioner filed a Reply (Paper 26, “Reply”). Additionally,
`Patent Owner filed a Motion to Exclude evidence. Paper 30. A consolidated
`hearing for oral arguments in this inter partes review and Cases IPR2015-
`00868, IPR2015-00870, and IPR2015-00871 was held June 27, 2016. A
`transcript of the hearing appears in the record. Paper 38 (“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–11, 14–25, and 28 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-00866
`Patent 8,458,341 B2
` The ’341 Patent
`The ’341 patent describes secure methods for communicating over the
`Internet. Ex. 1001, 10:9–11. Specifically, the ’341 patent describes “the
`automatic creation of a virtual private network (VPN) in response to a
`domain-name server look-up function.” Id. at 39:24–26. This automatic
`process makes use of a modified Domain Name Server as opposed to a
`conventional Domain Name Server (DNS), which is described 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:27–33.
`The modified DNS server may include both a conventional
`DNS and a DNS proxy. Id. at 40:20–22. 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:26–32. 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:49–52. 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:32–38. The DNS proxy
`then returns to the user the resolved address passed to it by the
`3
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`gatekeeper, which need not be the actual address of the destination
`computer. Id. at 40:38–44.
`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:5–9.
`
` The Challenged Claims
`Claims 1 and 15 of the challenged claims are independent and similar
`in scope. Claims 2–11 and 14 depend either directly or indirectly from
`claim 1 and claims 16–25 and 28 depend either directly or indirectly from
`claim 15. 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 request to look up an internet protocol (IP) address of a
`second network device based on a domain name associated
`with the second network device;
`receive, following interception of the request and a determination
`that the second network device is available for the secure
`communications service an indication that the second
`network device is available for the secure communications
`service, the requested IP address of the second network
`device, and provisioning information for a virtual private
`network communication link;
`connect to the second network device, using the received IP
`address of the second network device and the provisioning
`4
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`information for the virtual private network communication
`link; and
`communicate with the second network device using the secure
`communications service via the virtual private network
`communication link.
`Ex. 1001, 56:2–25.
`
`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 has construed claim terms similar to
`those at issue here in several other proceedings challenging patents related to
`the ’341 patent. See, e.g., 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); Apple Inc. v.
`VirnetX Inc., IPR2015-00812 (PTAB Aug. 30, 2016) (Paper No. 43) (final
`written decision “’812 FWD,” or generally, “’812 IPR”); 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).
`
` Interception of the Request
`Petitioner proposes we construe the term “interception of a request” as
`including “receiving a request pertaining to a first entity at another entity.”
`Pet. 9–10. In its Preliminary Response, Patent Owner argued that no
`5
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`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 a virtual
`private network communication link.” Prelim. Resp. 24–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. 5–6.
`In its Response, Patent Owner continues to assert that “[n]o
`construction is necessary” for the term “interception of the 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
`reference arguments from the Preliminary Response Prelim. Resp. 24–28).3
`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. Here, 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 request”
`includes receiving a request pertaining to a first entity at another entity.
`
`
`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.
`
`6
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`Patent Owner argues that the claimed embodiments of the ’341 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. 26.
`According to Patent Owner, “Petitioner’s construction overlooks the aspects
`distinguishing the ‘intercepting’ phrase from conventional DNS.” Id. at 27.
`Instead, Patent Owner asserts that its proposed construction “appropriately
`captures” the additional functionality. Id.; PO Resp. 4–5.
`Patent Owner’s arguments and the record, however, show that Patent
`Owner’s proposed construction adds unnecessary functionality to
`“interception of a request.” According to Patent Owner’s arguments,
`another recited phrase in claim 1 (and a similar phrase in claim 15), captures
`the functionality, in particular, the “determination” limitation of claim 1.
`See Prelim. Resp. 27 (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. 9–10. 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
`7
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`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 ’341 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 Apple Inc. v. VirnetX
`Inc., IPR2015-00812 (PTAB June 8, 2016) (Paper No. 42) (“’812 Tr.”)
`34:19–37:11 (proceeding involving a related patent construing the term
`“interception of a DNS request” in virtually identical context).
`Patent Owner alleges that Dr. Tamassia adopted an “intent”
`requirement in the “interception” clause—meaning a request must be
`“intended for” or “ordinarily received by” another entity than that
`which ultimately intercepts it. PO Resp. 28–29 & n.3. Petitioner
`disagrees with any intent requirement, and contends that Patent Owner
`mischaracterizes Beser’s disclosure and Dr. Tamassia’s testimony.
`Reply 12–15.
`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. 28–31. 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 ’341 patent supports or requires such “intent”
`as part of the broadest reasonable construction of the term
`
`8
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`“interception of a 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 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 reasonable
`construction of the term “interception of a request” includes “receiving a
`request pertaining to a first entity at another entity.”
`
` Virtual Private Network (VPN) Communication Link
`Petitioner and Patent Owner propose different constructions of the
`term VPN Communication Link. Pet. 14–15, PO Resp. 8. Petitioner argues
`that the claimed VPN Communication Link is “a transmission path between
`two devices 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.” Pet. 14.
`Patent Owner argues that Petitioner’s proposed construction
`“contradicts the plain language of the claims, is internally inconsistent, and
`is inconsistent with the ’341 patent specification and prosecution history.”
`PO Resp. 8. Instead, Patent Owner asserts the correct construction should be
`“‘a communication path between two devices in a [VPN]’, where a [VPN] is
`
`
`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-00866
`Patent 8,458,341 B2
`
`a network of computers which privately and directly communication with
`each other by encrypting traffic on insecure paths between the devices where
`the communication is both secure and anonymous.” Id.
`For purposes of this Decision, we need not resolve the dispute
`between the parties on this term because, as discussed below, we determine
`that Petitioner has shown, by a preponderance of the evidence, that this
`limitation, under either party’s proposed construction, would have been
`obvious over the combination of Beser and RFC 2401.
`
`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 ¶ 148; see Pet. 8. 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. 23–245 (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
`
`
`5 Patent Owner does not appear to renew this argument in its Response. See
`PO Resp. 2 n.1.
`
`10
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`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. 2018 ¶ 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
`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 ’341 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
`
`
`6 We address Patent Owner’s Motion to Exclude (Paper 30) certain
`paragraphs of Exhibit 1005 in a separate section, below.
`11
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`failed to consider, let alone opine on, how any of the claim features are
`disclosed in asserted references.” PO Resp. 44.
`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
`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. 45. 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
`
`12
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`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
`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
`
`13
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`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. 49. We look to the underlying facts to make a legal
`determination as to whether a document is a printed publication. Suffolk
`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. 6–7 (citing Ex 1008, 1). On this
`
`14
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`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 ¶ 186. Dr. Tamassia goes on to discuss an RFC that
`discusses the RFC development and publication process itself—RFC 2026,
`dated October 1996. Id. at ¶¶ 187–93; 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 ¶ 190. 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 ¶¶ 186–89.
`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. 50–52.7
`
`
`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. 51 n.5. Patent Owner, itself, however, directed the Board’s attention
`to this testimony in its Preliminary Response (Paper 6, 5–6), and, thus,
`15
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`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
`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 and made available on the Internet or otherwise 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
`
`
`clearly has had adequate notice of its contents such that it may respond with
`no resulting prejudice.
`
`16
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`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.
`
`
`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
`
`17
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`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
`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–
`
`18
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`36, Figs. 1, 4, 5.8 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 “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.
`
`
`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.
`19
`
`
`
`
`IPR2015-00866
`Patent 8,458,341 B2
`
`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
`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
`24
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
