Paper No. 21
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`___________________
`
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC,
`Patent Owner.
`___________________
`
`Case No. IPR2017-00337
`U.S. Patent No. 9,038,163
`____________________
`
`
`__________________________________________________________________
`
`
`
`
`
`
`
`
`
`
`
`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. IPR2017-00337
`U.S. Patent No. 9,038,163
`____________________
`
`
`__________________________________________________________________
`
`
`
`
`
`
`
`
`
`
`
`PETITIONER’S REPLY BRIEF
`
`
`
`
`
`
`
`
`
`IPR2017-00337
`
`
`
`Petitioner’s Reply
`
`TABLE OF CONTENTS
`
`Introduction ...................................................................................................... 1
`I.
`Effect of Recent Federal Circuit Opinions ...................................................... 2
`II.
`III. Claim Construction .......................................................................................... 3
`IV. Beser and RFC 2401 Render Claims 1-10, 12-18, 21-31, 33-39, and 42
`Obvious ............................................................................................................ 3
`A.
`Independent Claims 1 and 22 ................................................................ 4
`1.
`As Found in Prior Final Written Decisions Handling
`Substantially Similar Claims, Beser Teaches a Request to Look
`Up an IP Address ........................................................................ 5
`Beser Teaches Evaluating the Request ..................................... 10
`A Person of Ordinary Skill Would Have Combined Beser, RFC
`2401 and RFC 2543 .................................................................. 11
`Dependent Claims ............................................................................... 16
`1.
`Claims 2-4, 13, 23-25, and 34 ................................................... 16
`2.
`Claims 21 and 42....................................................................... 17
`3.
`Claims 5-10, 12, 14-18, 26-31, 33, and 35-39 .......................... 19
`RFC 2401 and RFC 2543 Are Prior Art Printed Publications ............ 19
`C.
`V. Dr. Tamassia’s Testimony Is Probative ......................................................... 22
`VI. Conclusion ..................................................................................................... 25
`
`2.
`3.
`
`B.
`
`
`
`
`
`i
`
`
`
`IPR2017-00337
`
`
`
`
`Petitioner’s Reply
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`Apple Inc. v. VirnetX Inc.,
`IPR2014-00237, Paper 41 (May 11, 2015) ........................................... 1, 9, 16, 18
`Apple Inc. v. VirnetX Inc.,
`IPR2015-00810, Paper 44 (Aug. 30, 2016) .................................................... 1, 19
`Apple Inc. v. VirnetX Inc.,
`IPR2015-00812, Paper 43 (Aug. 30, 2016) .......................................................... 1
`Apple Inc. v. VirnetX Inc.,
`IPR2015-00866, Paper 39 (Sept. 28, 2016) .................................................... 1, 22
`Apple Inc. v. VirnetX Inc.,
`IPR2015-00868, Paper 39 (Sept. 28, 2016) .................................................... 1, 16
`Apple Inc. v. VirnetX Inc.,
`IPR2015-00870, Paper 39 (Sept. 28, 2016) .......................................................... 1
`Apple Inc. v. VirnetX Inc.,
`IPR2016-00331, Paper 29 (June 22, 2017) ........................................................... 1
`Apple Inc. v. VirnetX Inc.,
`IPR2016-00332, Paper 29 (June 22, 2017) ............................................... 4, 18, 19
`Arthrocare Corp. v. Smith & Nephew, Inc.,
`406 F.3d 1365 (Fed. Cir. 2005) ............................................................................ 9
`Belden Inc. v. Berk-Tek LLC,
`805 F.3d 1064 (Fed. Cir. 2015) .......................................................................... 23
`Brand v. Miller,
`487 F.3d 862 (Fed. Cir. 2007) ............................................................................ 23
`Guangdong Xinbao Elec. Appliances Holdings v. Rivera,
`IPR2014-00042, Paper 50 (Feb. 6, 2015) ........................................................... 23
`LG Display Co. v. Innovative Display Techs. LLC,
`IPR2014-01362, Paper 32 (Feb. 8, 2016) ........................................................... 24
`
`
`
`ii
`
`
`
`
`
`Petitioner’s Reply
`
`IPR2017-00337
`
`Poole v. Textron, Inc.,
`192 F.R.D. 494 (D. Md. 2000) ..................................................................... 20, 21
`Schumer v. Lab. Computer Sys., Inc.,
`308 F.3d 1304 (Fed. Cir 2002) ........................................................................... 22
`Sundance, Inc. v. Demonte Fabricating Ltd.,
`550 F.3d 1356 (Fed. Cir. 2008) .......................................................................... 21
`Titanium Metals Corp. of Am. v. Banner,
`778 F.2d 775 (Fed. Cir. 1985) ............................................................................ 24
`United States v. Taylor,
`166 F.R.D. 356 (M.D.N.C. 1996),
`aff’d, 166 F.R.D. 367 (M.D.N.C. 1996) ............................................................. 21
`Virnetx Inc. v. Apple Inc.,
`No. 2015-1934, 2016 WL 7174130 (Fed. Cir. Dec. 9, 2016) .............................. 1
`Virnetx Inc. v. Apple Inc.,
`No. 2016-1211, 2016 WL 7174131 (Fed. Cir. Dec. 9, 2016) .............................. 1
`Statutes
`35 U.S.C. § 6 ............................................................................................................ 23
`Other Authorities
`37 C.F.R. § 42.65(a) ................................................................................................. 24
`37 C.F.R. § 42.73(d)(3) .............................................................................................. 2
`Fed. R. Evid. 702 ............................................................................................... 21, 22
`
`
`
`
`
`iii
`
`
`
`IPR2017-00337
`
`
`
`
`Petitioner’s Reply
`
`EXHIBIT LIST
`
`Exhibit # Reference Name
`1001
`1001 U.S. Patent 9,038,163
`1002
`1002 U.S. Patent 9,038,163 File History
`1003
`1003 Declaration of Roberto Tamassia
`1004
`1004 Curriculum Vitae of Roberto Tamassia
`1005-06 1005-06 [RESERVED]
`1007
`1007 U.S. Patent 6,496,867 to Beser
`1008
`1008 Kent, S., et al., RFC 2401, “Security Architecture for the Internet
`Protocol” (November 1998)
`1009-12 1009-12 [RESERVED]
`1013
`1013 Handley, M., et al., RFC 2543, SIP: Session Initiation Protocol
`(March 1999)
`[RESERVED]
`1014-18
`1019 Microsoft Computer Dictionary (4th Ed.)
`1020 U.S. Patent Number 6,408,336 to Schneider
`1021-31
` [RESERVED]
`1032 Mockapetris, P., RFC 882, “Domain Names – Concepts and Facilities”
`(November 1983)
`1033 Mockapetris, P., RFC 883, “Domain Names – Implementation and
`Specification” (November 1983)
`1034 Mockapetris, P., RFC 1034, “Domain Names – Concepts and
`Facilities” (November 1987)
`1035 Mockapetris, P. RFC 1035, “Domain Names – Implementation and
`Specification” (November 1987)
`Bradner, S., RFC 2026, “The Internet Standards Process – Revision 3”
`(October 1996)
`[RESERVED]
`1037
`1038 W3C and WAP Forum Establish Formal Liason Relationship
`(December 8, 1999)
`1039 Wireless Application Protocol (WAP) Architecture Specification
`(April 30, 1998)
`
`1036
`
`
`
`iv
`
`
`
`IPR2017-00337
`
`
`
`
`Petitioner’s Reply
`
`1043-44
`1045
`
`Exhibit # Reference Name
`1040 H.323 ITU-T Recommendation (February, 1998)
`1041
` [RESERVED]
`1042 VirnetX’s Opening Claim Construction brief, VirnetX, Inc. v. Cicso
`Systems, Inc., et al., Civil Action No. 6:10-cv-417 (EDTX)
`(November 4, 2011)
`[RESERVED]
`Steiner, J., et al., “Kerberos: An Authentication Service for Open
`Network Systems” (January 12, 1988)
`1046 Harkins, D., et al., RFC 2409, “The Internet Key Exchange (IKE)
`(November 1998)
`1047 Maughan, D., et al., “Internet Security Association and Key
`Management Protocol (ISAKMP)” (November 1998)
`1048 Data-Over-Cable Interface Specifications (DOCIS), Radio Frequency
`Interface Specification (March 26, 1997)
`1049 U.S. Patent 6,886,095 to Hind et al.
`1050-51
` [RESERVED]
`1052 U.S. Patent 6,609,148 to Salo et al.
`1053 Dell Computer Corp., Fiscal 1999 in Review (1999)
`1054
` [RESERVED]
`1055 Deposition of Fabian Newman Monrose, PhD., IPR2014-00237,
`Exhibit 1083 (October 23, 2014)
`Declaration of Scott M. Border
`1056
`Declaration of Anna M. Weinberg
`1057
`[RESERVED]
`1058-59
`1060 Declaration of Sandy Ginoza on behalf of the RFC Publisher for the
`Internet Engineering Task Force, dated January 23, 2013, submitted in
`Investigation No. 337-TA-858
`1061 Kent, S., et al., RFC 2401, “Security Architecture for the Internet
`Protocol” (November 1998), bearing Bates Nos. 337-TA-858-
`IETF001122 through 001183
`Redline comparison of Exhibit 1008 (IPR2015-00810) to Exhibit 1061
`Transcript of Feb. 8, 2013 deposition of Sandy Ginoza, ITC Inv. No.
`
`1062
`1063
`
`
`
`v
`
`
`
`IPR2017-00337
`
`
`
`
`Petitioner’s Reply
`
`1064
`
`1066-71
`1072
`
`Exhibit # Reference Name
`337-TA-858
`The Reality of Virtual Private Networks, InfoWorld, Aug. 16, 1999
`(Advertising Supplement)
`1065 Mark Gibbs, IP Security: Keeping your business private,
`NetworkWorld, Mar. 15, 1999
` [RESERVED]
`E. Kaufman & A. Newman, Implementing IPsec: Making Security
`Work on VPNs, Intranets, and Extranets, John Wiley & Sons, Inc.
`(1999)
`1073 U.S. Copyright Office, Registration Form for E. Kaufman & A.
`Newman, Implementing IPsec: Making Security Work on VPNs,
`Intranets, and Extranets, John Wiley & Sons, Inc. (1999)
`Charlie Scott et al., Virtual Private Networks (2nd ed. 1999)
`1075 Patent Owner Response to Office Action, Inter Partes
`Reexamination Control No. 95/001,269 (April 15, 2010)
`Transcript of Trial, Afternoon Session, Nov. 1, 2012 (Case 6-10-cv-
`417)
`Deposition of Fabian Monrose, Ph.D., IPR2015-00810 (Mar. 3, 2016)
`
`1074
`1075
`
`1076
`
`1077
`[NEW]
`
`
`
`vi
`
`
`
`IPR2017-00337
`
`I.
`
`
`
`Petitioner’s Reply
`
`Introduction
`In its Institution Decision, the Board correctly found that Beser, RFC 2401,
`
`and RFC 2543 render claims 1-10, 12-18, 21-31, 33-39, and 42 of U.S. Patent No.
`
`9,038,163 (“the 163 patent”) obvious. Paper 8 (“Dec.”), 11-19. The Board’s
`
`findings are consistent with other Final Written Decisions concerning related
`
`patents, in which claims substantially similar to the 163 patent’s claims were
`
`likewise found obvious in view of Beser and RFC 2401. E.g., IPR2015-00812,
`
`Paper 43 (Aug. 30, 2016); IPR2015-00866, Paper 39 (Sept. 28, 2016).1
`
`In its Response (Paper 17, “Resp.”), Patent Owner makes several narrow
`
`challenges to the substance of the Board’s findings about Beser, RFC 2401 and
`
`RFC 2543; challenges whether RFC 2401 and RFC 2543 are printed publications;
`
`and then asserts that the Board lacks the ability to compare the prior art to the
`
`
`1 See also IPR2016-00331, Paper 29 (June 22, 2017); IPR2015-00810, Paper 44
`
`(Aug. 30, 2016); IPR2015-00868, Paper 39 (Sept. 28, 2016); and IPR2015-00870,
`
`Paper 39 (Sept. 28, 2016); IPR2014-00237, Paper 41 (May 11, 2015); aff’d on
`
`other grounds, Virnetx Inc. v. Apple Inc., No. 2015-1934, 2016 WL 7174130 (Fed.
`
`Cir. Dec. 9, 2016); Virnetx Inc. v. Apple Inc., No. 2016-1211, 2016 WL 7174131,
`
`at *1 (Fed. Cir. Dec. 9, 2016) (affirming IPR2014-00403, IPR2014-00404,
`
`IPR2014-00481, IPR2014-00482).
`
`
`
`1
`
`
`
`IPR2017-00337
`
`challenged claims on its own and instead must rely on expert testimony. In prior
`
`Petitioner’s Reply
`
`
`
`decisions (e.g., in IPR2014-00237, IPR2015-00866, IPR2016-00331, and
`
`IPR2016-00332), the Board has already rejected these arguments based on similar
`
`claim language. Indeed, no issues raised by Patent Owner in this matter have not
`
`already been considered and decided by the Board, and Patent Owner’s arguments
`
`rest largely on unwarranted or incorrect assertions about its claims and the
`
`teachings of Beser, RFC 2401, and RFC 2453. The Board’s initial determination
`
`that the challenged claims are unpatentable is supported by more than substantial
`
`evidence and should be maintained.
`
`II. Effect of Recent Federal Circuit Opinions
`Based on the Federal Circuit’s affirmance of seven final decisions of the
`
`Board on related patents, see Paper No. 14, Petitioner submits that, pursuant to
`
`PTAB rules (37 C.F.R. § 42.73(d)(3)) and the traditional doctrine of collateral
`
`estoppel, Patent Owner is precluded from taking positions that are inconsistent
`
`with the final judgment in those previous proceedings. Applying estoppel under
`
`either basis to issues that have already been finally decided would allow for a more
`
`efficient allocation of Board and party resources in this proceeding. Petitioner
`
`nonetheless recognizes that, after considering this question in other proceedings,
`
`the Board has declined to find Patent Owner estopped, and instead made original
`
`findings based on the evidence before it in each proceeding. Given that the same
`
`
`
`2
`
`
`
`IPR2017-00337
`
`ultimate outcome—that the contested claims are unpatentable—would result from
`
`Petitioner’s Reply
`
`
`
`either making original findings or by finding Patent Owner estopped, Petitioner
`
`reiterates its position to preserve this issue for any subsequent review of the
`
`Board’s judgment in this proceeding.
`
`III. Claim Construction
`Petitioner believes that the constructions set forth in the Petition represent
`
`the broadest reasonable constructions of the claims. Paper 1 (“Pet.”), 9-14. Patent
`
`Owner does not provide any claim construction in the Patent Owner’s Response.
`
`Resp., 2. Under any interpretation proposed by Petitioner or adopted by the Board,
`
`the prior art discloses these limitations as explained below.
`
`IV. Beser and RFC 2401 Render Claims 1-10, 12-18, 21-31, 33-39, and 42
`Obvious
`In its Institution Decision, the Board correctly found that Beser, RFC 2401,
`
`and RFC 2453 render claims 1, 2-10, 12-18, 21-31, 33-39, and 42 of the 163 patent
`
`obvious. In Response, Patent Owner raises three primary challenges to those
`
`findings: (i) Beser does not disclose a “request to look up an internet protocol (IP)
`
`address of the second network device based on an identifier associated with the
`
`second network device”; (ii) Beser does not disclose an “evaluating the request to
`
`determine whether the identifier is registered”; and (iii) a person of ordinary skill
`
`would not have combined Beser and RFC 2401. In addition, Patent Owner
`
`challenges whether RFC 2401 and RFC 2543 were publically accessible.
`
`
`
`3
`
`
`
`IPR2017-00337
`
`
`
`
`Petitioner’s Reply
`
`This panel should reject Patent Owner’s arguments because they were
`
`already considered and rejected by another panel in a proceeding involving a
`
`related patent based on a virtually identical specification and substantially similar
`
`claims. In the Final Written Decision in IPR2014-00237, for example, the Board
`
`found that Beser and RFC 2401 invalidated claims similar to the 163 patent. Paper
`
`41, 37-43 (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,
`
`37-43), and that Beser does not disclose the step of “a request to look up an [] (IP)
`
`address . . . .” (id., 22-28). Additionally, the Board has already rejected Patent
`
`Owner’s arguments against the public accessibility of RFC 2401 and RFC 2453.
`
`IPR2016-00332, Paper 29, at 48-52 (June 22, 2017). In the current proceeding,
`
`Patent Owner simply rehashes those same rejected arguments. This panel should
`
`reject those arguments again. But even if the Board reconsiders Patent Owner’s
`
`arguments on the merits, they must be rejected.
`
`Independent Claims 1 and 22
`A.
`The Board correctly found Beser likely discloses a “request to look up a
`
`network address . . . based on an identifier associated with the second network
`
`device.” Dec. 12, 19. 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., 18-19. This request is intercepted by each of first
`
`
`
`4
`
`
`
`IPR2017-00337
`
`network device 14 and trusted-third-party network device 30. Id. In IPR2014-
`
`Petitioner’s Reply
`
`
`
`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, 24 (May 11, 2015).
`
`Patent Owner argues Beser’s tunneling request is not a “request to look up a
`
`network address” because no single device looks up the IP address of the
`
`terminating device. Resp., 6-10. Patent Owner also argues Beser does not disclose
`
`“evaluating the [tunneling] request to determine whether the [tunneling request’s]
`
`identifier is registered with a name service.” Id., 10-12. Finally, Patent Owner
`
`argues that Beser teaches away from using encryption. Id., 21-27. Each of Patent
`
`Owner’s contentions reflects a misunderstanding of its own claims and a
`
`mischaracterization of what Beser actually discloses.
`
`1.
`
`As Found in Prior Final Written Decisions Handling
`Substantially Similar Claims, Beser Teaches a Request to Look
`Up an IP Address
`The tunneling request sent by originating device 24 is a “request to look up a
`
`network address” because in response to receiving the request, the Beser trusted
`
`device 30 looks up two IP addresses. Pet., 44. First, it consults an internal
`
`database of registered devices to look up the IP address of second network device
`
`
`
`5
`
`
`
`IPR2017-00337
`
`16 that is associated with the unique identifier. Id., 45; Ex. 1007, 11:45-58.
`
`
`
`Petitioner’s Reply
`
`Second, it looks up a private IP address for terminating device 26 by sending a
`
`message to network device 16 requesting the address. Pet., 44; Ex. 1007, 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., 44; Ex. 1007, 21:48-52; see
`
`Ex. 1077, 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 “look up an
`
`[] (IP) address” because trusted device 30 does not “look up” any IP addresses in
`
`response to the request. Resp., 6-10. But that is irrelevant to the claims, which
`
`specify intercepting “a request to look up an [] (IP) address,” and under the
`
`broadest reasonable construction, do not require a look up to be performed, let
`
`alone specify that a particular device perform the look up. Thus, Patent Owner’s
`
`remaining arguments can be dismissed because the claims do not require a look
`
`up.
`
`Based on its incorrect theory that a look up is required, Patent Owner argues
`
`that neither of Beser’s look ups actually look up an IP address. First, Patent
`
`Owner argues Beser does not disclose that trusted device 30 performs a “look up”
`
`of network device 16’s public IP address in response to a tunneling request. Resp.,
`
`6-9. It admits that trusted device 30 contains a database or similar structure that
`
`
`
`6
`
`
`
`IPR2017-00337
`
`correlates each unique identifier to the public IP addresses of a second network
`
`Petitioner’s Reply
`
`
`
`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., 8. Patent Owner also argues that because the database of registered
`
`identifiers is part of Beser’s modification to the conventional DNS functionality,
`
`where the trusted-third-party device is a DNS server, it would only perform a look
`
`up on its conventional DNS tables and would not consult the database. Resp., 9-10.
`
`Those positions are 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, Fig. 5, 11:26-58. Figure 5 has
`
`four steps, and Beser walks through each step sequentially from 9:64 through
`
`12:19. Beser discusses Step 116 in two sequential paragraphs that appear, 11:26-
`
`58, as Dr. Monrose agreed. Ex. 1077, 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, 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
`
`
`
`7
`
`
`
`IPR2017-00337
`
`database is the IP 58 address of a particular second network device 16.” Id., 11:45-
`
`Petitioner’s Reply
`
`
`
`50; see id., 11:55-58 (noting other types of unique identifiers could be used).
`
`Thus, Beser teaches that in Step 114 of Figure 5, trusted device 30 receives the
`
`tunneling request (id., 11:9-20), and in response, it associates an IP address with
`
`the unique identifier by looking it up in its internal database (id., 11:26-58). See
`
`Ex. 1077, 107:15-108:8.
`
`Patent Owner also suggests the Beser tunneling request cannot be one to
`
`“look up an [] (IP) address” because trusted device 30 looks up the public IP
`
`address of second network device 16 instead of terminating device 26. Resp., 7-8.
`
`But the claims only specify “a request to look up a network address of the second
`
`network device based on an identifier associated with the second device,” (Ex.
`
`1001, 56:13-15) (emphasis added), and the 163 specification provides that the IP
`
`address looked up “need not be the actual address of the destination computer,”
`
`(id., 40:48-49). Dr. Monrose agreed. Ex. 1077, 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 “look up” 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., 8-10. That argument is
`
`
`
`8
`
`
`
`IPR2017-00337
`
`premised on a single embodiment in Beser, and ignores that Beser discloses
`
`
`
`Petitioner’s Reply
`
`embodiments where trusted device 30 performs the negotiation with the first and
`
`second network devices (14 & 16). Ex. 1007, 9:29-30, 12:16-19, 14:19-27, Figs. 6
`
`& 9; see Pet., 44. 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., 5-6. 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,
`
`Fig. 9 (packets 164 & 166), 13:33-48, 13:66-14:18; Pet., 21-22, 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, 13:49-64; Pet., 20.
`
`Thus, the Board should find Beser teaches a “request to look up an [] (IP)
`
`address.” IPR2014-00237, Paper 41, 22-23 (May 11, 2015) (finding Beser
`
`discloses such a request).
`
`
`
`9
`
`
`
`IPR2017-00337
`
`
`
`
`Petitioner’s Reply
`
`Beser Teaches Evaluating the Request
`2.
`Beser’s trusted-third-party network device can be a modified domain name
`
`server that maintains a database of subscribers. Pet., 45; Ex. 1007, 4:55-63, 11:32-
`
`36, 11:48-52; Ex. 1003, ¶¶ 158-61. The database maps each subscriber’s unique
`
`identifier to IP addresses including associated IP addresses for the second network
`
`device and terminating device. Pet., 45; Ex. 1007, 11:48-52; Ex. 1003, ¶¶ 162-65.
`
`Upon receipt of a tunneling request, the trusted-third-party network device
`
`searches the database for the entry that matches a registered unique identifier. Pet.,
`
`45; Ex. 1007, 11:45-58. If the unique identifier is registered—matches an entry—
`
`as a subscriber of the modified domain name server, the trusted-third-party
`
`network device to negotiate and establish a tunnel between those network devices
`
`using the IP addresses. Pet., 45; Ex. 1007, 9:6-11, 11:59-62, 9:26-30, 11:9-36; Ex.
`
`1003, ¶¶ 165-66, 178-80. Petitioner explained that Beser thus discloses
`
`“evaluating” whether the request’s “identifier is registered with a name server,”
`
`e.g., Beser’s trusted-third-party network device. Pet. 45.
`
`Patent Owner contends Beser does not disclose evaluating the tunneling
`
`request to determine whether the identifier specified in the tunneling request is
`
`registered with a third party device. Resp., 10-11. But this is precisely what Beser
`
`requires in order to negotiate and establish a tunnel between network devices. Ex.
`
`1003, ¶ 163, 165-166. For a tunnel request, Beser matches the unique identifier
`
`
`
`10
`
`
`
`IPR2017-00337
`
`with ones listed in trusted-third-party network device to obtain stored IP addresses.
`
`Petitioner’s Reply
`
`
`
`Ex. 1007, 11:26-55. The trusted-third-party network device uses the IP addresses
`
`to negotiate and establish a tunnel between those network devices. Ex. 1003, ¶166;
`
`see IPR2014-00237, Paper 41, 30 (May 11, 2015) (“Without that domain name
`
`listing in Beser’s DNS, Beser cannot return a private address for that domain name
`
`(or associate it with devices 16 and 26).”).
`
`Patent Owner also repeats the same argument presented elsewhere in the
`
`Patent Owner’s Response—Patent Owner again contends Beser never suggests that
`
`the data structure is looked up when the tunnel request is received by the device
`
`30. Resp., 8, 11. As discussed above, see §IV.A.1, Patent Owner is wrong.
`
`3.
`
`A Person of Ordinary Skill Would Have Combined Beser, RFC
`2401 and RFC 2543
`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., 33-38; Ex. 1003, ¶¶ 221-241. 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., 35; Ex. 1003, ¶¶ 237-38.
`
`
`
`11
`
`
`
`IPR2017-00337
`
`
`
`
`Petitioner’s Reply
`
`In its Response, Patent Owner primarily repeats the arguments it raised in
`
`IPR2014-00237, which the Board rejected. See Paper 41, 37-41 (May 11, 2015);
`
`Paper 30, 56-58 (Aug. 29, 2014). Patent Owner again argues that Beser’s
`
`statements recognizing that encryption can present practical challenges in some
`
`circumstances “teaches away” from the use of encryption. Resp., 15-18.2 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, 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., 11:22-25; Pet., 33). Beser also criticizes prior
`
`art IP tunneling methods that sometimes prevent use of encryption, (Ex. 1007, 2:1-
`
`8, 2:22-24), and states its tunneling method is intended to overcome such
`
`problems, (id., 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. 1003, ¶¶ 233-241.
`
`Neither Patent Owner nor Dr. Monrose have asserted Beser’s tunneling
`
`method is technically incompatible with encryption – they simply raise practical
`
`
`2 Patent Owner argues only against the combination of Beser with RFC 2401, and
`
`does not dispute the obviousness of the combination with RFC 2543.
`
`
`
`12
`
`
`
`IPR2017-00337
`
`concerns that only affect some configurations of the system. During his
`
`
`
`Petitioner’s Reply
`
`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. 1077, 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., 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. See Ex. 1003, ¶¶ 227-228 (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., 13-14. 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. 1055, 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,
`
`
`
`13
`
`
`
`IPR2017-00337
`
`and therefore, it was designed to replace computationally expensive security
`
`
`
`Petitioner’s Reply
`
`techniques such as encryption. Resp., 16-17. 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, 2:36-40, 3:4-9. Beser explains users increasingly had
`
`privacy concerns, (id., 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., 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., 2:1-5, 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. Id., 2:22-24; see also id., 1:54-2:35; see Pet.,
`
`36. Beser also notes that both encryption and prior art IP tunnels were
`
`computationally expensive. Ex. 1007, 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. Id., 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., 2:33-35), Beser’s IP tunnel has a low
`
`
`
`14
`
`
`
`IPR2017-00337
`
`“computational burden,” (id., 3:4-9). Because of its low computational burden,
`
`Petitioner’s Reply
`
`
`
`Beser’s method is flexible and can be integrated into existing communications
`
`systems and combined with other security techniques. See Ex. 1003, ¶¶ 138; Ex.
`
`1007, 3:4-9, 4:55-5:2. Beser’s tunneling method also can be combined with
`
`encryption: Beser specifically notes that its IP tunnel can improve the security of
`
`encryption by helping to “prevent a hacker from intercepting all media flow
`
`between the ends,” (id., 2:36-40), and from “accumulating . . . sufficient
`
`information to decrypt the message” (id.,
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
