`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`___________________
`
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC,
`Patent Owner.
`___________________
`
`Case No. IPR2016-01585
`U.S. Patent No. 8,904,516
`____________________
`
`
`__________________________________________________________________
`
`PETITIONER’S REPLY BRIEF
`
`
`
`Paper No. 19
`
`
`
`
`
`
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`TABLE OF CONTENTS
`
`2.
`
`Introduction ...................................................................................................... 1
`I.
`Effect of Recent Federal Circuit Opinions ...................................................... 2
`II.
`III. Claim Construction .......................................................................................... 3
`IV. Beser and RFC 2401 Render Claims 1-9, 11-23, and 25-28 Obvious ............ 3
`A.
`Independent Claims 1 and 15 ................................................................ 4
`1.
`As Found in Prior Final Written Decisions Handling
`Substantially Similar Claims, Beser Teaches a Request to Look
`Up an IP Address ........................................................................ 5
`A Person of Ordinary Skill Would Have Combined Beser and
`RFC 2401 .................................................................................... 9
`Dependent Claims ............................................................................... 14
`1.
`Claims 2, 12, 16, and 26 ........................................................... 14
`2.
`Claims 3-4 and 17-18 ................................................................ 15
`3.
`Claims 5-9, 11-14, 19-23, and 25-28 ........................................ 16
`RFC 2401 Is a Prior Art Printed Publication ................................................. 17
`V.
`VI. Dr. Tamassia’s Testimony Is Probative ......................................................... 19
`VII. Conclusion ..................................................................................................... 22
`
`
`B.
`
`
`
`i
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`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) .......................................................................... 21
`Brand v. Miller,
`487 F.3d 862 (Fed. Cir. 2007) ............................................................................ 21
`Guangdong Xinbao Elec. Appliances Holdings v. Rivera,
`IPR2014-00042, Paper 50 (Feb. 6, 2015) ........................................................... 21
`Laird Tech., Inc., v. Graftech Int’l Holdings, Inc.,
`IPR2014-00023, Paper 49 (Mar. 25, 2015) ........................................................ 15
`LG Display Co., Ltd, v. Innovative Display Techs. LLC,
`IPR2014-01362, Paper 32 (Feb. 8, 2016) ........................................................... 22
`Poole v. Textron, Inc.,
`192 F.R.D. 494 (D. Md. 2000) ........................................................................... 19
`Randall Mfg. v. Rea,
`733 F.3d 1355 (Fed. Cir. 2013) .......................................................................... 15
`Schumer v. Lab. Computer Sys., Inc.,
`308 F.3d 1304 (Fed. Cir 2002) ........................................................................... 20
`Sundance, Inc. v. Demonte Fabricating Ltd.,
`550 F.3d 1356 (Fed. Cir. 2008) .......................................................................... 19
`Titanium Metals Corp. of America v. Banner,
`778 F.2d 775 (Fed. Cir. 1985) ............................................................................ 21
`U.S. v. Taylor,
`166 F.R.D. 356, 361 (M.D.N.C.) aff’d, 166 F.R.D. 367 (M.D.N.C.
`1996) ................................................................................................................... 19
`
`
`
`
`ii
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`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 ............................................................................................................ 21
`Other Authorities
`37 C.F.R. § 42.65 ..................................................................................................... 16
`37 C.F.R. § 42.65(a) ........................................................................................... 19, 22
`37 C.F.R. § 42.73(d)(3) .............................................................................................. 2
`Fed. R. Evid. 702 ............................................................................................... 19, 20
`
`
`
`
`
`
`
`iii
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`I.
`
`Introduction
`In its Institution Decision, the Board correctly found that Beser and RFC
`
`2401 render claims 1-9, 11-23, and 25-28 of the 516 patent obvious. Paper 9
`
`(“Dec.”), 15-31 (Feb. 22, 2017). The Board’s findings are consistent with other
`
`Final Written Decisions concerning related patents, in which claims substantially
`
`similar to the 516 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 14, “Resp.”), 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
`
`
`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 14, 2014); 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
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`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. In
`
`prior decisions (e.g., in IPR2015-00866, IPR2014-00237, and IPR2016-00331), the
`
`Board has already addressed these arguments based on similar claim language.
`
`Indeed, no issues are raised in this matter that have not already been previously
`
`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
`
`and RFC 2401. 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. 8, 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
`
`
`
`
`2
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`findings based on the evidence before it in each proceeding. Given that the same
`
`ultimate outcome would result from either making original findings or by finding
`
`that Patent Owner estopped—that the contested claims are unpatentable—
`
`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. 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 those terms. These include:
`
`“intercept[ing] … a[/the] request,” (Resp., 3-6), “server,” (id., 10), “domain name,”
`
`(id., 10-11), and “modulation,” (id., 11).
`
`The Board need not address the remaining two, i.e., “secure communications
`
`service” and “encrypted communication link,” (id., 6-10), because as explained
`
`below, under any interpretation proposed by Petitioner or Patent Owner, or adopted
`
`by the Board, Beser and RFC 2401 disclose these limitations.
`
`IV. Beser and RFC 2401 Render Claims 1-9, 11-23, and 25-28 Obvious
`The Board correctly found that Beser and RFC 2401 render claims 1-9, 11-
`
`23, and 25-28 obvious. In its Response, Patent Owner raises two primary
`
`challenges to those findings: (i) Beser does not disclose a “request to look up an
`
`
`
`
`3
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`internet protocol (IP) address of the second network device based on an identifier
`
`associated with the second network device” and (ii) a person of ordinary skill
`
`would not have combined Beser and RFC 2401.
`
`Initially, this panel should reject Patent Owner’s arguments because they
`
`were already considered by another panel in a proceeding involving a related
`
`patent based on a virtually identical specification and substantially similar claims
`
`and were rejected. In the Final Written Decision in IPR2014-00237, for example,
`
`the Board found that Beser and RFC 2401 rendered claims containing claims
`
`involving elements similar to the 516 patent invalid. 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 each step of it of “a request to look up an [] IP address .
`
`. .” (id., 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.
`
`Independent Claims 1 and 15
`A.
`The Board correctly found Beser likely discloses “request to look up an
`
`internet protocol (IP) address . . . based on an identifier associated with the second
`
`network device.” Dec., 21-24. As explained in the Petition (“Pet.”), Beser shows
`
`
`
`
`4
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`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.,
`
`37-39. This request is intercepted by each of first network device 14 and trusted-
`
`third-party network device 30. Id. In IPR2014-00237, the Board relied on this
`
`same request in finding that “Beser’s trusted-third-party device 30 is ‘informed of
`
`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
`
`an IP address” because no single device looks up the IP address of the terminating
`
`device. Resp., 17-21. Patent Owner also 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
`
`an [] IP address” because in response to receiving the request, the Beser trusted
`
`device 30 looks up two IP addresses. Pet., 39. First, it consults an internal
`
`database of registered devices to look up the IP address of second network device
`
`
`
`
`5
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`16 that is associated with the unique identifier. Id., 39-40; Ex. 1007, 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., 39-41; 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., 41-42; Ex. 1007, 21:48-
`
`52; see Ex. 1075, 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., 17-21. 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.,
`
`18-19. 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
`
`
`
`
`6
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`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., 19. 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., 19-
`
`21. 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 on 9:64 to 12:19.
`
`Beser discusses Step 116 in two sequential paragraphs that appear, 11:26-58, as Dr.
`
`Monrose agreed. Ex. 1075, 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 database
`
`is the IP 58 address of a particular second network device 16.” Id., 11:45-50; see
`
`
`
`
`7
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`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. 1075,
`
`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., 19. But the
`
`claims only specify “a request to look up an [] IP address of a second network
`
`device based on an identifier associated with the second device,” (Ex. 1001, 56:16-
`
`19) (emphasis added), and the 516 specification provides that the IP address looked
`
`up “need not be the actual address of the destination computer,” (id., 40:51-52).
`
`Dr. Monrose agreed. Ex. 1075, 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., 19-21. That argument is
`
`premised on a single embodiment in Beser, and ignores that Beser discloses
`
`
`
`
`8
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`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
`
`and 9; see Pet., 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
`
`address to terminating device 26. Resp., 18-19. That argument fails for, 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:34-48, 13:66-14:18; Pet., 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, 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).
`
`2.
`
`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
`9
`
`
`
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`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., 30-35; Ex. 1003, ¶¶217-237. 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., 31-32; Ex. 1003, ¶¶233-34. In its
`
`Institution Decision, the Board agreed and preliminarily found a person of ordinary
`
`skill would have combined Beser and RFC 2401. Dec., 27.
`
`In its Response, Patent Owner primarily repeats the arguments it raised in
`
`IPR2014-00237, which were rejected by the Board. See Paper 41, 37-41 (May 11,
`
`2015); Paper 30, 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., 21-27. 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., 31. Beser also criticizes prior
`
`art IP tunneling methods that sometimes prevent use of encryption, (Ex. 1007, 2:1-
`
`
`
`
`10
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`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, ¶¶219-221, 224-225, 233-234.
`
`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. During 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. 1075, 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, ¶¶ 224-225 (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., 22-23. But adding more computing power is one
`
`
`
`
`11
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`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,
`
`and therefore, it was designed to replace computationally expensive security
`
`techniques such as encryption. Resp., 22-23. 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; id., 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.,
`
`
`
`
`12
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`31-32. 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
`
`“computational burden,” (id., 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. 1003, ¶¶ 223, 228;
`
`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., 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., 25; see id., 23-24 (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
`
`
`
`
`13
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`addresses of the end devices, as Patent Owner recognizes. Resp., 21-22. 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. 1075, 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.
`
`B. Dependent Claims
`Claims 2, 12, 16, and 26
`1.
`Claims 2, 12, 16, and 26 specify that audio and/or video conferencing data
`
`are encrypted as they are transmitted over the communication link. Petitioner
`
`explained that it would have been obvious to configure Beser to encrypt all data
`
`transmitted through its tunnel—including audio and video data—based on RFC
`
`2401. Pet., 47-49; see Ex. 1003, ¶¶ 164, 222, 224-25. The Board has previously
`
`found Beser and RFC 2401 to render substantially similar limitations obvious. E.g.,
`
`IPR2014-00237, Paper 41, 37-41 (May 11, 2015); IPR2015-00868, Paper 39, 41-
`
`42 (Sept. 28, 2016).
`
`Patent Owner argues Beser teaches away from encrypting “at least one of
`
`the encrypted video data and audio data” for the same reasons as independent
`
`claims 1 and 15. Resp., 27-28. As discussed above, see § IV.A, Patent Owner is
`
`
`
`
`14
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`wrong. See Ex. 1055, 206:20-208:7, 211:16-212:2.
`
`Claims 3-4 and 17-18
`2.
`Petitioner explained it would have been obvious to send email through
`
`Beser’s IP tunnel per claims 3-4 and 17-18 “because [Beser] already transmits
`
`other types of communication data such as audio and video, and extending it to e-
`
`mail would have been an obvious design choice.” Pet., 49-50; Ex. 1003, ¶164 (“E-
`
`mail is a type of data . . . and transmitting it via Beser’s secure IP tunnel would
`
`protect it in the same way.”). It also pointed to Beser’s use of email addresses and
`
`disclosure that “the ends of the data flow may be other types of network devices”
`
`as suggestions for such a modification. Pet., 49; Ex. 1003, ¶¶ 128 and 164.
`
`Patent Owner argues Petitioner did not explain “why it would have been
`
`obvious” but focuses on the Petition’s use of the words “design choice” instead of
`
`addressing the actual analysis. Resp., 30-31. Thus, Petitioner’s analysis and
`
`supporting evidence are unrebutted. Patent Owner also attacks Petitioner for citing
`
`to evidence to support Dr. Tamassia’s opinion that sending email over a VPN was
`
`well known in early 2000. Resp., 29. But “the knowledge of [an ordinary] artisan
`
`is part of the store of public knowledge that must be consulted when considering
`
`whether a claimed invention would have been obvious.” Randall Mfg. v. Rea, 733
`
`F.3d 1355, 1363 (Fed. Cir. 2013) (reversing Board non-obviousness determination
`
`for not considering supporting evidence); see Laird Tech., Inc., v. Graftech Int’l
`
`
`
`
`15
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`Holdings, Inc., IPR2014-00023, Paper 49, 20-21 (Mar. 25, 2015). It was proper to
`
`cite to supporting evidence to corroborate Dr. Tamassia’s opinion on this issue. See
`
`37 C.F.R. § 42.65.
`
`Petitioner explained it would have been obvious to send email through
`
`Beser’s IP tunnel per claims 3-4 and 17-18 “because [Beser] already transmits
`
`other types of communication data such as audio and video, and extending it to
`
`email would have been an obvious design choice.” Pet., 49-50; Ex. 1003, ¶164. It
`
`also pointed to Beser’s use of email addresses and disclosure that “the ends of the
`
`data flow may be other types of network devices” as suggestions for such a
`
`modification. Pet., 49; Ex. 1003, ¶¶139-43. In IPR2015-00866, the Board found
`
`substantially similar limitations would have been obvious in view of Beser and
`
`RFC 2401. Paper 39, 39-40 (Sept. 28, 2016).
`
`Patent Owner argues Petitioner has not shown adding email to Beser would
`
`have been “predictable.” Resp. 31. But Dr. Tamassia explained that sending email
`
`over a VPN was well known in early 2000, and it would have been a routine task
`
`to send e-mail via Beser’s tunnel because it would have worked the same way as
`
`sending other types of data. Ex. 1003, ¶164. In contrast, Dr. Monrose has not
`
`previously expressed an opinion on whether e-mail could be sent through Beser.
`
`E.g., Ex. 2025, 98:10-100:6.
`
`3.
`
`Claims 5-9, 11-14, 19-23, and 25-28
`
`
`
`
`16
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`Patent Owner does not separately challenge these claims so they rise and fall
`
`with claims 1 and 15. Resp., 32-33.
`
`V. RFC 2401 Is a Prior Art Printed Publication
`As the Board has previously found, RFC 2401 was published in November
`
`1998. Pet., 23-25. RFC 2401 states its “[d]istribution... is unlimited.” Ex. 1008, 1.
`
`As explained in the Petition and by Dr. Tamassia, RFC documents are the official
`
`publication channel for Internet standards, the publication process is described in
`
`RFC 2026 (Ex. 1036), and RFCs can be downloaded by anyone via the Internet.
`
`Pet., 23-25; Ex. 1003, ¶¶116-23; Ex. 2019, 103:1-12; Ex. 1036, 5-6. As the Board
`
`found in Final Written Decisions in IPR2015-00810, -00812, -00866, -00868, and -
`
`00870, the publication information in RFC 2401 itself, along with RFC 2026 and
`
`Dr. Tamassia’s testimony is sufficient to establish RFC 2401 was published and
`
`publicly available, and thus, is prior art. E.g., IPR2015-00810, Paper 44, 23-27
`
`(Aug. 30, 2016). That evidence is corroborated by testimony the Internet
`
`Engineering Task Force (IETF), (Ex. 1060, ¶¶1-5, 105-107; Ex. 1063, 39:14-
`
`40:24) and by industry publications, (Ex. 1064, 9; Ex. 1065, 3).
`
`Patent Owner mounts two challenges to RFC 2401, both of which have been
`
`repeatedly rejected by the Board. First, Patent Owner asserts the evidence
`
`submitted with the petition was insufficient to establish it was published. Resp.,
`
`33-39. But the Board has found that the petition and the supporting evidence
`
`
`
`
`17
`
`
`
`IPR2016-01585
`
`
`
`Petitioner’s Reply (Paper No. 19)
`
`submitted are sufficient to establish publication. Dec., 9-12; see, e.g., IPR2015-
`
`00810, Paper 44, 23-26 (Aug. 30, 2016). Patent Owner contends “there is no
`
`assurance that the procedures of RFC 2026… were actually applied to RFC 2401,”
`
`but provides no evidence to support that argument. Resp., 38; see Ex. 1075,
`
`112:25-113:15, 118:4-119:15, 120:5-121:11 (Dr. Monrose declining to
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
