APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC,
`Patent Owner.
`___________________
`
`Case No. IPR2015-00810
`U.S. Patent No. 8,868,705
`____________________
`
`Before KARL D. EASTHOM, JENNIFER S. BISK, and
`GREGG I. ANDERSON, Administrative Patent Judges.
`
`__________________________________________________________________
`
`PETITIONER’S REPLY BRIEF
`
`
`
`
`
`
`
`
`
`Paper No. 29
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`___________________
`
`
`
`

`
`IPR2015-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`Table of Contents
`
`I.
`
`II.
`
`Introduction ...................................................................................................... 1
`
`Claim Construction .......................................................................................... 1
`
`III. Beser and RFC 2401 Render Claims 1-4, 6-10, 12-26, and 28-34 Obvious ... 2
`
`A. A Person of Ordinary Skill Would Have Combined Beser and RFC
`2401 ....................................................................................................... 3
`
`B.
`
`Independent Claims 1 and 21 ................................................................ 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.
`
`5.
`
`Claims 3, 10, and 25 ................................................................. 15
`
`Claims 4 and 26 ......................................................................... 16
`
`Claims 14 and 31....................................................................... 17
`
`Claims 18-20 and 22-24 ............................................................ 18
`
`Claims 2, 6-9, 12, 13, 15-17, 28-30, and 32-34 ........................ 18
`
`IV. Beser, RFC 2401, and Brand Render Claims 5, 11, and 27 Obvious ........... 19
`
`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 ...................................... 21
`
`VI. Dr. Tamassia’s Testimony Is Probative ......................................................... 23
`
`VII. Conclusion ..................................................................................................... 25
`
`
`
`
`
`i
`
`

`
`IPR2015-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`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) ...................................................................... 16, 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 at 22-23 (Feb. 6, 2015) ............................................ 24
`
`LG Display Co., Ltd, v. Innovative Display Techs. LLC, IPR2014-
`01362, Paper 32 at 15-16 (Feb. 8, 2016) ........................................................... 25
`
`
`
`ii
`
`

`
`IPR2015-00810
`
`Statutes
`
`
`
`Petitioner’s Reply (Paper 29)
`
`35 U.S.C. § 6 ............................................................................................................ 25
`
`Other Authorities
`
`37 CFR 42.65(a) ....................................................................................................... 25
`
`Fed. R. Evid. 702 ............................................................................................... 23, 24
`
`
`
`
`
`iii
`
`

`
`IPR2015-00810
`
`I.
`
`Introduction
`
`
`
`Petitioner’s Reply (Paper 29)
`
`In its Institution Decision, the Board correctly found that Beser and RFC
`
`2401 render claims 1-4, 6-10, 12-26, and 28-34 of the ’705 patent obvious and that
`
`Beser, RFC 2401, and Brand render claims 5, 11, and 27 obvious. Paper 8 (Dec.)
`
`at 13-23. In its Response (“Resp.”) (Paper 25), Patent Owner advances a number
`
`of irrelevant challenges or clarifications to the Board’s claim constructions, 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 and instead must rely on 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
`
`is supported by more than substantial evidence and should be maintained.
`
`II. Claim Construction
`Petitioner believes that the constructions set forth in the petition represent
`
`the broadest reasonable constructions of the claims. However, in the Institution
`
`Decision, the Board correctly found that it need not adopt specific constructions
`
`here because under any reasonable construction, Beser and RFC 2401 (and Brand
`
`for certain claims) render the claims obvious.
`
`Many of the terms Patent Owner construes in its Response are irrelevant to
`
`
`
`1
`
`

`
`IPR2015-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`this proceeding because it never challenges that Beser and RFC 2401 teach those
`
`terms. These include: “encrypted communication channel,” (Resp. at 8-10),
`
`“domain name,” (id. at 13), “provisioning information,” (id. at 13-15),
`
`“modulated/unmodulated,” (id. at 16-17), and “phone,” (id. at 17).
`
`The Board need not address the remaining two, i.e., “secure domain name”
`
`and “intercepting,” (id. at 3-8, 11-13), because as explained below, under any
`
`interpretation proposed by Petitioner or Patent Owner, or adopted by the Board,
`
`Beser and RFC 2401 discloses these limitations.
`
`III. Beser and RFC 2401 Render Claims 1-4, 6-10, 12-26, and 28-34 Obvious
`The Board correctly found that Beser and RFC 2401 render claims 1-4, 6-10,
`
`12-26, and 28-34 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 they
`
`were already considered by another panel in a proceeding involving a related
`
`patent and were rejected. In the Final Written Decision in IPR2014-00237, the
`
`Board found that Beser and RFC 2401 rendered claims containing elements similar
`
`to the ’705 patent invalid. Paper 41 at 37-41 (May 11, 2015). The Board rejected
`
`Patent Owner’s arguments that a person of ordinary skill would not have combined
`
`
`
`2
`
`

`
`IPR2015-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`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 arguments. This
`
`panel should reject those arguments again. Even if Patent Owner’s 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 26-30; Ex. 1005 at ¶¶383-403. 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 28; Ex. 1005 at ¶¶398-99. 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-13.
`
`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
`
`
`
`3
`
`

