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-00866
`U.S. Patent No. 8,458,341
`
`––––––––––––––––––
`
`PETITIONER’S REPLY BRIEF
`
`
`
`

`
`IPR2015-00866
`
`
`
`Petitioner’s Reply (Paper 26)
`
`Table of Contents
`
`I.
`
`Introduction .................................................................................................... 1
`
`II. Claim Construction ....................................................................................... 1
`
`III. Beser and RFC 2401 Render Claims 1-11, 14-25, and 28 Obvious ........... 2
`
`A. A Person of Ordinary Skill Would Have Combined Beser and RFC
`2401 ....................................................................................................... 3
`
`B.
`
`Independent Claims 1 and 15 ................................................................ 7
`
`1.
`
`2.
`
`3.
`
`4.
`
`Beser Teaches a Request to Lookup an IP Address ................... 8
`
`Beser Teaches “Intercepting” a Request to Lookup an IP
`Address ...................................................................................... 12
`
`Beser and RFC 2401 Teach a “Virtual Private Network
`Communication Link” .............................................................. 15
`
`Beser Teaches that Originating Device 24 Receives an
`Indication, a Network Address, and Provisioning Information 16
`
`C.
`
`Dependent Claims ............................................................................... 17
`
`1.
`
`2.
`
`3.
`
`Claims 4, 5, 18, and 19 ............................................................. 17
`
`Claim 17 .................................................................................... 18
`
`Claims 2, 3, 6-11, 14, 16, 20-25, and 28 ................................... 18
`
`IV. 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
`
`V. Dr. Tamassia’s Testimony is Probative ..................................................... 23
`
`VI. Conclusion .................................................................................................... 25
`
`i
`
`

`
`IPR2015-00866
`
`
`
`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) ............................................................................ 24
`
`Poole v. Textron, Inc.,
`192 F.R.D. 494 (D. Md. 2000) ........................................................................... 22
`
`Randall Mfg. v. Rea,
`733 F.3d 1355 (Fed. Cir. 2013) .......................................................................... 18
`
`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
`
`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
`
`Laird Tech., Inc., v. Graftech Int’l Holdings, Inc.,
`IPR2014-00023, Paper 49 (Mar. 25, 2015) ....................................................... 18
`
`LG Display Co., Ltd, v. Innovative Display Techs. LLC,
`IPR2014-01362, Paper 32 at 15-16 (Feb. 8, 2016) ............................................ 25
`
`ii
`
`

`
`IPR2015-00866
`
`Statutes
`
`
`
`Petitioner’s Reply (Paper 26)
`
`35 U.S.C. § 6 ............................................................................................................ 25
`
`Other Authorities
`
`37 C.F.R. 42.65 ............................................................................................ 18, 22, 25
`
`Fed. R. Evid. 702 ..................................................................................................... 23
`
`
`
`iii
`
`

`
`IPR2015-00866
`
`I.
`
`Introduction
`
`
`
`Petitioner’s Reply (Paper 26)
`
`In its Institution Decision, the Board correctly found that Beser and RFC
`
`2401 render claims 1-11, 14-25, and 28 of the ’341 patent obvious. Paper 8 (Dec.)
`
`at 7-12. 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, Beser and RFC 2401 render 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: “provisioning information” (Resp. at 5-7), “secure
`
`communication service” (id. at 20), “indication” (id. at 20-21), “domain name” (id.
`
`at 21), and “modulation” (id. at 21). The Board need not address the remaining
`
`1
`
`

`
`IPR2015-00866
`
`
`
`Petitioner’s Reply (Paper 26)
`
`two terms, i.e., “interception” (id. at 4-5) and “[VPN] communication link” (id. at
`
`8-20), 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-11, 14-25, and 28 Obvious
`
`The Board correctly found that Beser and RFC 2401 render claims 1-11, 14-
`
`25, and 28 obvious. In its Response, Patent Owner raises five primary challenges:
`
`(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,” (iii) Beser does not
`
`disclose “intercepting” such a request, (iv) Beser and RFC 2401 do not disclose a
`
`“[VPN] communication link,” and (v) Beser and RFC 2401 do not suggest that
`
`originating device 24 receives all three elements specified by the “receiving” step.
`
`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-00866
`
`
`
`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 29-33; 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; 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 34-40. 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-00866
`
`
`
`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. 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-00866
`
`
`
`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 35-36. 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 36, 38. 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-00866
`
`
`
`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 29-30. 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-00866
`
`
`
`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 38; see id. at 36 (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 34-35. 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 15
`
`The Board correctly found Beser discloses “intercepting” a “request to
`
`lookup an [IP] address.” Dec. at 9-10. 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
`
`34-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-00866
`
`
`
`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 asserts that Beser and RFC 2401 do not teach four limitations
`
`of claims 1 and 15. See Resp. at 25-34. 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 34-36. 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, 35-36; 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, 35-
`
`36; Ex. 1007 at 9:29-30, 12:16-19, 14:14-27, Figs. 6 & 9. As a result of this
`
`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
`
`8
`
`

`
`IPR2015-00866
`
`
`
`Petitioner’s Reply (Paper 26)
`
`IP address” because trusted device 30 does not “look up” any IP addresses in
`
`response to the request. Resp. at 26. 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
`
`27. 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 27. That position is contrary to Beser’s explicit disclosure.
`
`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
`
`9
`
`

`
`IPR2015-00866
`
`
`
`Petitioner’s Reply (Paper 26)
`
`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
`
`second network device 16 instead of terminating device 26. Resp. at 27. But the
`
`claims only specify a request to lookup an “[IP] address … based on a domain
`
`name associated with second network device,” (Ex. 1001 at 56:8-10) (emphasis
`
`added), and the ’341 specification provides that the IP address looked up “need not
`
`10
`
`

`
`IPR2015-00866
`
`
`
`Petitioner’s Reply (Paper 26)
`
`be the actual address of the destination computer,” (id. at 40:43-44). 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 claim language.
`
`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 26. 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, 35-36. 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
`
`address to terminating device 26. Resp. at26. 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
`
`11
`
`

`
`IPR2015-00866
`
`
`
`Petitioner’s Reply (Paper 26)
`
`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 37. 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.
`
`1007 at Figs. 4 & 6. The trusted device 30 device thus also “intercepts” the
`
`tunneling request. Pet. at 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
`12
`
`

