`
`
`
`
`
`
`
`Trials@uspto.gov
`Tel: 571-272-7822
`
`Paper 29
`Entered: June 22, 2017
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`
`Case IPR2016-00331
`Patent 8,504,696 B2
`
`
`Before Vice Chief Administrative Patent Judge MICHAEL P. TIERNEY,
`KARL D. EASTHOM, and STEPHEN C. SIU, Administrative Patent
`Judges
`
`EASTHOM, Administrative Patent Judge.
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`
`
`
`
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`I. INTRODUCTION
`A. Background
`Petitioner, Apple Inc., filed a Petition (Paper 1, “Pet.”) requesting an
`inter partes review of claims 1–11, 14–25, and 28–30 (the “challenged
`claims”) of U.S. Patent No. 8,504,696 B2 (Ex. 1001, “the ’696 patent”).
`Patent Owner, VirnetX Inc., filed a Preliminary Response. Paper 6 (“Prelim.
`Resp.”).
`Subsequent to institution (Paper 9, “Inst. Dec.”), Patent Owner filed a
`Patent Owner Response (Paper 14, “PO Resp.”), and Petitioner filed a Reply
`(Paper 17, “Pet. Reply”). Patent Owner also filed a Motion to Exclude
`evidence (Paper 20), Petitioner filed an Opposition (Paper 23), and Patent
`Owner filed a Reply to the Opposition (Paper 24).
`The record includes a transcription of the Oral Hearing held on March
`27, 2017. Paper 28. This Final Written Decision issues concurrently with
`the final written decision involving the ’696 patent in Apple Inc. v. VirnetX
`Inc., IPR2016-00332 (PTAB June 22, 2017).
`The Board has jurisdiction under 35 U.S.C. § 6(c). This Final Written
`Decision issues pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73. For
`the reasons that follow, we determine that Petitioner has shown by a
`preponderance of the evidence that claims 1–11, 14–25, and 28–30 of the
`’696 patent are unpatentable.
`B. Related Matters
`Petitioner indicates that the ’696 patent “has not been asserted in
`litigation or the subject of other IPR proceedings.” Pet. 2. Petitioner
`concurrently filed a petition challenging the same claims in the ’696 patent
`in IPR2016-00332. Id. at 5. Petitioner and Patent Owner provide listings of
`
`2
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`district court actions, other inter partes review, and inter partes
`reexamination proceedings challenging related patents. See Pet. 2–5, Paper
`5, 2–15; see also VirnetX, Inc. v. Cisco Systems, Inc., 767 F.3d 1308, 1317–
`19 (Fed. Cir. 2014) (addressing ancestor VirnetX patents); VirnetX Inc. v.
`Apple Inc., 665 F. App’x 880 (Fed. Cir. 2016) (affirming Apple Inc. v.
`VirnetX Inc., Cases IPR2014-00237, IPR2014-00238 (final written decisions
`“’237 FWD,” “’238 FWD,” or generally, “’237 IPR,” “’238 IPR”) (PTAB
`May 11, 2015) (appealed by VirnetX))1; VirnetX Inc. v. Apple Inc., 671 F.
`App’x. 786 (Fed. Cir. 2016) (affirming Apple Inc. v. VirnetX Inc., Cases
`IPR2014-00403, IPR2014-00404, (PTAB July 29, 2015) (appealed by
`VirnetX)); Apple Inc. v. VirnetX Inc., Cases IPR2014-00481, IPR2014-
`00482 (PTAB August 24, 2015) (appealed by VirnetX))2; Apple Inc. v.
`VirnetX Inc., Case IPR2015-00811 (PTAB Sept. 8, 2016) (appealed by
`VirnetX); Apple Inc. v. VirnetX Inc., Case IPR2015-00812 (PTAB Aug. 30,
`2016) (appealed by VirnetX); Apple Inc. v. VirnetX Inc., IPR2015-00870
`(PTAB Sept. 28, 2016) (appealed by VirnetX); Apple Inc. v. VirnetX Inc.,
`IPR2015-00871 (PTAB Sept. 28, 2016) (appealed by VirnetX). Some of
`these related cases involve overlapping claim construction and prior art
`issues with the instant case as discussed further below.
`
`
`1 The court affirmed the ’237 FWD and the ’238 FWD without reaching the
`merits of the ’237 FWD. See 665 F. App’x. at 889 (In re Gleave, 560 F.3d
`1331, 1338 (Fed. Cir. 2009) (“declining to address alternative grounds of
`invalidity when the court upholds one such ground”).
`2 The court affirmed the four final written decisions without reaching the
`merits of the ’404 and ’482 proceedings. See 671 F. App’x at 787 (finding
`“no error in the Patent Trial and Appeal Board’s (‘the Board’) claim
`constructions or findings in the 403 and 481 proceedings).
`
`3
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`C. Instituted Grounds of Unpatentability
`We instituted under 35 U.S.C. § 103 on the ground that combination
`of Beser3 and RFC 24014 would have rendered obvious claims 1–11, 14–25,
`and 28–30 of the ’696 patent. Petitioner relies on, inter alia, the
`“Declaration of Roberto Tamassia Regarding U.S. Patent Nos. 8,540,696.”
`Ex. 1005 (the “Tamassia Declaration”). Patent Owner relies on, inter alia,
`the “Declaration of Fabian Monrose, Ph.D.” Ex. 2018 (the “Monrose
`Declaration”), originally filed in a related case, Apple Inc. v. VirnetX Inc.,
`IPR2015-00866 (PTAB Jan. 25, 2016) (Ex. 2018).
`D. The ’696 Patent
`The ’696 patent describes secure methods for communicating over the
`Internet. Ex. 1001, Abstract, 10:3–8. Specifically, the ’696 patent describes
`“the automatic creation of a virtual private network (VPN) in response to a
`domain-name server look-up function.” Id. at 39:23–25. This automatic
`creation employs a modified Domain Name Server, which may include a
`conventional Domain Name Server (DNS) and a DNS proxy (id. at 40:20–
`40:22).
`
`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:26–32.
`
`
`3 U.S. Patent No. 6,496,867 B1 (Ex. 1007).
`4 S. Kent and R. Atkinson, Security Architecture for the Internet Protocol,
`Request for Comments: 2401, BBN Corp., November 1998 (Ex. 1008).
`
`4
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`The DNS proxy of the modified DNS server intercepts all DNS
`lookup requests, determines whether the user has requested access to a
`secure site (using for example, a domain name extension or an internal
`table of secure sites), and if so, whether the user has sufficient security
`privileges to access the requested site. Id. at 40:26–35. 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–53. If the user has requested access to a secure site
`to which it has sufficient security privileges, the DNS proxy requests a
`gatekeeper to create a VPN between the user’s computer and the
`secure target site. Id. at 40:31–42. The DNS proxy 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:39–44.
`The VPN is “preferably implemented using the IP address ‘hopping’
`features,” (i.e., changing IP addresses based upon an agreed upon algorithm)
`described elsewhere in the ’696 patent, “such that the true identity of the two
`nodes cannot be determined even if packets during the communication are
`intercepted.” Id. at 40:4–8. The system may hide the identities (i.e.,
`anonymity, a form of security) by encrypting parts of packets, including the
`true final destination. See id. at 1:50–56, 10:3–10:67.
`“Tunneled Agile Routing Protocol (TARP)” (id. at 3:16–18) routers
`122–127, described as “special servers or routers” (id. at 10:4–5) along the
`hopping path, “are similar to regular IP routers 128–132” (id. at 10:5–6).
`See id. Fig. 2. TARP routers determine the “next-hop in a series of TARP
`router hops” (id. at 10:15–16) in the path and the final destination, by
`authenticating or decrypting transmitted encrypted parts of packets to find
`
`5
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`the next-hop TARP router address. Id. at 3:36–63, 10:23–67. “Once the
`outer layer of encryption is removed, the TARP router determines the final
`destination. Each TARP packet 140 undergoes a minimum number of hops
`to help foil traffic analysis.” Id. at 3:47–50 “[T]he hops may be chosen at
`random.” Id. at 3:50–51. “The fact that different packets take different
`routes provides distinct advantages by making it difficult for an interloper to
`obtain all the packets forming an entire multi-packet message.” Id. at 3:56–
`59. The system also may encrypt data in the packets. See id. at 1:50–56,
`4:7–12.
`
`E. Illustrative Challenged Claim 1
`Independent claims 1 and 16 recite the same limitations respectively
`in system and method format. Compare Ex. 1001, 56:8–23, with id. at 57:1–
`14. All other challenged claims depend from claims 1 or 16. Claim 1,
`illustrative of the challenged claims, follows:
`
`1. A system for connecting a first network device and a
`
`second network device, the system including one or more
`servers configured to:
`
`intercept, from the first network device, a request to look
`up an internet protocol (IP) address of the second network
`device based on a domain name associated with the second
`network device;
`
`determine, in response to the request, whether the second
`network device is available for a secure communications
`service; and
`
`initiate a virtual private network communication link
`between the first network device and the second network device
`based on a determination that the second network device is
`available for the secure communications service, wherein the
`secure communications service uses the virtual private network
`communication link.
`Ex. 1001, 56:8–23.
`
`6
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`II. ANALYSIS
`A. Claim Construction
`In an inter partes review, the Board construes claims by applying the
`broadest reasonable interpretation in light of the specification. 37 C.F.R.
`§ 42.100(b); Cuozzo Speed Techs., LLC v. Lee, 136 S. Ct. 2131, 2144–46
`(2016) (upholding the use of the broadest reasonable interpretation standard
`under 37 C.F.R. § 42.100(b)). Under this standard, absent any special
`definitions, claim terms or phrases are given their ordinary and customary
`meaning, as would be understood by one of ordinary skill in the art, in the
`context of the entire disclosure. In re Translogic Tech., Inc., 504 F.3d 1249,
`1257 (Fed. Cir. 2007).
` For the purposes of this Decision, only the claim terms or clauses
`below need express construction. See Vivid Techs., Inc. v. Am. Sci. & Eng’g,
`Inc., 200 F.3d 795, 803 (Fed. Cir. 1999) (only those terms in controversy
`need to be construed and only to the extent necessary to resolve the
`controversy).
`
`“intercept . . . a request”
`Relying partly on the ’237 FWD, Petitioner proposes that we construe
`the claim 1 phrase “intercept . . . a request” as “receiving a request
`pertaining to a first entity at another entity.” Pet. 12 (citing ’237 FWD, 10–
`12).5 Claim 16 recites a similar “intercepting a request” phrase. Patent
`
`
`5 Claim 1 of U.S. Patent No. 8,504,697 (“’697 patent”) at issue in the’237
`FWD (see supra notes 1 and infra note 6) recites a similar clause:
`“intercepting, from the first network device, a request to look up an internet
`protocol (IP) address of the second network device based on a domain name
`associated with the second network device.” ’237 FWD 4. The ’697 and
`’696 patents each have common ancestor patents at issue in Cisco, 767 F.3d
`
`7
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`Owner states that “[n]o construction [is] necessary; alternatively,” Patent
`Owner proposes that the phrase means “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. 40. Patent Owner contends
`that its “construction appropriately captures the notion of performing an
`additional evaluation on a request related to establishing a virtual private
`network communication link, beyond conventionally resolving it and
`returning the address.” Id. at 43.
`Patent Owner’s contentions are not persuasive. Patent Owner fails to
`explain sufficiently why the notion of “performing an additional evaluation”
`constitutes an implicit part of the claimed intercept clause. Addressing
`similar arguments by Patent Owner, a Board panel made a similar
`determination in the ’237 FWD relied upon by Petitioner. ’237 FWD 11
`(“the record show[s] that the additional functionality urged by Patent Owner
`should not be imported into the intercepting phrase”).
`To support its construction, Patent Owner states “a request to look up
`an address of a secure target site 2604 or unsecure target site 2611 (a first
`entity) is received at a DNS server 2602 (a second entity).” PO Resp. 18
`
`
`at 1308: The ’696 patent is a continuation of an application, which like the
`’697 patent, is a continuation of U.S. Patent No. 7,921,211, which is a
`continuation of U.S. Patent No. 7,418,504 (“’504 patent”), which is a
`continuation-in-part of U.S. Patent No. 6,502,135 (“’135 patent)––three of
`the four patents at issue in Cisco. See 767 F.3d at 1313. (The fourth patent
`at issue in Cisco, is U.S. Patent No. 7,490,151 (“’151 patent”), a division of
`the ’135 patent.)
`
`8
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`(citing Ex. 1001, Fig. 26). Patent Owner explains “the claimed
`embodiments differ from [a] 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.” Id.
`As one example, Patent Owner contends that DNS proxy 2610 (part of
`DNS server 2602) “may intercept the request and ‘determine whether access
`to a secure side has been requested.’” Id. (quoting Ex. 1001, 40:26–35).
`Patent Owner provides two additional “example” DNS functions, but fails to
`describe which examples are necessary to the construction of the intercept
`clause. See id. (listing examples: 1) determining if a user has sufficient
`security privileges to access the site; 2) transmitting a message to a gate
`keeper to request a VPN creation; and 3) resolving an address and returning
`it to the DNS). These additional disclosed functions of a DNS fail to show
`that the “intercept” clause at issue requires the unclaimed additional
`functionality. The intercept clause does not recite a DNS.
`Furthermore, the disclosed embodiment cited by Patent Owner
`supports Petitioner’s proposed claim construction, as DNS server 2602
`performs the intercept by “receiving a request pertaining to a first entity
`[2604 or 2611] at another entity [2602].” See Ex. 1001, Fig. 26. As the
`’696 patent discloses, in one embodiment, a “single server” having “the
`functions of DNS proxy 2610 and DNS server 2609” (Ex. 1001, 40:63–65,
`Fig. 26) “intercepts all DNS lookup functions” (id. at 40:26–27). In other
`words, pursuant to requests for a connection to a secure or unsecure device
`(first entity), intercepting DNS server 2602 (second entity) returns the IP
`address of the first entity after looking up the domain name. See id. at
`40:26–34.
`
`9
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`Based on the foregoing discussion, we adopt Petitioner’s proposed
`construction that the phrase “intercept . . . a request” means “receiving a
`request pertaining to a first entity at another entity.”6
`B. Prior Art Printed Publication Status of RFC 2401
`Patent Owner asserts that Petitioner fails to show that RFC 2401 was
`publicly accessible as of November 1998 (the date recited on each of its
`pages). PO Resp. 42 (citing Ex. 1008). On this basis, according to Patent
`Owner, Petitioner cannot rely upon RFC 2401 as prior art to meet its burden
`of showing obviousness of the challenged claims over the combination of
`Beser and RFC 2401. See id.
`The determination of whether a given reference qualifies as a prior art
`“printed publication” involves a case-by-case inquiry into the facts and
`circumstances surrounding the reference’s disclosure to members of the
`public. In re Klopfenstein, 380 F.3d 1345, 1350 (Fed. Cir. 2004). On its
`face, RFC 2401 is a dated “Request for Comments” from the “Network
`Working Group,” discussing a particular standardized security protocol for
`the Internet. Ex. 1008, 1. Moreover, RFC 2401 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.” Id. These
`
`
`6 See ’237 FWD 12 (reaching the same construction). As also noted in the
`’237 FWD (a final judgment affirmed by our reviewing court, supra note 1),
`“Patent Owner concedes that “[t]he Decision’s construction [of intercepting
`a request] addresses a common aspect of a conventional DNS and the
`disclosed embodiments, namely that a request to look up an address of one
`entity may be received at another entity.” ’237 FWD 24 (quoting ’237
`patent owner response 26) (emphases added).
`
`10
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`indicia suggest that the document was made available to the public (over the
`Internet), in order to obtain feedback prior to implementation of the standard
`it describes.
`To bolster its showing, Petitioner provides evidence suggesting that
`RFC 2401 would have been accessible to the interested public. For
`example, Petitioner relies on testimony by Dr. Tamassia, and an article dated
`March 15, 1999, referencing RFC 2401 availability on a website. Pet. 25–26
`(citing Ex. 1005 ¶¶ 115–21; Ex. 1065, 3). Petitioner also explains that RFC
`2401 describes the IPsec protocol promulgated by the Internet Engineering
`Task Force (IETF). Id. Petitioner provides a declaration by Sandy Ginoza,
`who, acting as a designated representative of the IETF, previously testified
`that RFC 2401 was published on the RFC Editor’s website and was publicly
`available in November 1998. Id. at 25–26 (citing Ex. 1060 ¶¶ 105–07; Ex.
`1063, 39:14–24). Petitioner provides additional documentary evidence, in
`the form of an August 16, 1999 magazine article (Ex. 1064, 9 (discussing
`RFC 2401 and IPsec protocols and stating “[a]ll of these documents are
`available on the IETF website”)), and an October 1996 RFC 2026
`publication (Ex. 1036, 5–6 (explaining that any interested person can obtain
`RFC documents from a number of Internet hosts using anonymous FTP,
`gopher, WWW, and other document-retrieval systems)). Id. at 25–26 (citing
`Ex. 1064, 9; Ex.1036, 5–6).
`Patent Owner characterizes Petitioner’s showing as insufficient. PO
`Resp. 43–51. Patent Owner contends that Sandy Ginoza and Dr. Tamassia
`lack personal knowledge about the publication of RFC 2401, and challenges
`other evidence as too general and lacking a sufficient foundation. See PO
`Resp. 44–47 (discussing Pet. 25–26, Ex. 1036, 4–6; Ex. 1060–65)). Patent
`
`11
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`Owner does not contest Petitioner’s characterization of the two magazine
`articles, Exhibits 1064 and 1065, other than to refer to them as follows:
`“Exhibit 1064 is allegedly an article from InfoWorld magazine (dated
`August 16, 1999) and Exhibit 1065 is allegedly an article from
`NetworkWorld magazine (dated March 15, 1999).” PO Resp. 45.
`RFC 2026 states it reflects “generally accepted practices” for RFC
`documents and states “any interested person can obtain RFCs from a number
`of Internet hosts.” See PO Resp. 47 n.9 (citing Ex. 1036, 4, discussing Inst.
`Dec. 13). Patent Owner contends that Petitioner has not shown that this
`evidence of “generally accepted practices” “is accurate.” Id. Patent Owner
`notes that the document represents “flexible” standards, so that “there is no
`assurance that the procedures of RFC 2026 that were quoted by Petitioner
`were actually applied.” Id. at 47.
` 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.7
`As part of routine discovery, see 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. Ex. 1008, 1. In addition, this document—a
`request for suggestions and improvements for an Internet standards protocol,
`
`7 As addressed below, Patent Owner objects and moves to dismiss a number
`of Exhibits based on hearsay and relevancy. See Paper 20 (Motion to
`Exclude).
`
`12
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`having no indication of being a mere draft or internal paper—is precisely the
`type of document whose very purpose is public disclosure, including on the
`Internet. Both of the magazine articles, Exhibits 1064 and 1065, further
`corroborate the indicia of availability on the face of RFC 2401, although
`they are not necessary to our finding of public accessibility. We do not rely
`on the testimony of Sandy Ginoza, Exhibits 1060 and 1063, which Patent
`Owner seeks to exclude as discussed further below.
`Petitioner also points out that at least one District Court characterized
`RFCs as having “been written and circulated”: “[M]uch of the development
`and technical management of the Internet has been by the consensus of
`Internet users. This is evidenced . . . by IETF and the more than 2000 RFC’s
`which have been written and circulated.” Paper 23, 6 n.3. (quoting
`PGMedia, Inc. v. Network Sols., Inc., 51 F. Supp. 2d 389, 406 (S.D.N.Y.
`1999)).
`“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 disseminated and
`made available 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).
`
`13
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`C. Tamassia Declaration (Ex. 1005)
`Patent Owner argues that the entirety of the Tamassia Declaration
`should be given little or no weight because Dr. Tamassia “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 or determine a fact in issue.’” Pet. Reply 22–23 (quoting Fed.
`R. Evid. 702). Petitioner also contends “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. at 23.
`Patent Owner does not articulate 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
`upon which Patent Owner relies do not show 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–53. 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,
`
`14
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`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
`testimony relates to prior invention and is from an interested party, as here, it
`must be corroborated.” Id. at 1316. 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.
`Co., Ltd. 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 does not show that the whole of Dr. Tamassia’s testimony suffers
`from any of these failings.
`Under 35 U.S.C. § 316(e), the preponderance of the evidence standard
`governs in determining whether Petitioner establishes unpatentability. We
`exercise discretion to determine the appropriate weight to accord the
`evidence presented, including expert opinions, based on the underlying facts
`supporting the opinion. We accord relevant portions of Dr. Tamassia’s
`testimony the appropriate weight based on that particular testimony and
`supporting evidence.
`
`15
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`D. Obviousness Over Beser and RFC 2401
`1) Overview of Beser
`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 follows:
`
`
`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 network devices 24 and 26 as telephony devices,
`multimedia devices, VoIP devices, or personal computers. Id. at 4:43–52.
`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
`
`16
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`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 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 devices 26. See id. at
`11:32–58. DNS 30 associates terminating network device 26, based on its
`unique identifier in the request, with a public IP address for router device 16.
`See id. at 11:26–36. 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. The negotiated private IP
`addresses are “isolated from a public network such as the Internet,” and “are
`not globally routable.” Id. at 11:62–65.
`2) Overview of RFC 2401
`RFC 2401 describes security services using IPsec protocols on the
`Internet (Ex. 1008, 3) including “access control, connectionless integrity,
`data origin authentication, [and] . . . confidentiality (encryption)” (id. at 4).
`According to RFC 2401, one of the IPsec goals is to provide “confidentiality
`(encryption).” Id. at 4. Using IPsec protocols
`
`17
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`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.
`3) Claims 1 and 16
`i) Petitioner’s Contentions
`Petitioner asserts that Beser’s streaming audio/video examples, in
`light of the encryption teachings based on the combination of Beser and
`RFC 2401, would have rendered obvious claims 1 and 16. See Pet. 29–30.
`According to Petitioner, Beser teaches or suggests most of the limitations of
`claims 1 and 16, with Beser and RFC 2401 at least suggesting encryption of
`data. See Pet. 28–34. “[T]o limit the impact from any potential disputes or
`related legal proceedings over the construction” of a VPN communications
`link, Petitioner contends that even if a VPN communications link requires
`data encryption, the combination of Beser and RFC 2401 would have
`rendered such a VPN link obvious. See id. at 29.8
`
`
`8 According to Cisco, “the [related ’151] patent consistently differentiates
`between ‘security’ and ‘encryption.’ Both the claims and the specification
`of the ’151 patent make clear that encryption is a narrower, more specific
`requirement than security.” Cisco, 767 F.3d at 1323. Cisco refers to
`“physical security” on private networks that do not necessarily have
`encryption, notes that the VirnetX patents (at issue in that litigation) describe
`encryption as one possible way to tackle data security, and notes that the
`district court’s claim construction for security only requires encryption on
`insecure paths (for example, on the Internet––as opposed to physically
`secure private networks). See id. at 1321–22.
`
`18
`
`
`
`IPR2016-00331
`Patent 8,504,696 B2
`
`Addressing the preambles claims 1 and 16, Petitioner contends that
`the claimed first network device reads on Beser’s originating end device 24,
`and that the claimed second network device reads on Beser’s terminating
`end device 26. See id. at 35–36 (citing Ex. 1007, 8:15–20, 21:52–62, 22:2–
`22; Ex. 1005 ¶¶ 127, 195–96); Ex. 1007, Fig. 1. Petitioner points out that
`Beser discloses various end devices including WebTV devices and VoIP
`devices that communicate over a private tunneling association established by
`trusted-third party network device 30 “with the help of first and second
`network devices” 14 and 12. See Pet. 35 (citing Ex. 1007, 4:43–54, 7:64–66,
`8:15–20, 14:51–67, 10:22–36, 10:55–66, 14:51–67; Ex. 1005 ¶¶ 131, 169,
`173, 177, 188–93, 198).
`Regarding the “intercept” clause of claim 1, Petitioner explains that
`Beser’s trusted-third-party network device 30 (which includes a DNS), first
`network device 14, and second network device 16, work together such that
`devices 30 and 14 singly or together intercept the request, and then look up
`(also using device 16 in some embodi
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
