`
`
`
`Paper No. 33
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________________
`
`
`APPLE INC.,
`Petitioner
`
`v.
`
`VIRNETX, INC. AND SCIENCE APPLICATION INTERNATIONAL
`CORPORATION,
`Patent Owner
`___________________
`
`Case IPR2014-00237
`Patent 8,504,697
`____________________
`
`Before MICHAEL P. TIERNEY, KARL D. EASTHOM, and STEPHEN C. SIU,
`Administrative Patent Judges.
`
`
`__________________________________________________________________
`
`Petitioner’s Reply
`
`
`
`
`
`
`
`
`IPR2014-00237
`
`Table of Contents
`
`I. Mr. Fratto’s Testimony is Competent and Unbiased ................................ 1
`
`II. Claim Construction ...................................................................................... 3
`
`A.
`
`B.
`
`C.
`
`D.
`
`Broadest Reasonable Interpretation ................................................. 3
`
`“Secure Communication Link”.......................................................... 4
`
`“Intercept[ing] . . . A Request to Look up an [IP] Address” ........... 4
`
`The “Determining” Step ..................................................................... 5
`
`III. Anticipation by Beser ................................................................................... 6
`
`A.
`
`B.
`
`C.
`
`D.
`
`E.
`
`Beser Discloses the Claimed “Intercepting” Features ..................... 6
`
`Beser Discloses the Claimed “Determining” Features..................... 9
`
`Beser Discloses the Claimed “Secure Communication Link” ....... 12
`
`Beser Discloses Encryption of Video or Audio Data (Claim 2) .... 13
`
`Beser Discloses a VPN Communication Link (Claim 3) ................ 14
`
`IV. Obviousness over Beser in view of RFC 2401 .......................................... 14
`
`
`ii
`
`
`
`IPR2014-00238
`
`
`The Board correctly found that Beser anticipates and renders obvious claims
`
`1-11, 14-25, and 28-30 of the ’697 patent. Paper 15 (“Dec.”) at 33. In its
`
`Response (“Resp.”) (Paper 30), Patent Owner tries to divert attention from the
`
`largely undisputed evidence of record establishing this, choosing instead to accuse
`
`Mr. Fratto of bias and disputing his credentials. It then asks the Board to read new
`
`limitations into its claims. When it finally addresses the grounds, Patent Owner
`
`advances strained readings of the prior art its own expert largely abandoned at his
`
`deposition. The Board’s determination that the challenged claims are unpatentable
`
`thus is supported by more than substantial evidence and should be maintained.
`
`I. Mr. Fratto’s Testimony is Competent and Unbiased
`
`Patent Owner devotes more than 8 pages of its Response to an attack on Mr.
`
`Fratto’s supposed lack of expertise and bias. Far more telling is Patent Owner’s
`
`conduct – Patent Owner did not ask Mr. Fratto a single substantive question
`
`about his declaration testimony at his deposition. Patent Owner’s decision to not
`
`test any of Mr. Fratto’s technical opinions shows those opinions are accurate and
`
`well-founded. Moreover, Patent Owner did not identify a single inaccuracy in
`
`Mr.Fratto’s testimony linked to this supposed “bias” and lack of expertise.
`
`Patent Owner’s challenge to Mr. Fratto’s credentials is baseless. Mr. Fratto
`
`has over 15 years of experience in studying, evaluating, testing, and describing
`
`networking, networking security and related technologies. Ex. 1003 ¶ 9. In the
`
`1
`
`
`
`IPR2014-00237
`
`early 1990s he was writing computer programs as part of an IT consulting business
`
`that provided remote office automation. Ex. 1081 (Fratto Dep. Tr.) at 13:4-14:7.
`
`He can write computer programs in several languages including “C, Pascal, Turbo
`
`Pascal, PERL, PHP, JAVA, Javascript, [and] a little bit of Python,” all of which
`
`were self-taught. Ex. 1081 at 13:11-14:19. These subject areas are directly
`
`relevant to understanding the state of the art as it relates to the ’697 patent, and
`
`more than qualify Mr. Fratto as an expert in these proceedings.
`
`Patent Owner claims Mr. Fratto is nonetheless unqualified as he “does not
`
`have a master’s degree” – it argues that knowledge cannot be gained through work
`
`experience to qualify a witness as an expert. Resp. at 1-5. Patent Owner’s expert
`
`disagrees – Dr. Monrose testified that someone with substantial work experience in
`
`the “things that are really relevant to understanding [] the state of the art” could
`
`acquire the same level of expertise as someone with a master’s degree. Ex. 1083
`
`(Monrose Dep. Tr.) at 48:8-49:9; see id. at 36:1-17, 37:6-11, 48:8-49:9. Patent
`
`Owner’s theory also ignores Fed. R. Evid. 702 (i.e., a witness may qualify “as an
`
`expert by knowledge, skill, experience, training, or education.” (emphasis added)).
`
`Patent Owner’s claim of “bias” rests on a handful of tweets by Mr. Fratto
`
`reflecting his belief that several of Patent Owner’s patents are invalid. Resp. at 5-
`
`8. This is hardly an indicia of bias –institution of this trial and other proceedings
`
`before the Office substantiates the merits of that belief. The tweets at issue do not
`
`
`
`2
`
`
`
`IPR2014-00237
`
`even mention VirnetX. At worst, those tweets are consistent with Mr. Fratto’s
`
`declarations and little more than candid reflections of the fact that the patents at
`
`issue in this and related proceedings are invalid. It is also irrelevant that Mr. Fratto
`
`has never found a patent valid – under this metric, Dr. Monrose is also fatally
`
`biased because he has never found a patent invalid. See Ex. 1083 at 8:7-9. Both
`
`critiques are meaningless – each has only served as an expert in proceedings
`
`involving Patent Owner. Id.; Ex. 1081 at 46:18-22. Patent Owner’s manufactured
`
`“bias” theory is simply an effort to distract the Panel from the merits and can be
`
`ignored – once again, Patent Owner identifies no error in Mr. Fratto’s testimony
`
`linked to this supposed bias. Resp. at 6-8.
`
`II. Claim Construction
`
`A. Broadest Reasonable Interpretation
`
`Patent Owner argues the broadest reasonable interpretation should “not
`
`apply” because its ability to amend the claims is “restricted.” Resp. at 9-10. But
`
`Patent Owner made no attempt to amend its claims in this proceeding, and its
`
`hypothetical concerns over amending the claims is unmerited – the Board has
`
`provided ample guidance on motions to amend. See, e.g., Toyota Motor Corp. v.
`
`American Vehicular Sciences, LLC, IPR2013-00419, Paper 32 at 2-5. Patent
`
`Owner’s real problem is its disclosure, which does not describe an invention
`
`having the intricate set of requirements it seeks to now read into its claims. Patent
`
`
`
`3
`
`
`
`IPR2014-00237
`
`Owner also has not moved to waive Rule 42.100(b), much less identified a
`
`legitimate justification for doing so – there is no basis for not following that rule.
`
`B.
`
`“Secure Communication Link”
`
`Patent Owner contends a secure communication link requires encryption.
`
`But Patent Owner’s expert Dr. Monrose admits that techniques such as “[a]ddress
`
`hopping may hide who is talking to whom,” and “provides some amount of
`
`security.” Ex. 1083 at 113:16-114:12, 74:12-14; see Prelim. Resp., Paper 12, at 21
`
`(in some circumstances, “hiding the address information is important while hiding
`
`the video data and/or audio data itself is not”). Dr. Monrose also acknowledges the
`
`’697 patent has “opposing views” on what secure communications means. Ex.
`
`1083 at 66:11-17. Moreover, reading “secure” to require encryption renders
`
`dependent claim 2 entirely superfluous, contrary to the doctrine of claim
`
`differentiation. Pet. at 34; Ex. 1083 at 110:8-21; Sunrace Roots Enterprise Co. v.
`
`SRAM Corp., 336 F.3d 1298, 1302-03 (Fed. Cir. 2003). Finally, the Board
`
`properly rejected Patent Owner’s request to read limitations into its claims due to
`
`an opaque “disclaimer” in pending Office proceedings. Dec. at 8; Resp. at 15-18.
`
`C.
`
`“Intercept[ing] . . . A Request to Look up an [IP] Address”
`
`The Board correctly found “intercepting” means “receiving a request
`
`pertaining to a first entity at another entity,” (Dec. at 13), which is consistent with
`
`its ordinary meaning and the ’697 disclosure (e.g., showing a request specifying
`
`
`
`4
`
`
`
`IPR2014-00237
`
`one computer being received by a different “proxy” computer), (Ex. 1001 at 40:31-
`
`33). Despite admitting that redefining “intercepting” would have no impact in
`
`proceeding, Patent Owner asks the Board to read into this term the additional step
`
`of “performing an evaluation on [the request] related to establishing a secure
`
`communication link.” Resp. at 26; see Dec. at 12. Patent Owner’s illogical
`
`construction must be rejected – it would create hopeless confusion in the claims,
`
`given that the proposed “evaluation” is actually part of the next step of the claims
`
`(i.e., the “determining” step). See Ex. 1083 at 140:5-9 (one example of an
`
`“evaluation” is “to determine whether the access to a secure site has been
`
`requested”); id. at 135:7-19 (“determin[ing] whether access to a secure site has
`
`been requested” part of “determining” step), 68:6-20, 70:1-19; see Resp. at 29.
`
`D. The “Determining” Step
`
`Patent Owner argues the “determining” step should be read as not covering a
`
`determination based on an indication of the relative permission level or security
`
`privileges of the requestor. It contends the ’697 patent distinguishes between
`
`“focusing on the second network device” (“determin[ing] whether access to a
`
`secure site has been requested,” Ex. 1001 at 40:32-33), and “focusing on the first
`
`network device” (“determin[ing] whether the user has sufficient security privileges
`
`to access the site,” (id. at 40:36-37). Resp. at 29. The language of the claims
`
`makes no such distinction. And Patent Owner ignores that the ’697 patent itself
`
`
`
`5
`
`
`
`IPR2014-00237
`
`explains that security privileges correspond to “different levels of security []
`
`provided for different categories of hosts” (Ex. 1001 at 41:20-21) and states “some
`
`sites may be designated as having a certain security level, and the security level of
`
`the user requesting access must match that security level.” Id. at 41:22-24. Thus,
`
`the ’697 patent shows its “determining” step covering determining the relative
`
`permission levels or security privileges of the requestor.
`
`III. Anticipation by Beser
`
`The Board correctly found claims 1-11, 14-25, and 28-30 of the ’697 patent
`
`anticipated by Beser. In response, Patent Owner argues that Beser does not show
`
`(i) the claimed “intercepting” features, (ii) the claimed “determining” features, or
`
`(iii) the claimed “secure communication link.” Each argument relies on limitations
`
`not found in the claims, and conflicts with evidence in the record.
`
`A. Beser Discloses the Claimed “Intercepting” Features
`
`Patent Owner does not challenge the Board’s finding that Beser shows the
`
`first network device intercepts the request, determines if it contains a distinctive
`
`sequence of bits, and if so, routes the request to the trusted-third-party network
`
`device instead of processing it normally. Dec. at 20-21; Ex. 1003 at ¶¶ 297-98 (Ex.
`
`1009 at 8:33-43); see Ex. 1009 at 8:21-50. Instead, Patent Owner contends that
`
`Beser does not disclose the “request to lookup an [IP] address,” arguing (1) the
`
`trusted-third-party network device does more than just look up an IP address,
`
`
`
`6
`
`
`
`IPR2014-00237
`
`(Resp. at 36-37), and (2) even if it looks up an IP address, it looks up the wrong IP
`
`address, (Resp. at 37-39). It also argues that (3) the trusted-third-party network
`
`device cannot “intercept[]” a request. Resp. at 38-39. Each argument lacks merit.
`
`First, Beser’s “tunneling” request is a “request to look up an [IP] address.”
`
`The originating device sends out a request containing a unique identifier (e.g., a
`
`domain name) of a terminating device, and it obtains an IP address that it uses to
`
`communicate with the terminating device. See Pet. at 19; Ex. 1003 at ¶¶ 296, 305-
`
`06; Ex. 1009 at Fig. 5, 8:1-9, 9:64-10:41. The trusted-third-party network device
`
`uses the unique identifier to look up an IP address of the terminating device – “a
`
`public IP address for a second network device 16 is associated with the unique
`
`identifier for the terminating telephony device.” Ex. 1009 at 11:26-28, 11:48-52,
`
`Fig. 5 (step 116); Ex. 1003 at ¶¶ 304-06; Ex. 1083 at 166:11-167:12, 173:6-13,
`
`174:3-16, 177:20-178:1 (“Beser [teaches that] there is a resolution . . . that could
`
`happen on the trusted third party to get a public address of device 16.”), 189:2-5.
`
`After looking up the IP address, the trusted-third-party network device negotiates
`
`with the first and second network devices to obtain a private IP address for the
`
`terminating device, which it returns to the originating device. Ex. 1003 at ¶¶ 309-
`
`10; Ex. 1009 at 11:9-24, 33-37, 45-62; 12:5-19; 21:48-55. The distinction Patent
`
`Owner and its expert attempt to draw – why the request to look up an IP address is
`
`sent – does not change the actions being performed in Beser. Ex. 1083 at 197:10-
`
`
`
`7
`
`
`
`IPR2014-00237
`
`19. The trusted-third-party network device looks up an IP in response to the
`
`tunneling connection; that the device also performs additional actions to establish a
`
`tunnel is irrelevant. Id. at 172:1-11, 195:17-197: 19; see In re Schreiber, 128 F.3d
`
`1473, 1478 (Fed. Cir. 1997). Simply put, Beser shows a “tunneling” request that is
`
`used to “look[] up an [IP] address.”
`
`Second, Patent Owner asserts the “trusted-third-party network device 30
`
`does not perform any translation into an IP address of the domain name of the
`
`terminating device 26.” Resp. at 37-38. Patent Owner is simply wrong. Beser
`
`shows that the originating device must communicate through the first and second
`
`network devices in order to reach the terminating device. See Ex. 1009 at Fig. 1,
`
`22:4-8; Ex. 1003 at ¶¶ 260-63, 283. Beser repeatedly shows that the IP address of
`
`second network device 16 is the address associated with the domain name of
`
`terminating device 26. Ex. 1009 at 11:48-58; see id. at 22:2-22, 11: 26-32, 15:50-
`
`54; Ex. 1003 at ¶¶ 263, 267, 315. As Dr. Monrose agrees, the claimed “[IP]
`
`address” covers a public IP address associated with the claimed second device.
`
`Ex. 1083 at 169:22-172:13, 227:22-228:12. The trusted-third-party network device
`
`also negotiates a private IP address for the terminating device, which is returned to
`
`the originating device. E.g., Ex. 1003 at ¶¶ 309-10; Ex. 1009 at 11:9-24; Ex. 1083
`
`at 191:15-192:16, 232:12-234:9. Thus, the trusted-third-party network device
`
`looks up two IP addresses (the public IP address of device 16 and the private IP
`
`
`
`8
`
`
`
`IPR2014-00237
`
`address of device 26), which are both necessary to enable communications
`
`between the originating and terminating end devices. See, e.g., Ex. 1009 at 22:12-
`
`22. Beser thus discloses that the trusted-third-party network device “look[s] up an
`
`[IP] address of the second network device.”
`
`Third, the Board also correctly found in the alternative that trusted-third-
`
`party network device 30 “intercept[s] a request” as required by the claims. Dec. at
`
`21. Patent Owner contends that Beser’s system does not intercept requests but
`
`instead is one that “has requests intercepted from it.” Resp. at 38. But Patent
`
`Owner overlooks that the trusted-third-party network device checks for the
`
`indicator bits on incoming requests (the same bits checked by the first network
`
`device), and if present, will give the request special processing. Ex. 1009 at 8:59-
`
`9:1. If the bits are not present, the request will be processed normally. Ex. 1003 at
`
`¶¶ 302-06, 357. Thus, Beser discloses the claimed “intercepting” step.
`
`B.
`
`Beser Discloses the Claimed “Determining” Features
`
`The Board correctly found Beser discloses the “determining” step. Initially,
`
`Patent Owner contends the Board’ “exceeded its statutory authority” by adopting a
`
`rationale different than that set forth in the petition as to Beser teaches the
`
`“determining” step. Resp. at 39-41. The Board plainly acted within its authority,
`
`and each of two rationales employed by the Board to find that Beser shows the
`
`claimed “determining” step was actually set forth in the Petition. See Dec. 21-23.
`
`
`
`9
`
`
`
`IPR2014-00237
`
`
`First, the Board correctly found the trusted-third-party network device is a
`
`modified DNS (Dec. at 22), that it determines whether the terminating device is
`
`available by checking to see if it has “a stored public address” for the device (id.),
`
`and that it initiates an IP tunnel and returns a private IP address “only if the
`
`terminating device has a public address” listed in its tunneling application database
`
`(id. at 23). The Board explained that “without a currently valid domain name, the
`
`DNS [i.e., the trusted-third-party network device] will not return a public or private
`
`address.” Dec. at 23. This same explanation was provided in the Petition: the
`
`trusted-third-party network device is able negotiate a tunnel with registered
`
`terminating devices “because the trusted-third-party network device stores domain
`
`names and associated IP addresses, and may also contain a database of users or end
`
`devices.” Pet. at 20; Ex. 1003 at ¶¶ 262-64; Ex. 1009 at 4:9-11, 4:44-5:2, 11:45-
`
`58; see Ex. 1083 at 159:13-160:8, 183:16-184:15. If the domain name “sent to the
`
`trusted-third-party network device specifies a destination that is unavailable or
`
`unknown to the trusted-third-party network device . . ., the request will not be
`
`routed further.” Pet. at 20; id. at 20-21 (if the domain name “does not map to a
`
`device requiring negotiation of an IP tunnel” a private IP address is not returned).
`
`Patent Owner challenges these findings, focusing on the Board’s statement
`
`that the determining step “includes determining that the device has a private
`
`Internet address assigned to it,” (see Dec. at 23), and arguing that Beser’s system
`
`
`
`10
`
`
`
`IPR2014-00237
`
`does not “determine[] [whether] device 25 [sic] or device 26 has a private internet
`
`address assigned to it.” Resp. at 43-48. But Patent Owner’s myopic argument
`
`ignores that the Board clearly explained that the trusted-third-party network device
`
`returns a private IP address “only if the terminating device has a public address”
`
`listed in its tunneling application database. Dec. at 23.
`
`Patent Owner also argues that Beser does not disclose a “determination”
`
`because it “does not necessarily” return a public IP address if the tunneling request
`
`specifies a non-secure domain name, and it instead could, e.g., “return[] an error
`
`message” or “discard[] the request.” Resp. at 41-43. Initially, Patent Owner
`
`ignores that a standard DNS lookup returns an associated IP address of a domain
`
`name. Ex. 1003 at ¶¶ 77-81, 109-12, 287-89. But more importantly, Patent
`
`Owner’s argument actually supports the Board’s finding – the counterexamples
`
`show that no tunnel is created if the domain name is not listed in the trusted-third-
`
`party network device’s table. Dec. 21-23; Ex. 1003 at ¶ 367. Thus, the
`
`determination affects whether the secure communication link is established.
`
`Second, the Board correctly found Beser discloses the “determining” step
`
`because Beser show determining whether “the originating device, device 24, has
`
`authorization to communicate [using the secure tunneling service].” Dec. at 23.
`
`As Mr. Fratto explained “the request containing the unique identifier ‘may require
`
`encryption or authentication to ensure [it] cannot be read on the public network.’”
`
`
`
`11
`
`
`
`IPR2014-00237
`
`Ex. 1003 at ¶ 303 (quoting Ex. 1009 at 11:22-25); accord Ex. 1003 at ¶¶ 316-18;
`
`see Dec. at 21, 24; Pet. at 20-22. Thus, if the originating device is not authorized
`
`to initiate a tunnel with the terminating device, it will not be able to initiate a
`
`tunnel. Ex. 1003 at ¶¶ 303 (“clients [must be] authenticated before [the trusted-
`
`third-party network device] will process a request”), 316-18. In response, Patent
`
`Owner argues that the only data transmitted to the trusted-third-party network
`
`device are the unique identifier and the distinctive bit sequence, and it believes
`
`those data do not show “authorization.” Resp. at 48-49. Patent Owner’s argument
`
`is irrelevant because it overlooks that the originating device also sends
`
`authentication information, and as Patent Owner admits, the trusted-third-party
`
`network device will only initiate a tunnel if the originating device has been
`
`authenticated. Resp. at 49 (citing Ex. 1009 at 11:22-25).
`
`C. Beser Discloses the Claimed “Secure Communication Link”
`
`Patent Owner argues that Beser does not show a “secure communication
`
`link” because “Beser never discloses that the packets being sent using the allocated
`
`private network addresses use ‘authentication,’ ‘encryption,’ or ‘address
`
`hopping.’” Resp. at 49, 50-52. Here, Patent Owner simply reads “including, but
`
`not limited to” out of the Board’s construction. See Dec. at 10; § II.B; Ex. 1083 at
`
`68:6-20, 70:1-19. In reality, Beser shows “obfuscation methods” that “restrict
`
`access to data, addresses, or other information on the path” which are “secure
`
`
`
`12
`
`
`
`IPR2014-00237
`
`communication links.” See Dec. at 10. For example, Beser’s tunnel restricts
`
`access to the identities of the communicating devices: “the identities of the
`
`originating 24 and terminating 26 telephony devices are inside the payload fields
`
`85 of the IP 58 packets and may be hidden from hackers on the public network
`
`12.” Ex. 1009 at 12:6-19 (emphasis added); Ex. 1003 at ¶ 312. Protecting the
`
`identities of communicating devices restricts access to “data, addresses, or other
`
`information on the path.” Ex. 1083 at 113:16-114:12; compare Resp. at 49 (Beser
`
`discloses using encryption “to ensure that the unique identifier cannot be read”)
`
`with Prelim. Resp., Paper 12, at 21 (in some circumstances, “hiding the address
`
`information is important while hiding the [] data itself is not.”).
`
`D. Beser Discloses Encryption of Video or Audio Data (Claim 2)
`
`Patent Owner advances two reasons why it believes Beser does not disclose
`
`that “at least one of the video data and the audio data is encrypted”: (i) that Beser
`
`does not incorporate IPSec by reference, and (i) it “teach[es] away” from using
`
`encryption. Resp. at 52-54. Both arguments miss the mark. First, Beser explicitly
`
`discloses that IPSec is one conventional way to “encrypt the information inside the
`
`IP packets before transmission.” Ex. 1009 at 1:54-56. A person of skill would
`
`read this as indicating the contents of IPSec are being incorporated by reference.
`
`Ex. 1003 at ¶¶ 320-22; Ex. 2025 at ¶ 16. Second, Beser’s indication that IPSec
`
`may have limitations in certain streaming video applications “does not vitiate the
`
`
`
`13
`
`
`
`IPR2014-00237
`
`fact that [using IPSec] is disclosed.” See Celeritas Technologies Ltd. v. Rockwell
`
`International Corp., 150 F.3d 1354, 1361 (Fed. Cir. 1998) (emphasis added); In re
`
`Heck, 699 F.2d 1331, 1332-33 (Fed. Cir. 1983) (patents are prior art “for all they
`
`contain”). Beser actually states that “the sender may encrypt the information
`
`inside the IP packets before transmission, e.g. with IP Security (‘IPSec’),” (Ex.
`
`1009 at 1:54-56), and that its invention aims to avoid “preventing certain types of
`
`encryption from being used,” (id. at 2:22-24; Ex. 1003 at ¶¶ 318-25). A person of
`
`skill thus would have read Beser as indicating video or audio data optionally can
`
`be encrypted when sent through a tunnel. Ex. 1003 at ¶ 319; Ex. 1083 at 213:19-
`
`214:1 (admitting use of IPSec was “conventional”), 218:1-220:2 (configure IPsec).
`
`E.
`
`Beser Discloses a VPN Communication Link (Claim 3)
`
`Patent Owner argues Beser does not explicitly call its secure tunnels a
`
`“VPN.” This is irrelevant – what matters is whether Beser’s tunnel meets the
`
`Board’s definition of a “[VPN] communication link.” Dec. at 11. It does –
`
`Beser’s secure tunnel traverses a portion of a public network. Ex. 1009 at 4:19-24.
`
`Moreover, Beser says a VPN is “a tunneling connection between edge routers on
`
`[a] public network,” and describes a tunneling connection between “edge router[s]”
`
`over a “public network.” Id.; Ex. 1003 at ¶¶ 255, 260, 328.
`
`IV. Obviousness over Beser in view of RFC 2401
`
`The Board correctly found that Beser in view of RFC 2401 renders obvious
`
`
`
`14
`
`
`
`IPR2014-00237
`
`claims 1-11, 14-25, 28-30. Dec. at 29. In response, Patent Owner argues Beser
`
`“teaches one of ordinary skill in the art away from” using RFC 2401’s IPSec to
`
`encrypt the contents of the tunnel. Resp. at 56-58. Beser does not “teach away”
`
`from using IPSec – it does not say it cannot be used. There is no requirement that
`
`“prior art must teach that a particular combination is preferred, or ‘optimal,’ for the
`
`combination to be obvious.” In re Fulton, 391 F.3d 1195, 1201-02 (Fed. Cir.
`
`2004); In re Gurley, 27 F.3d 551, 554 (Fed. Cir. 1994). Moreover, while Beser
`
`identifies situations where encryption “may” (i.e., “streaming” multimedia or high
`
`volume applications) cause challenges, the ’697 claims are not limited to such
`
`applications, and would cover transfer of video file via other means. See Dec. at
`
`31; Ex. 1009 at 1:58-65. Several passages of Beser also contradict Patent Owner’s
`
`assertion, and indicate encryption should be used. Ex. 1009 at 2:22-24; Ex. 1003
`
`at ¶ 321. And the implementation challenges that Beser identifies in using
`
`encryption can easily be navigated as both experts agreed. Ex. 1003 at ¶¶ 318-25;
`
`Ex. 1083 at 206:20-208:6 (admitting a more powerful computer or lower recording
`
`fidelity would resolve any problems), 211:16-212:2. The Board should maintain
`
`its finding that Beser anticipates or, in view of RFC 2401, renders obvious claims
`
`1-11, 14-25, and 28-30, as that finding is supported by substantial evidence.
`
`
`
`15
`
`
`
`IPR2014-00238
`
`
`
`Dated: November 21, 2014
`
`
`
`
`
`
`
`Respectfully Submitted,
`
`/ Jeffrey P. Kushan/
`Jeffrey P. Kushan
`Registration No. 43,401
`Sidley Austin LLP
`1501 K Street NW
`Washington, DC 20005
`jkushan@sidley.com
`(202) 736-8914
`Attorney for Petitioner Apple
`
`
`
`
`
`
`
`
`
`Certificate of Service
`
`I hereby certify that on this 21st day of November, 2014, a copy of this
`
`Petitioner’s Reply has been served in its entirety by email on the following counsel
`
`of record for Patent Owner:
`
`Joseph E. Palys
`Paul Hastings LLP
`875 15th Street NW
`Washington, DC 20005
`Telephone: (202) 551-1996
`E-mail: josephpalys@paulhastings.com
`
`Naveen Modi
`Paul Hastings LLP
`875 15th Street NW
`Washington, DC 20005
`Telephone: (202) 551-1990
`E-mail: naveenmodi@paulhastings.com
`
`
`
`
`Dated:
`
`November 21, 2014
`
`Respectfully submitted,
`
`/Jeffrey P. Kushan/
`Jeffrey P. Kushan
`Attorney for Petitioner Apple
`
`
`
`
`
`
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
