Paper No. 28
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`___________________
`
`
`
`
`
`
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC,
`Patent Owner.
`___________________
`
`Case No. IPR2015-00812
`U.S. Patent No. 8,850,009
`____________________
`
`
`Before KARL D. EASTHOM, JENNIFER S. BISK, and
`GREGG I. ANDERSON, Administrative Patent Judges.
`
`__________________________________________________________________
`
`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-00812
`U.S. Patent No. 8,850,009
`____________________
`
`
`Before KARL D. EASTHOM, JENNIFER S. BISK, and
`GREGG I. ANDERSON, Administrative Patent Judges.
`
`__________________________________________________________________
`
`PETITIONER’S REPLY BRIEF
`
`
`
`
`
`
`
`
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`Table of Contents
`
`I.
`
`II.
`
`Introduction ...................................................................................................... 1
`
`Claim Construction .......................................................................................... 1
`
`III. Beser and RFC 2401 Render Claims 1-8,10-20, and 22-25 Obvious ............. 2
`
`A. A Person of Ordinary Skill Would Have Combined Beser and RFC
`2401 ....................................................................................................... 3
`
`B.
`
`Independent Claims 1 and 14 ................................................................ 8
`
`1.
`
`2.
`
`3.
`
`Beser Teaches a DNS Request to Lookup an Address ............... 9
`
`Beser Teaches “Interception” of a DNS Request ..................... 14
`
`Beser Teaches that Originating Device 24 Receives an
`Indication, a Network Address, and Provisioning Information 17
`
`C.
`
`Dependent Claims 2-8,10-13, 15-20, and 22-25 ................................. 18
`
`IV. RFC 2401 Is a Prior Art Printed Publication ................................................. 18
`
`A.
`
`B.
`
`The Evidence Shows RFC 2401 Is a Prior Art Printed Publication ... 18
`
`Patent Owner’s Arguments Lack Any Merit ...................................... 20
`
`V. Dr. Tamassia’s Testimony Is Probative ......................................................... 23
`
`VI. Conclusion ..................................................................................................... 25
`
`
`
`
`
`i
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`Arthrocare Corp. v. Smith & Nephew, Inc.,
`406 F.3d 1365 (Fed. Cir. 2005) .......................................................................... 13
`
`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
`
`Schumer v. Lab. Computer Sys., Inc.,
`308 F.3d 1304 (Fed. Cir 2002) ........................................................................... 23
`
`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 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
`
`Statutes
`
`35 U.S.C. § 6 ............................................................................................................ 25
`
`
`
`ii
`
`
`
`IPR2015-00812
`
`Other Authorities
`
`
`
`Petitioner’s Reply (Paper 28)
`
`37 CFR 42.65(a) ....................................................................................................... 25
`
`Fed. R. Evid. 702 ..................................................................................................... 23
`
`
`
`
`
`iii
`
`
`
`IPR2015-00812
`
`I.
`
`Introduction
`
`
`
`Petitioner’s Reply (Paper 28)
`
`In its Institution Decision, the Board correctly found that Beser and RFC
`
`2401 render claims 1-8,10-20, and 22-25 of the ’009 patent obvious. Paper 8
`
`(Dec.) at 10-14. In its Response (“Resp.”) (Paper 24), 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 render the
`
`claims obvious.
`
`
`
`1
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`Many of the terms Patent Owner construes in its Response are irrelevant to
`
`this proceeding because it never challenges that Beser and RFC 2401 teach them.
`
`These include: “encrypted communication link,” (Resp. at 5-7), “provisioning
`
`information,” (id. at 7-10), “secure communications service,” (id. at 10-11),
`
`“[VPN] communication link,” (id. at 12-22), “domain name,” (id. at 22), and
`
`“modulation,” (id. at 23). The Board need not address the remaining term
`
`“interception,” (id. at 4-5), because as explained below, under any interpretation
`
`proposed by Petitioner or Patent Owner, or adopted by the Board, Beser and RFC
`
`2401 discloses this limitations. Finally, Patent Owner agrees with Petitioner’s
`
`construction of “[]DNS request” so the Board need not revisit this term. Id. at 3.
`
`III. Beser and RFC 2401 Render Claims 1-8,10-20, and 22-25 Obvious
`The Board correctly found that Beser and RFC 2401 render claims 1-8,10-
`
`20, and 22-25 obvious. In its Response, Patent Owner raises four 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,” (iii) Beser does not disclose “interception” of such a request, and (iv)
`
`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 already were rejected by another panel in a proceeding involving a related
`
`
`
`2
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`patent. In the Final Written Decision in IPR2014-00237, the Board found that
`
`Beser and RFC 2401 rendered claims containing elements similar to the ’009
`
`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 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 30-34; 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 32; 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 10-12.
`
`
`
`3
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`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, 38-41.
`
`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 a person of ordinary skill would have had
`
`
`
`4
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`computational concerns only if IPsec was configured to use certain types of
`
`encryption. Ex. 1066 at 80:20-81:8, 82:7-17. Dr. Monrose also admitted that a
`
`person of ordinary skill in the art in February 2000 generally 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 the configuration of a system 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 35. 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 36, 38. But Patent Owner mischaracterizes
`
`the purpose of Beser’s design. Beser was designed to provide a better method for
`
`
`
`5
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`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; see 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 33. 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;
`
`
`
`6
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`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).
`
`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; see id. at
`
`14-15 (recognizing the difference between privacy and security). 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 should maintain its finding.
`
`
`
`7
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`Independent Claims 1 and 14
`
`B.
`The Board correctly found Beser likely discloses the “interception” of a “[]
`
`DNS request to lookup a network address.” 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
`
`35-37. This request is intercepted by each of first network device 14 and trusted-
`
`third-party network device 30, which can be a DNS server. 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 that Beser’s tunneling request is not a “DNS request to
`
`lookup a network address” because it is not a “DNS request” and no single device
`
`looks up the address of the terminating device. Resp. at 27-30. 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 30-33. Finally, it argues that Beser
`
`and RFC 2401 do not show that originating device 24 receives all three elements
`
`specified by the “receiving” step. Id. at 40-42. Each of Patent Owner’s
`
`
`
`8
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`contentions reflects a misunderstanding of its own claims and a
`
`mischaracterization of what Beser actually discloses.
`
`1.
`
`Beser Teaches a DNS Request to Lookup an Address
`
`The tunneling request sent by originating device 24 is a “DNS request to
`
`lookup a network address” because in one embodiment the Beser trusted-third-
`
`party network device 30 is a DNS server, and when trusted device 30 receives a
`
`tunneling request, it uses the domain name in the request to lookup two IP
`
`addresses. Pet. at 36-37. For the first address, it consults an internal database of
`
`registered devices to look up the IP address of the second network device 16 that is
`
`associated with the unique identifier. Id. at 23, 36; Ex. 1007 at 11:45-55. For the
`
`second address, it looks up a private IP address for the terminating device 26 by
`
`sending a message to network device 16 requesting the address. Pet. at 23, 36; Ex.
`
`1007 at 9:29-30, 12:16-19, 14:19-27, Figs. 6 & 9. As a result of this process,
`
`originating device 24 ultimately receives an IP address for terminating device 26.
`
`Pet. at 25; Ex. 1007 at 21:48-52; see Ex. 1066 at 103:22-104:3 (Dr. Monrose
`
`admitting he does not dispute that the originating device receives an IP address for
`
`the terminating device).
`
`Patent Owner asserts Beser does not disclose this element, and raises several
`
`challenges. First, Patent Owner argues that the “tunneling request” is not a “DNS
`
`request” because Beser does not disclose that tunneling requests follow the DNS
`
`
`
`9
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`protocol. Resp. at 28. But nothing in the parties’ agreed upon construction for
`
`“DNS request” requires it to follow the DNS protocol. See Resp. at 3. Even if the
`
`claimed “DNS request” did need to follow the DNS protocol, Beser teaches that
`
`the tunneling request follows that protocol. See Ex. 1007 at 1:50-53, 4:9-11. In his
`
`declaration, Dr. Tamassia noted that the trusted-third-party network device 30
`
`could be a DNS server and explained that the “functionality of a DNS server was
`
`extremely well-known by February 2000.” Ex. 1005 at ¶306; see id. at ¶¶303, 307.
`
`He also explained that “a unique identifier could be a domain name (e.g. if a web
`
`browser made a request for a website),” (id. at ¶319), and that in response to
`
`tunneling requests, trusted device 30 would resolve domain names into IP
`
`addresses, (id. at ¶¶327-28). A person of ordinary skill would have understood that
`
`when a request to resolve a domain name is sent to a DNS server, that request
`
`follows the DNS protocol. Id. at ¶306; see Ex. 1007 at 1:50-53. Dr. Tamassia
`
`explained that DNS servers were extremely well-known, and a person of ordinary
`
`skill would have known what the DNS protocol was. Ex. 1005 at ¶306; Ex. 1066
`
`at 84:5-86:3 (Dr. Monrose admitting a person of ordinary skill would have been
`
`well aware of what “the DNS protocol” was).
`
`Next, Patent Owner argues that the tunneling request is not a request to
`
`“lookup a network address” because the trusted device 30 does not “look up” any
`
`IP addresses in response to a tunneling request. Resp. at 28-29. But that argument
`
`
`
`10
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`is irrelevant to the claims, which simply specify an “interception of the DNS
`
`request,” and under the broadest reasonable construction, do not require a DNS
`
`lookup to be performed, let alone specify that a particular device perform a lookup.
`
`The claims simply do not require a lookup, and thus Patent Owner’s remaining
`
`arguments can be dismissed.
`
`Based on its incorrect theory that a lookup is required, Patent Owner next
`
`argues that neither of Beser’s lookups actually lookup an IP address. Patent Owner
`
`first 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
`
`29. Patent Owner admits that trusted device 30 contains a database or similar data
`
`structure that correlates each unique identifier to the public IP addresses of second
`
`network device 16 and terminating device 26, but asserts that Beser “never
`
`suggests that this data structure is looked up when the tunnel request is received by
`
`device 30.” Resp. at 29. Patent Owner’s 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
`
`four steps, and Beser walks through each step sequentially on 9:64 to 12:19. See
`
`
`
`11
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`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:24-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-16), 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 tunneling request cannot be one to “lookup a
`
`network address” because trusted device 30 looks up the public IP address of the
`
`second network device 16 instead of the public IP address of the terminating
`
`device 26. Resp. at 29. But the claims only specify a request to lookup “a network
`
`address of a second network device based on an identifier associated with [that]
`
`device,” (Ex. 1003 at 56:28-30), and the ’009 specification provides that the IP
`
`address looked up “need not be the actual address of the destination computer,” Ex.
`
`
`
`12
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`1003 at 40:52-57. See Ex. 1066 at 63:25-64:24. In Beser’s system, the IP address
`
`of the second network device is looked up “based on” the unique identifier (e.g.,
`
`domain name) associated with the terminating device. Thus the lookup meets the
`
`language of the claims.
`
`Finally, Patent Owner challenges Beser’s second network address “lookup”
`
`by arguing first and second network devices (14 & 16), and not trusted device 30,
`
`negotiate private IP addresses for the end devices (24 & 26). Resp. at 28-29.
`
`Patent Owner’s argument is premised on a single embodiment in Beser, and it
`
`simply ignores that Beser discloses embodiments where the trusted-third-party
`
`network 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 & 9; see Pet.
`
`at 24, 36. Petitioner showed 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. at 29. 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
`
`
`
`13
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`sends a message to network device 16 requesting a private IP address. Ex. 1007 at
`
`Fig. 9 (packets 164 and 166), 13:33-14:18; Pet. at 23, 41 (discussing same). Two,
`
`second network 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 24. Thus, the Board should find that Beser teaches a “DNS request to
`
`lookup a network address.” See IPR2014-00237, Paper 41 at 22-24 (finding that
`
`Beser discloses a request to lookup an IP address).
`
`2.
`
`Beser Teaches “Interception” of a DNS Request
`
`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 to trusted
`
`device 30, (id. at 8:3-7, 8:48-49). Pet. at 33; see also Ex. 1007 at Figs. 4 & 6. The
`
`trusted-third-party network 30 device thus also “intercepts” the tunneling request.
`
`Pet. at 33-34; see also IPR2014-00237, Paper 41 at 23-24.
`
`
`
`14
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`In its Response, 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 32-33. But Patent Owner’s arguments
`
`are irrelevant to what the claims require. The only disclosure in the ’009 patent of
`
`a DNS device that “intercepts” lookup requests is DNS proxy 2610, which
`
`“intercepts all DNS lookup functions from client 2605.” Ex. 1003 at 40:39-41
`
`(emphasis added). The ’009 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:39-41. Dr. Monrose agreed
`
`that the DNS proxy in the ’009 patent 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 an “interception” because the system is designed such that IP
`
`tunnel requests are received by network device 14 and trusted device 30.
`
`Moreover, Patent Owner mischaracterizes Beser. Even if an “interception”
`
`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
`
`petition explains, the originating device 24 sends tunneling requests to first
`
`
`
`15
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`network device 14. Pet. at 37-38. 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 37-38;
`
`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-38.
`
`All of Patent Owner’s arguments about “interception” are anchored on it
`
`including an “intent” element, and not on any of the actual proposed constructions.
`
`Resp. at 30-33; 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 of
`
`“intercepting,” and in fact, had no opinion of what the term “intercepting”
`
`requires). The Board can reject those arguments because no one in this proceeding
`
`has advanced such a construction of “interception.” 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
`
`
`
`16
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`entity.” See Resp. at 31; 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 “interception” 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 4), 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 ’009 patent, (Ex. 1003 at 40:41-45).
`
`3.
`
`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 40-41. 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 40-44. Claims 1 and 14 specify that a first device
`
`“receive” “(1) an indication that the second network device is available . . ., (2) the
`
`requested network address of the second network device, and (3) provisioning
`
`information for an encrypted communication link.” Ex. 1003 at 56:31-38. Patent
`
`Owner asserts that Petitioner relied on the same two features in Beser for the
`
`
`
`17
`
`
`
`IPR2015-00812
`
`
`
`Petitioner’s Reply (Paper 28)
`
`indication and the requested network address, but Patent Owner is wrong.
`
`Petitioner explained that after Beser’s originating device 24 sends out a tunneling
`
`request, it receives the private IP address of the terminating device 26 as well as its
`
`own private IP address. Pet at 41-42; Ex. 1007 at 21:48-62. The originating
`
`device 24 receives the claimed “(2) the requested network address” because it
`
`receives the private IP address of terminating device 26. Pet. at 42. It also
`
`receives the claimed “(1) indication” because originating device 24 receives a
`
`second private IP address: its own.1
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