`
`IPR2015-00866
`
`
`
`Petitioner’s Reply (Paper 26)
`
`is designed such that tunneling requests are always “intended for” and received by
`
`those two devices. Resp. at 29-31. But Patent Owner’s arguments are irrelevant to
`
`what the claims require. The ’341 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. 1001 at 40:26-27 (emphasis added). The
`
`’341 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:26-27. 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. See Resp. at 4. The originating
`
`device 24 never “intends for” its tunneling request to be received by the trusted
`
`device 30. As the 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
`
`13
`
`

`
`IPR2015-00866
`
`
`
`Petitioner’s Reply (Paper 26)
`
`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 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 any constructions and had no opinion on the
`
`term “intercepting”). 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 request pertaining to intended for or ordinarily received by a first
`
`entity at another entity.” Resp. at 28-29; Ex. 1005 at ¶73. But here Patent Owner
`
`simply 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; see Ex. 1005 at
`
`14
`
`

`
`IPR2015-00866
`
`
`
`Petitioner’s Reply (Paper 26)
`
`¶72. 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
`
`’341 patent, (Ex. 1001 at 40:28-31).
`
`3.
`
`Beser and RFC 2401 Teach a “Virtual Private Network
`Communication Link”
`
`Petitioner explained that Beser and RFC 2401 teach a “[VPN]
`
`communication link” because Beser’s obfuscation provides anonymity while RFC
`
`2401 encrypts data. Pet. at 41-43. 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 17, 19;
`
`Ex. 2008 at 25; see id. at 21; Ex. 1070 at 101:3-115:16; Prelim. Resp. at 42.
`
`Patent Owner argues that Beser differentiates its tunnel from a “virtual
`
`private network communication link” because Beser identifies a limitation of prior
`
`art “VPN” methods. Resp. at 31. But Patent Owner relies only on Beser’s
`
`purported definition of a VPN, not a construction of “[VPN] communication link”
`
`proposed in this case. Id.; Ex. 1070 at 72:21-73:14 (Dr. Monrose testifying his
`
`15
`
`

`
`IPR2015-00866
`
`
`
`Petitioner’s Reply (Paper 26)
`
`opinion was based on Beser’s “understanding of virtual private networks”).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 42; Ex. 1070 at 79:3-21, 83:2-22.
`
`Therefore, Patent Owner’s challenge to this claim limitation can be dismissed.
`
`4.
`
`Beser Teaches that Originating Device 24 Receives an
`Indication, a Network Address, and Provisioning Information
`
`Patent Owner argues that Petitioner relies on two features in Beser and RFC
`
`2401 to teach three different claim elements, and asserts that such reliance is
`
`improper. Resp. at 32-34. Patent Owner’s argument suffers from a fatal flaw:
`
`Petitioner relies on three different features in Beser and RFC 2401 to teach the
`
`three claim elements. Pet. at 39-44. Claims 1 and 15 specify that a first device
`
`“receive … an indication that the second network device is available …, the
`
`requested IP address of the second network device, and provisioning information
`
`for a virtual private network communication link.” Ex. 1001 at 56:11-18. Patent
`
`Owner asserts that Petitioner relied on the same two features in Beser for the
`
`indication and the requested network address, but Patent Owner is wrong.
`
`Petitioner explained that after Beser’s originating device 24 sends out a tunneling
`
`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-00866
`
`
`
`Petitioner’s Reply (Paper 26)
`
`request, it receives the private IP address of the terminating device 26 as well as its
`
`own private IP address. Pet at 39-41; Ex. 1007 at 21:48-62. The originating
`
`device 24 receives the claimed “requested IP address” because it receives the
`
`private IP address of terminating device 26. Pet. at 41. It also receives the claimed
`
`“indication” because originating device 24 receives a second private IP address: its
`
`own.2 Pet. at 40. Thus, Petitioner has relied on two separate elements to teach two
`
`claim limitations. Patent Owner’s contrary argument can be dismissed.
`
`C. Dependent Claims
`
`1.
`
`Claims 4, 5, 18, and 19
`
`Petitioner explained it would have been obvious to send email through
`
`Beser’s IP tunnel per claims 4, 5, 18, and 19 “because [Beser] already transmits
`
`other types of communication data such as audio and video, and extending it to e-
`
`mail would have been an obvious design choice.” Pet. at 51; Ex. 1005 at ¶350 (“E-
`
`mail is a type of data . . . and transmitting it via Beser’s secure IP tunnel would
`
`protect it in the same way”). It also pointed to Beser’s use of email addresses and
`
`disclosure that “the ends of the data flow may be other types of network devices”
`
`as suggestions for such a modification. Pet. at 51; Ex. 1005