Paper No. 26
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`––––––––––––––––––
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`––––––––––––––––––
`
`APPLE INC.,
`Petitioner,
`
`v.
`VIRNETX INC.,
`Patent Owner.
`
`––––––––––––––––––
`
`Case No. IPR2015-00870
`U.S. Patent No. 8,860,705
`
`––––––––––––––––––
`
`PETITIONER’S REPLY BRIEF
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`––––––––––––––––––
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`––––––––––––––––––
`
`APPLE INC.,
`Petitioner,
`
`v.
`VIRNETX INC.,
`Patent Owner.
`
`––––––––––––––––––
`
`Case No. IPR2015-00870
`U.S. Patent No. 8,860,705
`
`––––––––––––––––––
`
`PETITIONER’S REPLY BRIEF
`
`
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`Table of Contents
`
`I.
`
`II.
`
`Introduction ...................................................................................................... 1
`
`Claim Construction .......................................................................................... 1
`
`III. Beser and RFC 2401 Render Claims 1-23 and 25-30 Obvious ....................... 2
`
`A. A Person of Ordinary Skill Would Have Combined Beser and RFC
`2401 ....................................................................................................... 3
`
`B.
`
`Independent Claims 1 and 16 ................................................................ 7
`
`1.
`
`2.
`
`Beser Teaches a Request to Lookup an IP Address ................... 8
`
`Beser Teaches “Intercepting” a Request to Lookup an IP
`Address ...................................................................................... 12
`
`C.
`
`Dependent Claims ............................................................................... 15
`
`1.
`
`2.
`
`3.
`
`4.
`
`Claims 6 and 21 ......................................................................... 15
`
`Claims 7 and 22 ......................................................................... 16
`
`Claims 13 and 28....................................................................... 17
`
`Claims 2-5, 8-12, 14, 15, 17-20, 23, 25-27, 29, and 30 ............ 18
`
`IV. Beser, RFC 2401, and Brand Render Claim 24 Obvious .............................. 18
`
`V.
`
`RFC 2401 Is a Prior Art Printed Publication ................................................. 19
`
`A.
`
`B.
`
`The Evidence Shows RFC 2401 Is a Prior Art Printed Publication ... 19
`
`Patent Owner’s Arguments Lack Any Merit ...................................... 20
`
`VI. Dr. Tamassia’s Testimony is Probative ......................................................... 23
`
`VII. Conclusion ..................................................................................................... 25
`
`
`
`i
`
`
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`TABLE OF AUTHORITIES
`
`Cases
`
`Page(s)
`
`Arthrocare Corp. v. Smith & Nephew, Inc.,
`406 F.3d 1365 (Fed. Cir. 2005) .......................................................................... 11
`
`Belden Inc. v. Berk-Tek LLC,
`805 F.3d 1064 (Fed. Cir. 2015) .................................................................... 24, 25
`
`Brand v. Miller,
`487 F.3d 862 (Fed. Cir. 2007) .................................................................. 1, 19, 24
`
`Poole v. Textron, Inc.,
`192 F.R.D. 494 (D. Md. 2000) ........................................................................... 22
`
`Schumer v. Lab. Computer Sys., Inc.,
`308 F.3d 1304 (Fed. Cir 2002) ........................................................................... 24
`
`Sundance, Inc. v. Demonte Fabricating Ltd,
`550 F.3d 1356 (Fed. Cir. 2008) .......................................................................... 23
`
`Tempo Lighting Inc. v. Tivoli, LLC,
`742 F.3d 973 (Fed. Cir. 2014) ...................................................................... 17, 25
`
`Titanium Metals Corp. of America v. Banner,
`778 F.2d 775 (Fed. Cir. 1985) ............................................................................ 25
`
`U.S. v. Taylor,
`166 F.R.D. 356 (M.D.N.C.) aff'd, 166 F.R.D. 367 (M.D.N.C. 1996) ................ 22
`
`Ultratec, Inc. v. Sorenson Commc'ns, Inc.,
`No. 13-CV-346, 2014 WL 4829173 (W.D. Wis. Sept. 29, 2014) ...................... 22
`
`Guangdong Xinbao Elec. Appliances Holdings v. Adrian Rivera,
`IPR2014-00042, Paper 50 (Feb. 6, 2015) .......................................................... 24
`
`LG Display Co., Ltd, v. Innovative Display Techs. LLC,
`IPR2014-01362, Paper 32 (Feb. 8, 2016) .......................................................... 25
`
`Statutes
`
`35 U.S.C. § 6 ............................................................................................................ 25
`
`ii
`
`
`
`IPR2015-00870
`
`Other Authorities
`
`
`
`Petitioner’s Reply (Paper 26)
`
`37 CFR 42.65 ..................................................................................................... 22, 25
`
`Fed. R. Evid. 702 ............................................................................................... 23, 24
`
`
`
`iii
`
`
`
`IPR2015-00870
`
`I.
`
`Introduction
`
`
`
`Petitioner’s Reply (Paper 26)
`
`In its Institution Decision, the Board correctly found that Beser and RFC
`
`2401 render claims 1-23 and 25-30 of the ’0705 patent obvious and that Beser,
`
`RFC 2401, and Brand renders claim 24 obvious. Paper 8 (Dec.) at 7-18. In its
`
`Response (“Resp.”) (Paper 23), Patent Owner advances a number of irrelevant
`
`claim construction challenges, makes several narrow challenges to the substance of
`
`the Board’s findings about Beser and RFC 2401, challenges whether RFC 2401 is
`
`a printed publication, and then concludes by asserting that the Board lacks the
`
`ability to compare the prior art to the challenged claims on its own without expert
`
`testimony. Each of Patent Owner’s arguments lacks merit and should be rejected.
`
`The Board’s initial determination that the challenged claims are unpatentable was
`
`correct and should be maintained.
`
`II. Claim Construction
`
`In the Institution Decision, the Board correctly found that it need not rely on
`
`the broadest reasonable construction of any of the disputed terms, noting that under
`
`any reasonable construction, the prior art renders the claims obvious.
`
`Many of the terms Patent Owner construes in its Response are irrelevant to
`
`this proceeding because it does not dispute that Beser and RFC 2401 teach those
`
`terms. These include: “secure communications link” (id. at 5-15), “domain name”
`
`(id. at 25-26), “secure communications service” (id. at 26), “[modulated /
`
`1
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`unmodulated] transmission link” (id. at 26-27), and “phone” (id. at 27). The Board
`
`need not address the remaining three, i.e., “interception” (id. at 4-5), “[VPN] link”
`
`(id. at 15-22), and “secure domain name” (id. at 22-25), because as explained
`
`below, Beser and RFC 2401 discloses these limitations under any reasonable
`
`construction of those terms.
`
`III. Beser and RFC 2401 Render Claims 1-23 and 25-30 Obvious
`
`The Board correctly found that Beser and RFC 2401 render claims 1-23 and
`
`25-30 obvious. In its Response, Patent Owner raises three primary challenges to
`
`those findings: (i) a person of ordinary skill would not have combined Beser and
`
`RFC 2401, (ii) Beser does not disclose a “request to lookup an IP address,” and
`
`(iii) Beser does not disclose “intercepting” such a request.
`
`Initially, this panel should reject Patent Owner’s arguments because most of
`
`them were already considered and rejected by another panel in a proceeding
`
`involving a closely related patent. In the Final Written Decision in IPR2014-00237,
`
`the Board found that Beser and RFC 2401 rendered claims containing elements
`
`similar to the ’341 patent invalid. Paper 41 at 37-41 (May 11, 2015). There, the
`
`Board rejected Patent Owner’s arguments that a person of ordinary skill would not
`
`have combined Beser and RFC 2401, (Paper 41 at 37-41), and that Beser does not
`
`disclose the step of “intercepting a request to lookup an IP address,” (id. at 22-28).
`
`In the current proceeding, Patent Owner simply rehashes those same rejected
`
`2
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`arguments. This panel should reject those arguments again. Even if those
`
`arguments are reconsidered on the merits, they are wrong and must be rejected.
`
`A. A Person of Ordinary Skill Would Have Combined Beser and
`RFC 2401
`
`As explained in the petition and by Dr. Tamassia, a person of ordinary skill
`
`in the art would have found it obvious to combine Beser and RFC 2401 to provide
`
`end-to-end encryption in an IP tunnel between Beser’s originating and terminating
`
`end devices. Pet. at 30-34; Ex. 1005 at ¶¶421-441. The petition explained that the
`
`Beser IP tunnel would hide the true addresses of two communicating end devices
`
`providing user anonymity, and that a person of ordinary skill would have been
`
`motivated to follow Beser’s suggestion to use IPsec (RFC 2401) to hide the data
`
`transmitted between the end devices. Pet. at 31-32; Ex. 1005 at ¶¶436-37. In its
`
`Institution Decision, the Board agreed and preliminarily found a person of ordinary
`
`skill would have combined Beser and RFC 2401. Dec. at 11-14.
`
`In its Response, Patent Owner primarily repeats the arguments it raised in
`
`IPR2014-00237 and which were rejected by the Board. See Paper 41 at 37-41
`
`(May 11, 2015); Paper 30 at 56-58 (Aug. 29, 2014). It again argues that Beser’s
`
`statements recognizing that encryption can present practical challenges in some
`
`circumstances “teaches away” from the use of encryption. Resp. at 36-42. Patent
`
`Owner’s argument still cannot be squared with Beser’s disclosure.
`
`Beser recognizes encryption ordinarily should be used when the contents of
`3
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`a communication need to be protected (Ex. 1007 at 1:54-56), and it discloses using
`
`encryption when user-identifiable data are sent over the network such as during
`
`establishment of the IP tunnel, (id. at 11:22-25); Pet. at 30-31. Beser also criticizes
`
`prior art IP tunneling methods that sometimes prevent use of encryption, (Ex. 1007
`
`at 2:1-8, 2:22-24), and states its tunneling method is intended to overcome such
`
`problems, (id. at 2:43-45). A person of ordinary skill reading Beser would have
`
`understood that encryption should ordinarily be used to protect the contents of
`
`communications in an IP tunnel. Ex. 1005 at ¶¶422-24, 427-28, 436-37.
`
`Neither Patent Owner nor Dr. Monrose have asserted Beser’s tunneling
`
`method is technically incompatible with encryption – they simply raise practical
`
`concerns that only affect some configurations of the system. Dr. Monrose has
`
`admitted that there was no inherent incompatibility with using IPsec to encrypt
`
`multimedia data, and that a person of ordinary skill would have had computational
`
`concerns only if IPsec was configured to use certain types of encryption. Ex. 1066
`
`at 80:20-81:8, 82:7-17. He also admitted a person of ordinary skill in February
`
`2000 would have been able to adjust the configuration of a system to allow
`
`multimedia data to be encrypted. Id. at 79:3-11. Petitioner’s expert Dr. Tamassia
`
`similarly explained that a skilled person would be able to change a system’s
`
`configuration to accommodate use of encryption in Beser’s IP tunnel. Ex. 1005 at
`
`¶¶427-28 (adding more computing power or using a lower resolution media stream
`
`4
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`could solve any issues). Patent Owner criticizes the Board for finding that adding
`
`more computer power to a system would alleviate the potential concerns identified
`
`in Beser, arguing that approach is not always the solution to every problem. Resp.
`
`at 37-38. But adding more computing power is one of several ways to address the
`
`practical considerations mentioned in Beser, as Dr. Monrose has previously
`
`recognized. Ex. 1067 at 206:20-208:6 (admitting more powerful computers or
`
`lower recording fidelity would resolve Beser’s concerns), 211:16-212:2.
`
`Patent Owner also argues Beser teaches away from encryption because its
`
`tunneling method was designed to have a low computational burden on a system,
`
`and therefore, it was designed to replace computationally expensive security
`
`techniques such as encryption. Resp. at 38, 40. But Patent Owner mischaracterizes
`
`the purpose of Beser’s design. Beser was designed to provide a better method for
`
`ensuring user privacy by allowing communications over the Internet to be
`
`anonymous. See Ex. 1007 at 2:36-40, 3:4-9. Beser explains users increasingly had
`
`privacy concerns, (id. at 1:13-25), and that it was easy for computer hackers to
`
`determine the identity of two users communicating over the Internet because the
`
`source and destination addresses of IP packets were viewable, (id. at 1:26-53).
`
`Beser explains that while encrypting data could protect the contents of the
`
`communication, encryption did not provide privacy because it did not hide the
`
`identities of devices that are communicating. Id. at 2:1-5; id. at 1:56-58. Beser
`
`5
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`then discusses conventional IP tunneling techniques, which could provide privacy
`
`by hiding the true addresses of end devices, but notes those techniques sometimes
`
`were incompatible with encryption. Ex. 1007 at 2:22-24; see also id. at 1:54-2:35;
`
`see Pet. at 30-31. Beser also notes that both encryption and prior art IP tunnels
`
`were computationally expensive. Ex. 1007 at 1:60-63, 2:12-17, 2:33-35.
`
`Beser states that its IP tunneling technique was designed to overcome these
`
`problems with the prior art. Ex. 1007 at 2:43-45. Beser’s IP tunnel hides the
`
`identities of communicating devices, but in contrast to prior art IP tunnels which
`
`were computationally expensive, (id. at 2:33-35), Beser’s IP tunnel has a low
`
`“computational burden,” (id. at 3:4-9). Because of its low computational burden,
`
`Beser’s method is flexible and can be integrated into existing communications
`
`systems and combined with other security techniques. See Ex. 1005 at ¶¶426, 431;
`
`Ex. 1007 at 3:4-9, 4:55-5:2. Beser’s tunneling method also can be combined with
`
`encryption: Beser specifically notes the its IP tunnel can improve the security of
`
`encryption by helping to “prevent a hacker from intercepting all media flow
`
`between the ends,” (Ex. 1007 at 2:36-40), and from “accumulating . . . sufficient
`
`information to decrypt the message,” (id. at 1:56-58). In addition, IPsec was
`
`known to be highly adaptable, enabling it to accommodate computational burdens
`
`of a particular configuration by adjusting parameters of the IPsec protocol (e.g.,
`
`adjusting the strength or type of encryption used). See Ex. 1008 at 4, 7, 10.
`
`6
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`Next, Patent Owner argues that using encryption in Beser’s system would be
`
`“redundant” because Beser teaches hiding the identities of the end devices instead
`
`of protecting the contents of a communication. Resp. at 40; see id. at 38-39
`
`(arguing Beser is intended to replace encryption). But Beser never states its
`
`technique is intended to replace encryption. In fact, Beser distinguishes between
`
`using encryption to protect the data inside packets and using IP tunnels to hide the
`
`true addresses of the end devices, as Patent Owner recognizes. Resp. at 36-37. And
`
`Dr. Monrose agreed a person of ordinary skill would have recognized that using a
`
`security technique to protect the identities of the parties communicating is not a
`
`substitute for using encryption to protect the contents of the communications sent
`
`between the parties. Ex. 1066 at 74:4-15; 74:25-75:3. Thus, the Board correctly
`
`found a person of ordinary skill would have combined Beser and RFC 2401.
`
`B.
`
`Independent Claims 1 and 16
`
`The Board correctly found Beser discloses “intercepting” a “request … to
`
`lookup an [IP] address.” Dec. at 9-11. As explained in the Petition, Beser shows
`
`an originating device 24 initiates an IP tunnel with terminating device 26 by
`
`sending out a tunneling request that contains device 26’s unique identifier. Pet. at
`
`36-37. This request is intercepted by each of first network device 14 and trusted-
`
`third-party network device 30. Id. In IPR2014-00237, the Board relied on this
`
`same request in finding that “Beser’s trusted-third-party device 30 is ‘informed of
`
`7
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`the request’ from device 14; thereby ‘receiving a request pertaining to a first entity
`
`[26] at another entity [14 or 30]’ and satisfying the ‘intercepting a request’ element
`
`of claim 1 (and a similar element in claim 16).” Paper 41 at 24.
`
`Patent Owner argues Beser’s tunneling request is not a “request … to lookup
`
`an [IP] address” because no single device looks up the IP address of the
`
`terminating device. Resp. at 31-33. It also argues the tunneling request cannot be
`
`“intercepted” by first network device 14 or trusted-third-party network device 30
`
`because in Beser’s system those devices are designed to always process the
`
`requests. Id. at 33-36. Each of Patent Owner’s contentions reflects a
`
`misunderstanding of its own claims and a mischaracterization of what Beser
`
`actually discloses.
`
`1.
`
`Beser Teaches a Request to Lookup an IP Address
`
`The tunneling request sent by originating device 24 is a “request … to
`
`lookup an [IP] address” because in response to receiving the request, the Beser
`
`trusted device 30 looks up two IP addresses. Pet. at 36-37. First, it consults an
`
`internal database of registered devices to look up the IP address of second network
`
`device 16 that is associated with the unique identifier. Id. at 21-22, 36-37; Ex. 1007
`
`at 11:45-58. Second, it looks up a private IP address for terminating device 26 by
`
`sending a message to network device 16 requesting the address. Pet. at 22-23, 36-
`
`37; Ex. 1007 at 9:29-30, 12:16-19, 14:14-27, Figs. 6 & 9. As a result of this
`
`8
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`process, originating device 24 receives an IP address for terminating device 26.
`
`Pet. at 23; Ex. 1007 at 21:48-52; see Ex. 1066 at 103:22-104:3 (Dr. Monrose not
`
`disputing the originating device receives an IP address for the terminating device).
`
`Patent Owner argues the tunneling request cannot be a request to “lookup an
`
`IP address” because trusted device 30 does not “look up” any IP addresses in
`
`response to the request. Resp. at 31-32. Initially, that argument is irrelevant to the
`
`claims, which specify intercepting “a request to lookup an [] IP address,” and
`
`under the broadest reasonable construction, do not require a lookup to be
`
`performed, let alone specify that a particular device perform the lookup. Thus,
`
`Patent Owner’s arguments about performing a lookup can be dismissed because
`
`the claims do not require a lookup.
`
`Based on its incorrect theory that a lookup is required, Patent Owner argues
`
`that neither of Beser’s lookups actually lookup an IP address. First, Patent Owner
`
`argues Beser does not disclose that trusted device 30 performs a “lookup” of
`
`network device 16’s public IP address in response to a tunneling request. Resp. at
`
`32. It admits that trusted device 30 contains a database or similar structure that
`
`correlates each unique identifier to the public IP addresses of a second network
`
`device 16 and terminating device 26, but asserts Beser “never suggests that this
`
`data structure is looked up when the tunnel request is received by device 30.”
`
`Resp. at 32. That position is contrary to Beser’s explicit disclosure.
`
`9
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`Beser describes the database as an example of how the trusted-third-party
`
`network device 30 performs Step 116 of Figure 5, “associat[ing] a public IP
`
`address for a second network device,” which it performs after receiving the
`
`tunneling request sent to it in Step 114. Ex. 1007 at Fig. 5, 11:26-58. Figure 5 has
`
`four steps, and Beser walks through each step sequentially on 9:64 to 12:19. See
`
`Ex. 1066 at 104:25-107:13. Beser discusses Step 116 in two sequential paragraphs
`
`that appear at 11:26-58, as Dr. Monrose agreed. Ex. 1066 at 107:15-108:8. The
`
`first paragraph explains trusted device 30 associates the public IP address for
`
`second network device 16 with the unique identifier in the request. Ex. 1007 at
`
`11:26-32. The second paragraph describes an example of how the association is
`
`performed, stating “[f]or example, the trusted-third-party network device 30
`
`may . . . retain[]a list of E.164 numbers of its subscribers [and] [a]ssociated with a
`
`E.164 number in the directory database is the IP 58 address of a particular second
`
`network device 16.” Id. at 11:45-50; see id. at 11:55-58 (noting other types of
`
`unique identifiers could be used). Thus, Beser teaches that in Step 116 of Figure 5,
`
`trusted device 30 receives the tunneling request, (id. at 11:9-20), and in response, it
`
`associates an IP address with the unique identifier by looking it up in its internal
`
`database, (id. at 11:26-58). See Ex. 1066 at 107:15-108:8.
`
`Patent Owner also suggests the Beser tunneling request cannot be one to
`
`“lookup an IP address” because trusted device 30 looks up the public IP address of
`
`10
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`second network device 16 instead of terminating device 26. Resp. at 32. But the
`
`claims only specify a request to lookup an “[IP] address … based on a domain
`
`name associated with the target device,” (Ex. 1050 at 55:56-57) (emphasis added),
`
`and the ’0705 specification provides that the IP address looked up “need not be the
`
`actual address of the destination computer,” (id. at 40:24-25). Dr. Monrose agreed.
`
`Ex. 1066 at 63:25-64:24. In Beser’s system, the IP address of network device 16 is
`
`“associated with” the unique identifier (e.g., domain name) of terminating device
`
`26. Thus, the tunneling request meets the language of the claims.
`
`Second, Patent Owner challenges the “lookup” of the private IP address by
`
`arguing the first and second devices (14 & 16), and not trusted device 30, negotiate
`
`private IP addresses for end devices 24 & 26. Resp. at 31-32. That argument is
`
`premised on a single embodiment in Beser, and ignores that Beser discloses
`
`embodiments where trusted device 30 performs the negotiation with the first and
`
`second network devices (14 & 16). Ex. 1007 at 9:29-30, 12:16-19, 14:19-27, Figs.
`
`6 and 9; see Pet. at 21-22, 36-37. Petitioner established certain embodiments in
`
`Beser met the claim limitations, which is all that is required. Arthrocare Corp. v.
`
`Smith & Nephew, Inc., 406 F.3d 1365, 1372 (Fed. Cir. 2005) (no requirement that
`
`every possible embodiment of a prior art reference satisfy the claims).
`
`Patent Owner also asserts that no private IP addresses are “looked up”
`
`during the negotiation because second network device 16 “assigns” a private IP
`
`11
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`address to terminating device 26. Resp. at 31-32. That argument fails for at least
`
`two reasons. One, even if second network device 16 “assigns” the IP address to
`
`terminating device 24, the trusted device 30 “looks up” the IP address when it
`
`sends a message to network device 16 requesting a private IP address. Ex. 1007 at
`
`Fig. 9 (packets 164 & 166), 13:34-48, 13:66-14:18; Pet. at 20-21, 38. Two, second
`
`device 16 does not simply “assign” an IP address – it looks one up by selecting an
`
`unused address out of a pool of IP addresses. Ex. 1007 at 13:49-64; Pet. at 20.
`
`Thus, the Board should find Beser teaches a “request to lookup an IP address.”
`
`IPR2014-00237, Paper 41 at 22-23 (finding Beser discloses such a request).
`
`2.
`
`Beser Teaches “Intercepting” a Request to Lookup an IP
`Address
`
`Beser shows that each of the first network device 14 and the trusted-third-
`
`party network device 30 “intercept” the tunneling request sent by originating
`
`device 24. Pet. at 36-37. The tunneling request contains the unique identifier for
`
`terminating device 26, (Ex. 1007 at 8:1-3, 10:37-42), but it is received and
`
`processed by first network device 14, (id. at 8:21-22, 8:39-43, 10:22-23). Because
`
`the request pertains to terminating device 26 but is received by network device 14,
`
`it is intercepted by network device 14. Pet. at 36. If network device 14 determines
`
`the request needs special processing by detecting a unique sequence of bits in the
`
`packet, (Ex. 1007 at 8:34-43), network device 14 forwards the request, where it is
`
`received by trusted device 30, (id. at 8:3-7, 8:48-49). Pet. at 36-37; see also Ex.
`12
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`1007 at Figs. 4 & 6. The trusted device 30 device thus also “intercepts” the
`
`tunneling request. Pet. at 36-37; see also IPR2014-00237, Paper 41 at 23-24.
`
`Patent Owner contends that neither first network device 14 nor trusted-third-
`
`party network device 30 “intercept” the tunneling request because Beser’s system
`
`is designed such that tunneling requests are always “intended for” and received by
`
`those two devices. Resp. at 34-36. But Patent Owner’s arguments are irrelevant to
`
`what the claims require. The ’0705 patent’s only disclosure of a DNS device that
`
`“intercepts” lookup requests is DNS proxy 2610, which “intercepts all DNS
`
`lookup functions from client 2605.” Ex. 1050 at 40:6-7 (emphasis added). The
`
`’0705 patent thus provides that DNS proxy 2610 “intercepts” lookup functions,
`
`even though the DNS proxy receives every single lookup request sent by the client.
`
`Id. at Fig. 26, 40:6-7. Dr. Monrose agreed the DNS proxy receives every DNS
`
`request and that the system is designed, i.e., “pre-established” to intercept every
`
`DNS request. Ex. 1066 at 55:8-20. Thus, the Board should reject Patent Owner’s
`
`arguments that Beser cannot show “intercepting” because it is designed such that
`
`IP tunnel requests are received by network device 14 and trusted device 30.
`
`Moreover, Patent Owner mischaracterizes Beser. Even if “intercepting”
`
`were to include an “intent” element—a position that no party has taken in this
`
`proceeding—Beser discloses such as system. The originating device 24 never
`
`“intends for” its tunneling request to be received by the trusted device 30. As the
`
`13
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`petition explains, the originating device 24 sends tunneling requests to first
`
`network device 14. Pet. at 36. Dr. Monrose agreed that the tunneling request is
`
`addressed to the first network device and not the trusted-third-party network
`
`device. Ex. 1066 at 94:7-95:14. Network device 14 runs a tunneling application
`
`that monitors traffic for a distinctive sequence of bits, and if it detects a packet
`
`containing those bits, it forwards that packet to trusted device 30. Pet. at 36; Ex.
`
`1007 at 8:39-43. In Beser’s system, it is first network device 14 that “intends” for
`
`trusted device 30 to receive the request. Ex. 1066 at 97:8-98:10, 101:9-14. The
`
`originating device 24 only “intends” for the tunneling request to go to network
`
`device 14. Thus, the tunnel request is received by trusted device 30, even though
`
`originating device 14 did not “intend” to send the tunnel request to that device, and
`
`thus trusted device 30 “intercepts” the request. See Pet. at 36-37.
`
`All of Patent Owner’s arguments about the “intercepting” step are anchored
`
`on it including an “intent” element, and not on any of the actual proposed
`
`constructions. Resp. at 23-27; see Ex. 1066 at 124:23-127:13, 132:8-13 (Dr.
`
`Monrose admitting he did not apply Petitioner’s, Patent Owner’s, or the Board’s
`
`constructions, and in fact had no opinion on what the term “intercepting” requires).
`
`The Board can reject those arguments because no one in this proceeding has
`
`advanced such a construction of “intercepting.” Patent Owner asserts Dr.
`
`Tamassia “clarified” his construction of “interception” to mean “receiving a
`
`14
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`request pertaining to intended for or ordinarily received by a first entity at another
`
`entity.” Resp. at 33; Ex. 1005 at ¶123. But here Patent Owner mischaracterizes Dr.
`
`Tamassia’s testimony; he was at that point explaining the rationale underpinning
`
`his construction, and was neither proposing nor applying a different construction.
`
`Ex. 2019 at 79:9-80:13, 85:9-12; Ex. 1005 at ¶122. Even if “intercepting” were
`
`found to require receiving a request “intended for” another entity, that is disclosed
`
`by Beser, as explained above. Further, even if Patent Owner’s “alternative”
`
`construction specifying “performing an additional evaluation” on the request were
`
`adopted, (Resp. at 4-5), Beser discloses that as well: the trusted device 30 evaluates
`
`the request by checking an internal table of secure devices, (Ex. 1007 at 11:45-58),
`
`which is the same process shown in the ’0705 patent, (Ex. 1050 at 40:8-11).
`
`C. Dependent Claims
`
`1.
`
`Claims 6 and 21
`
`Petitioner explained Beser and RFC 2401 teach a “[VPN] communication
`
`link” because Beser’s obfuscation provides anonymity while RFC 2401 encrypts
`
`data. Pet. at 47-48. The same glossary of terms that Patent Owner and Dr.
`
`Monrose rely on to inform their understanding of this term explicitly provides that
`
`IPsec and RFC 2401 can be used to create VPNs. Resp. at 19-21; Ex. 2008 at 25;
`
`see id. at 21; Ex. 1070 at 101:3-115:16; Prelim. Resp. at 43-45.
`
`Patent Owner argues that Beser differentiates its tunnel from a “virtual
`
`15
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`private network link” because Beser identifies a limitation of prior art “VPN”
`
`methods. Resp. at 42. But Patent Owner relies only on Beser’s purported definition
`
`of a VPN, not a construction of “virtual private network link” proposed in this
`
`case. Id. at 42-43, Ex. 1070 at 72:21-73:14 (Dr. Monrose testifying his opinion
`
`was based on Beser’s “understanding of virtual private networks”), 63:5-64:6,
`
`65:10-66:2.1 Neither Patent Owner nor Dr. Monrose apply either party’s proposed
`
`construction of the term to Beser, nor do they respond to Petitioner’s reliance on
`
`the combination of Beser and RFC 2401. Pet. at 47-48; Ex. 1070 at 79:3-21, 83:2-
`
`22. Therefore, Patent Owner’s challenge to this claim limitation can be dismissed.
`
`2.
`
`Claims 7 and 22
`
`Petitioner explained that Beser discloses a “secure domain name” because if
`
`a unique identifier is listed in the trusted-third-party network device 30’s database
`
`of registered identifiers, it corresponds to a private IP address that can be used to
`
`access the device securely. Pet. at 48-49. This satisfies Petitioner’s construction
`
`of a “secure domain name”: “a name that corresponds to a secure computer
`
`network address.” Pet. at 15; Ex. 1005 at ¶141.
`
`Patent Owner challenges Petitioner’s position by asserting Beser’s trusted-
`
`
`
`1 Beser’s solution is also plainly a VPN as Beser defines it: “a tunneling connection
`
`between edge routers on the public network.” Ex. 1007 at 2:6-8, 2:43-67, 4:19-21.
`
`16
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`third party device does not negotiate addresses based on the secure domain name.
`
`Resp. at 44. But as explained above, Patent Owner is wrong, see § III.B.1 above. It
`
`also argues Beser does not disclose a “secure domain name” based on its
`
`construction of that term: a “non-standard domain name that corresponds to a
`
`secure computer network address and cannot be resolved by a conventional
`
`domain name service (DNS).” Id. Its construction is based on a disclaimer
`
`argument which is not applicable to the Board here. Tempo Lighting Inc. v. Tivoli,
`
`LLC, 742 F.3d 973, 978 (Fed. Cir. 2014). But even under that construction, Beser
`
`discloses a secure domain name. During prosecution of a related patent, U.S.
`
`Patent No. 8,051,181, Patent Owner explained that the term “secure name”
`
`encompassed a “secure non-standard domain name” such as “a secure non-
`
`standard top-level domain name (e.g., .scom) or a telephone number.” Ex. 1069 at
`
`9. Therefore, Patent Owner’s construction of “secure domain name” as being a
`
`“non-standard domain name” encompasses a telephone number. Beser discloses
`
`the unique identifier can be a phone number, which satisfies Patent Owner’s
`
`construction. Pet. at 20, 48-49 (Ex. 1007 at 10:38-41); see Ex. 1066 at 110:18-
`
`11:14 (testifying he never considered whether the phone number in Beser could be
`
`a secure domain name). Thus, the Board should find claims 7 and 22 obvious.
`
`3.
`
`Claims 13 and 28
`
`Patent Owner argues Beser does not disclose that terminating device 26 can
`
`17
`
`
`
`IPR2015-00870
`
`
`
`Petitioner’s Reply (Paper 26)
`
`be “a server” as required by these claims. Resp. at 45-
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