`
`IPR2015-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`circumstances “teaches away” from the use of encryption. Resp. at 29, 31-33.
`
`Patent Owner’s argument still cannot be squared with Beser’s disclosure.
`
`Beser recognizes encryption ordinarily should be used when the contents of
`
`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 27. 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 ¶¶384-86, 389-90, 398-99.
`
`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. At his deposition, Dr.
`
`Monrose admitted 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 the art 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.
`
`
`
`4
`
`

`
`IPR2015-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`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 ¶¶389-90 (explaining adding more computing power
`
`or using lower resolution 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 28. 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 (in a related
`
`proceeding, 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 29, 31. 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
`
`
`
`5
`
`

`
`IPR2015-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`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
`
`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 27-28. 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 ¶¶388, 393;
`
`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
`
`
`
`6
`
`

`
`IPR2015-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`information to decrypt the message,” (id. at 1:56-58).
`
`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 31; see id. at 29 (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 27. And Dr.
`
`Monrose agreed that 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 the teachings of Beser and RFC 2401 and it should maintain its finding.
`
`Independent Claims 1 and 21
`
`B.
`The Board correctly found Beser likely discloses “intercepting” a “request to
`
`lookup an [] IP address.” Dec. at 13-14. 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
`
`32-34. This request is intercepted by each of first network device 14 and trusted-
`
`
`
`7
`
`

`
`IPR2015-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`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
`
`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 22-23. 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
`
`25-26. 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 33-34. 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 19-20, 34; 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 20-21, 34; Ex. 1007
`
`
`
`8
`
`

`
`IPR2015-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`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 21; Ex. 1007 at
`
`21:48-52; see Ex. 1066 at 103:22-104:3 (Dr. Monrose admitting he does not
`
`dispute 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 22. But that 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 remaining
`
`arguments 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
`
`23. 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 23. That position is contrary to Beser’s explicit disclosure.
`
`
`
`9
`
`

`
`IPR2015-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`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-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`second network device 16 instead of terminating device 26. Resp. at 23. But the
`
`claims only specify a request to lookup an “IP address corresponding to a domain
`
`name associated with the target device,” (Ex. 1001 at 55:50-52) (emphasis added),
`
`and the ’705 specification provides that the IP address looked up “need not be the
`
`actual address of the destination computer,” (id. at 40:18-19). Dr. Monrose agreed.
`
`Ex. 1066 at 63:25-64:24. In Beser’s system, the IP address of network device 16
`
`“corresponds” to 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 22. 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 20-21, 34. 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-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`address to terminating device 26. Resp. at 22. 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 32-34. 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 33. 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 33; see also Ex. 1007
`
`
`
`12
`
`

`
`IPR2015-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`at Figs. 4 & 6. The trusted device 30 device thus also “intercepts” the tunneling
`
`request. Pet. at 33-34; 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 25-26. But Patent Owner’s arguments are irrelevant to
`
`what the claims require. The ’705 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:1-3 (emphasis added). The
`
`’705 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:1-3. 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-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`petition explains, the originating device 24 sends tunneling requests to first
`
`network device 14. Pet. at 32-33. 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 32-33;
`
`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 33-34.
`
`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 face, had not 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-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`request pertaining to intended for or ordinarily received by a first entity at another
`
`entity.” Resp. at 24; Ex. 1005 at ¶69. But it mischaracterizes Dr. Tamassia’s
`
`testimony, who was discussing the rationale underpinning his construction, and
`
`was neither proposing nor applying a different construction. Ex. 2015 at 79:9-
`
`80:13, 85:9-12; see Ex. 1005 at ¶68. Even if “intercepting” were 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 11-12), 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 ’705 patent, (Ex. 1001 at 40:3-7).
`
`C. Dependent Claims
`1.
`Claims 3, 10, and 25
`
`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 43-44. This satisfies Petitioner’s construction
`
`of a “secure domain name”: “a name that corresponds to a secure computer
`
`network address.” Pet. at 12; Ex. 1005 at ¶73.
`
`Patent Owner does not contest that Beser discloses a “secure domain name”
`
`
`
`15
`
`

`
`IPR2015-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`under Petitioner’s construction. See Resp. at 33-34. Instead, it 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 Patent Owner’s 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 (181 FH) at 9. Therefore, Patent
`
`Owner’s construction of “secure domain name” as being a “non-standard domain
`
`name” encompasses a telephone number. Beser discloses that the unique identifier
`
`can be a phone number, which satisfies Patent Owner’s construction. Pet. at 18, 43
`
`(citing 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 that claims 3, 10, and 25 are obvious.
`
`2.
`
`Claims 4 and 26
`
`Dependent claims 4 and 26 specify that the encrypted communications
`
`channel is a “broadband connection.” The ’705 patent describes a “broadband”
`
`
`
`16
`
`

`
`IPR2015-00810
`
`
`
`Petitioner’s Reply (Paper 29)
`
`connection as one that includes separate channels, such as a modulated medium.
`
`Ex. 1001 at 34:49-55. Dr. Tamassia explained modulated communications
`
`inherently allow “multiple communications over the communication link (i.e.,
`
`frequency division multiplexing).” Ex. 1005 at ¶80. Petitioner explained that Beser
`
`discloses transmitting data using a cable modem (i.e., modulator-demodulator), and
`
`that when a cable modem transmits data over a television network, it necessarily
`
`uses a broadband connection. Pet. at 44-45; Ex. 1005 at ¶80. Patent Owner argues
`
`Petitioner has not shown that “cable television communications” necessarily use a
`
`broadband connection. Resp. at 34-35. But Petitioner asserted that using a cable
`
`modem over to communicate over a cable television network necessarily used a
`
`broadband connection because the modem allows for multiple channels over the
`
`link. Pet. at 44; see id. at 14. Thus, the Board should find these claims are obvious.
`
`3.
`
`Claims 14 and 31
`
`Patent Owner argues Beser does not disclose that terminating device 26 can
`
`be “a server” as required by these claims. Resp. at 35-37. It notes Beser discloses
`
`an embodiment where originating device 24 is a Web-TV set or a computer
`
`running a multimedia application, (Ex. 1007