Paper No. 23
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`––––––––––––––––––
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`––––––––––––––––––
`
`APPLE INC.,
`Petitioner,
`
`v.
`VIRNETX INC.,
`Patent Owner.
`
`––––––––––––––––––
`
`Case No. IPR2015-01010
`U.S. Patent No. 8,843,643
`
`––––––––––––––––––
`
`PETITIONER’S REPLY
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`––––––––––––––––––
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`––––––––––––––––––
`
`APPLE INC.,
`Petitioner,
`
`v.
`VIRNETX INC.,
`Patent Owner.
`
`––––––––––––––––––
`
`Case No. IPR2015-01010
`U.S. Patent No. 8,843,643
`
`––––––––––––––––––
`
`PETITIONER’S REPLY
`
`
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`Table of Contents
`
`I.
`
`II.
`
`Introduction ...................................................................................................... 1
`
`Claim Construction .......................................................................................... 1
`
`III. Yeager and IE5 Resource Kit Render Claims 1-8, 12-23, and 27-32 Obvious1
`
`A.
`
`Independent Claims 1 and 17 ................................................................ 2
`
`1.
`
`2.
`
`3.
`
`“Enabling… a Secure Communication Mode Without a User
`Entering Any Cryptographic Information” ................................. 3
`
`“Establishing… an Encrypted Communication Link” ............... 6
`
`“Initiating Establishment of the Encrypted Communication
`Link” ........................................................................................... 8
`
`B.
`
`Dependent Claims ............................................................................... 10
`
`1.
`
`2.
`
`3.
`
`4.
`
`Claims 7 and 22 ......................................................................... 10
`
`Claims 12 and 27....................................................................... 13
`
`Claims 14 and 29....................................................................... 15
`
`Claims 2-6, 8, 13, 15-16, 18-21, 23, 28, and 30-32 .................. 16
`
`IV. Yeager, IE5 Resource Kit, and RFC 1034 Render Claims 9 and 24 Obvious16
`
`V.
`
`RFC 1034 Is Prior Art ................................................................................... 17
`
`VI. Dr. Tamassia’s Testimony Is Probative ......................................................... 19
`
`VII. Dr. Monrose’s Testimony Is Entitled to No Weight Because He Admitted
`He Has No Opinion About What the References Teach or What the
`Challenged Claims Cover .............................................................................. 20
`
`VIII. Conclusion ..................................................................................................... 25
`
`
`
`
`
`i
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`Belden Inc. v. Berk-Tek LLC,
`805 F.3d 1064 (Fed. Cir. 2015) .......................................................................... 20
`
`Cisco Systems, Inc. v. VirnetX Inc.,
`Appeal 2015-007843 (Feb. 11, 2016) ................................................................... 8
`
`Denso Corp. and Clarion Co. v. Beacon Navigation,
`IPR2013-00026, Paper 34 (Mar. 14, 2014) .......................................................... 4
`
`In re Etter,
`756 F.2d 852 (Fed. Cir. 1985) (en banc) .............................................................. 6
`
`Grober v. Mako Prods., Inc.,
`686 F.3d 1335 (Fed. Cir. 2012) .................................................................... 15, 16
`
`In re Keller,
`642 F.2d 413 (CCPA 1981) .................................................................................. 6
`
`KSR Intern. Co. v. Teleflex Inc.,
`550 U.S. 398 (2007) ............................................................................................ 16
`
`PGMedia, Inc. v. Network Solutions, Inc.,
`51 F. Supp. 2d 389 (S.D.N.Y. 1999) .................................................................. 17
`
`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
`
`Tempo Lighting Inc. v. Tivoli, LLC,
`742 F.3d 973 (Fed. Cir. 2014) ...................................................................... 10, 13
`
`Titanium Metals Corp. of America v. Banner,
`778 F.2d 775 (Fed. Cir. 1985) ............................................................................ 20
`
`
`
`
`
`ii
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`Exhibit List
`
`1006
`1007
`1008
`1009
`
`1010
`
`1011
`
`Exhibit # Reference Name
`1001
`U.S. Patent 8,843,643
`1002
`U.S. Patent 8,843,643 File History
`1003
`Declaration of Roberto Tomassia
`1004
`Curriculum Vitae of Roberto Tomassia
`1005
`Microsoft Corp., Microsoft Windows 2000 Professional Resource Kit
`(2000)
`Microsoft Internet Explorer 5 Resource Kit
`U.S. Patent 5,657,390
`Publication - Web Server Technology; Yeager & McGrath (1998)
`Microsoft Windows 2000 Professional Resource Kit – Copyright
`Registration Request
`USPN 6,839,750 (Control No. 95/001747) Request for Inter Partes
`Reexamination
`USPN 6,839,759 (Control No. 95/001747) Patent Owner’s Response
`to 10/14/2011 Office Action
`VirnetX v Cisco - Opening Claim Construction Brief (TXED 6-10-cv-
`417; Dkt 173)
`VirnetX v Cisco - Claim Construction Order (TXED 6-10-cv-00417;
`Dkt 266)
`Microsoft Windows 2000 Professional Resource Kit – About page
`U.S. Patent No. 6,502,135
`U.S. Patent No. 6,839,759
`Amazon Reviews “Microsoft Windows 2000 Professional Resource
`Kit”
`Barnes and Noble Customer Reviews of “Microsoft Windows 2000
`Professional Resource Kit”
`Microsoft Press Announces Complete Line of Learning and Reference
`Solutions for Microsoft Windows 2000 (Feb. 17, 2000),
`http://news.microsoft.com/2000/02/17/microsoft-press-announces-
`iii
`
`1012
`
`1013
`
`1014
`1015
`1016
`1017
`
`1018
`
`1019
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`1020
`1021
`1022
`1023
`1024
`1025
`1026
`1027
`
`1028
`1029
`1030
`1031
`
`1032
`
`Exhibit # Reference Name
`complete-line-of-learning-and-reference-solutions-for-microsoft-
`windows-2000/
`RFC 2026 – The Internet Standards Process – Revision 3
`U.S. Patent No. 5,991,810
`RFC 882 – Domain Names – Concepts and Facilities
`RFC 883 – Domain Names – Implementation and Specification
`RFC 1034 – Domain Names – Concepts and Facilities
`RFC 1035 – Domain Names – Implementation and Specification
`RFC 1912 – Common DNS Operational and Configuration Errors
`Linux Networking-HOWTO,
`http://www.tldp.org/HOWTO/html_single/NET3-4-HOWTO/ (Aug.
`1999)
`RFC 2219 – Use of DNS Aliases for Network Services
`RFC 2543 – SIP: Session Initiation Protocol
`U.S. Patent No. 6,061,738
`Ben Laurie & Peter Laurie, Apache: The Definitive Guide (2d ed.
`1999)
`Kerberos: An Authentication Service for Open Network Systems
`(Mar. 30, 1988)
`RFC 2409 – The Internet Key Exchange (IKE)
`RFC 2408 – Internet Security Association and Key Management
`Protocol (ISAKMP)
`RFC 2401 – Security Architecture for Internet Protocol
`U.S. Patent No. 5,960,204
`Original Specification, U.S. Utility Patent Application No. 09/558,210
`Microsoft Internet Explorer 5 Resource Kit - Copyright Registration
`Amazon reviews “Microsoft Windows 2000 Server Resource Kit”
`Secure Sockets Layer for SOCKS Version 5 (1997)
`Ari Luotonen & Tim Berners-Lee, CERN httpd Reference Manual
`
`1033
`1034
`
`1035
`1036
`1037
`1038
`1039
`1040
`1041
`
`iv
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`1042
`
`1043
`
`Exhibit # Reference Name
`(1994)
`Archive.org snapshot of Morgan Kaufmann Publishers website,
`www.mjp.com (April 29, 1997), https://web.archive.org/web/
`19970429195411/http://www.mkp.com/index.htm
`Search for “‘web server technology’ yeager”, Google Scholar,
`https://scholar.google.com/ (date limited: 1996-1999)
`U.S. Patent No. 6,012,126
`Declaration of Scott M. Border
`Deposition Transcript of Fabian Monrose (May 18, 2016)
`
`Deposition Transcript of Fabian Monrose in IPR2015-01046 &
`IPR2015-01047 (April 28, 2016)
`The Reality of Virtual Private Networks, InfoWorld, Aug. 16, 1999
`(Advertising Supplement)
`Gibbs, M., IP Security: Keeping Your Business Private, Network
`World (March 15, 1999)
`Huitema, C., RFC 1602, The Internet Standards Process – Revision 2,
`Mar. 1994
`Chapin, L., RFC 1310, The Internet Standards Process, Mar. 1992
`
`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
`Transcript of Feb. 8, 2013 deposition of Sandy Ginoza, ITC Inv. No.
`337-TA-858
`Mockapetris, P., RFC 1034, “Domain Names – Concepts and
`Facilities,” bearing Bates Nos. 337-TA-858-IETF00022 through
`00073
`
`v
`
`1044
`1045
`1046
`[NEW]
`1047
`[NEW]
`1048
`[NEW]
`1049
`[NEW]
`1050
`[NEW]
`1051
`[NEW]
`1052
`[NEW]
`
`1053
`[NEW]
`1054
`[NEW]
`
`
`
`
`
`IPR2015-01010
`
`I.
`
`Introduction
`
`
`
`Petitioner’s Reply
`
`In its Institution Decision, the Board correctly found that Yeager and IE5
`
`Resource Kit render claims 1-8, 12-23, and 27-32 obvious and that Yeager, IE5
`
`Resource Kit, and RFC 1034 render claims 9 and 24 obvious. Paper 9 (Dec.), 14.
`
`Because the Board’s initial determination that the challenged claims are
`
`unpatentable is fully supported by more than substantial evidence, the claims
`
`should be cancelled.
`
`II. Claim Construction
`
`The Board correctly found that no claims require construction. Dec., 5.
`
`Patent Owner proposes constructions for a number of terms, only a few of which
`
`are relevant to the parties’ dispute: “encrypted communication link,” (Resp., 4-6),
`
`“secure”/”non-secure domain name,” (Resp., 7-14), “secure domain name
`
`service,” (Resp., 15-22), and “virtual private network communication link,” (Resp.,
`
`22-31). For those terms, Patent Owner’s constructions are not supported by the
`
`specification and are simply an attempt to read features into the claims. As
`
`explained in the analysis below, Patent Owner’s constructions must be rejected.
`
`III. Yeager and IE5 Resource Kit Render Claims 1-8, 12-23, and 27-32
`Obvious
`
`The Board correctly found that Yeager and IE5 Resource Kit likely render
`
`claims 1-8, 12-23, and 27-32 obvious. In its Response, Patent Owner raises three
`
`primary challenges to the Board’s findings regarding the two independent claims:
`
`1
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`(i) that Yeager alone does not disclose the “enabling” step, (ii) that the references
`
`do not teach the “establishing” step is “based on a determination a secure
`
`communication mode has been enabled,” and (iii) that Yeager does not disclose
`
`“encrypted communication link resources received from a server that is separate
`
`than the first device.” Patent Owner also raises specific challenges to several
`
`dependent claims. Patent Owner’s arguments are wrong and must be rejected.
`
`A.
`
`Independent Claims 1 and 17
`
`The Board correctly found that Yeager and IE5 Resource Kit likely render
`
`claims 1 and 17 obvious. Dec., 6-8. As explained in the Petition, Yeager and IE5
`
`Resource Kit teach a method and system for “establishing an encrypted
`
`communication link” between a Web browser (“first device”) and a Web server
`
`(“second device”). Pet., 24, 29-30. A user “enables” a secure communication
`
`mode by typing an “https” URL into a Web browser, and the browser will
`
`“establish[]” an encrypted SSL connection with the Web server only if the browser
`
`determines it supports “https.” Pet., 24-25, 46-47.
`
`Petitioner also explained how Yeager and IE5 Resource Kit teach the four
`
`sub-elements of the “establishing” step of claims 1 and 17. First, IE5 Resource
`
`Kit teaches AutoCorrect and AutoComplete features that allow the Internet
`
`Explorer 5 Web browser to “construct[] a domain name” by fixing mistakes in a
`
`URL entered by a user or by automatically completing a URL that has been
`
`2
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`partially typed in by the user. Pet., 46-47; Ex. 1006, 19-20, 200-01. Second and
`
`third, Yeager teaches “sending a query” to a DNS server and “receiving” at least
`
`one network address in response. Pet., 27-28; Ex. 1008, 48; see also Ex. 1008, 12-
`
`13, 138. Fourth, Yeager teaches “initiating establishment of the encrypted
`
`communication link” because the Web browser initiates an SSL connection with
`
`the Web server using a digital certificate and encryption key received from the
`
`Web server. Pet., 28-29; Ex. 1008, 362-63; see also Ex. 1008, 345.
`
`Patent Owner make several narrow challenges to these findings by the
`
`Board, none of which have any merit.
`
`1.
`
`“Enabling… a Secure Communication Mode Without a User
`Entering Any Cryptographic Information”
`
`The Board correctly found that Yeager and IE5 Resource Kit likely teach
`
`this step, and explained the secure communication mode is enabled when a user
`
`types an “https” URL into a Web browser that supports SSL. Dec., 7; Pet., 24-25,
`
`46-47. In addition to this mapping of the claims, Petitioner explained that
`
`alternatively the enabling step could be performed by a user clicking on a
`
`hyperlink or a button that links to an SSL-enabled Web server. Pet., 24-25.
`
`Patent Owner asserts that Yeager and IE5 Resource Kit do not teach the
`
`“enabling” step because Yeager alone does not show an example where a user
`
`3
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`types an “https” URL into a browser. Resp., 35-36.1 Patent Owner’s challenge
`
`suffers from several flaws.
`
`First, Yeager discloses that URLs can be typed into a Web browser. Ex.
`
`1008, 37 (stating “the user might type the URL”). Petitioner supported that
`
`disclosure in Yeager with testimony from its Expert, Dr. Tamassia, who explained
`
`that a person of ordinary skill in the art reading Yeager would have understood that
`
`the “https” URL disclosed in Yeager could be typed into a Web browser. Ex.
`
`1003, ¶¶235, 240. When considering what a reference discloses, “it is proper to
`
`take into account not only specific teachings of the reference but also the
`
`inferences which one skilled in the art would reasonably be expected to draw
`
`therefrom.” Denso Corp. and Clarion Co. v. Beacon Navigation, IPR2013-00026,
`
`Paper 34 at 19-20 (Mar. 14, 2014) (emphasis added) (citing In re Preda, 401 F.2d
`
`825, 826, 159 USPQ 342, 344 (CCPA 1968)). Thus, Yeager teaches that a user
`
`can type an “https” URL into a Web browser.2
`
`
`
`1 Petitioner explained that each step is performed “without a user entering any
`
`cryptographic information.” Pet., 25. Patent Owner does not contest this.
`
`2 Patent Owner also asserts Petitioner has improperly relied on a portion of Yeager
`
`that discloses submitting a purchase order to a server using the “shttp” protocol
`
`when Petitioner’s obviousness theory is based on the “https” protocol. Resp., 34-
`
`4
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`Second, Patent Owner ignores the combined teachings of Yeager and IE5
`
`Resource Kit, which were the grounds upon which the Board instituted. Pet., 45-
`
`47. As Petitioner explained, Internet Explorer 5 supported SSL (i.e., “https”) and
`
`could be used to perform each step of the claims. Pet., 45. Petitioner also
`
`explained that IE5 Resource Kit teaches that a user can type a URL into a Web
`
`browser. Id.; Ex. 1006, 19-20, 200-01; see Ex. 1046, 97:16-19, 100:4-11 (Dr.
`
`Monrose agreeing). The Board correctly found the combined teachings of these
`
`two references conveys that a user can type an “https” URL into a Web browser.
`
`Dec., 7; Ex. 1006, 19-20; Ex. 1003, ¶206. And, of course, that is a common sense
`
`conclusion based on how web browsers function and are used.
`
`Finally, Patent Owner asserts that Petitioner cannot rely on Yeager’s
`
`disclosure of a user clicking on a hyperlink and selecting a button because those
`
`actions purportedly are incompatible with the AutoCorrect and AutoComplete
`
`features in IE5 Resource Kit. Resp., 32-24. But that argument ignores that Yeager
`
`and IE5 Resource Kit together teach that another way to navigate to a desired site
`
`
`
`35; Ex. 1008, 356. But Patent Owner misreads Yeager, which uses the purchase
`
`order as an example, and provides that it can be submitted using either “shttp” or
`
`“https”. Ex. 1008, 362. Petitioner relies on the SSL-enabled example. Pet., 19-20;
`
`Ex. 1003, ¶242.
`
`5
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`is by typing the URL into a Web browser, which satisfies this claim element.
`
`Patent Owner’s argument also employs an implausible reading of the two
`
`references—assuming a literal, bodily incorporation of IE5 Resource Kit into
`
`Yeager without any adaptation. That wooden reading of the prior art is legally
`
`incorrect. In re Etter, 756 F.2d 852, 859 (Fed. Cir. 1985) (en banc) (question of
`
`obviousness is not “whether the references could be physically combined but
`
`whether the claimed inventions are rendered obvious by the teachings of the prior
`
`art as a whole”); see In re Keller, 642 F.2d 413, 425 (CCPA 1981). For these
`
`reasons, the claimed “enabling” step is obvious.
`
`2.
`
`“Establishing… an Encrypted Communication Link”
`
`Claims 1 and 17 specify the step of “establishing, based on a determination
`
`that the secure communication mode has been enabled, the encrypted
`
`communication link,” and recites that this step comprises four sub-elements.
`
`Petitioner explained that Yeager teaches this step because if a user tries to navigate
`
`to a URL that uses “https” but the Web browser does not support “https,” then the
`
`Web browser will not follow the link. Pet., 25-26; Ex. 1008, 349. Thus, if the
`
`browser supports SSL, the “https” connection will be established, but otherwise, it
`
`will not. Pet., 25-26.
`
`Patent Owner asserts the references do not teach this step, arguing that the
`
`AutoComplete or AutoCorrect features would construct the domain name prior to
`
`6
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`determining whether SSL and “https” were supported. Resp., 36-37. Patent
`
`Owner’s arguments are wrong and must be rejected.
`
`First, IE5 Resource Kit shows that the Internet Explorer 5 web browser
`
`determines whether the secure communication mode has been enabled before
`
`constructing the domain name. For example, it shows the AutoCorrect feature can
`
`determine whether a URL prefix contains an error. Ex. 1006, 19; Pet., 46. If the
`
`user types in “htpp,” AutoCorrect can automatically fix the error by changing the
`
`prefix to “http.” Ex. 1006, 19; Ex. 1003, ¶266. As Dr. Tamassia explained, IE5
`
`would know whether SSL had been enabled, (Ex. 1003, ¶¶205, 208), and thus, if
`
`the user typed in “https” but the browser did not support SSL, AutoCorrect would
`
`change the prefix to “http.” See Ex. 1006, 19. If “https” was supported,
`
`AutoCorrect would not change it. Id. Dr. Monrose agreed. Ex. 1046, 103:1-18.
`
`Second, Patent Owner misreads its own claims, which require no such
`
`ordering. While the claims specify that the step of “establishing the encrypted
`
`communication link” is “based on a determination the secure communication mode
`
`has been enabled,” they do not specify that every sub-element of the “establishing”
`
`step must be based on that determination. As long as the encrypted
`
`communication channel is established “based on” the determination, the claim is
`
`satisfied. Patent Owner’s interpretation also conflicts with the Board’s previous
`
`decision involving a related patent and similar “enabling” and “establishing …
`
`7
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`based on the enabling” steps, where it determined that the “establishing” step was
`
`merely “based on the events that occur during” the “enabling” step. Cisco
`
`Systems, Inc. v. VirnetX Inc., Appeal 2015-007843, 12 (Feb. 11, 2016).
`
`Finally, Yeager discloses that if a Web browser does not support SSL, then
`
`the browser will not even attempt to initiate a connection with the Web server. Ex.
`
`1008, 349. Thus, the browser would not send a DNS query, receive an address, or
`
`initiate the encrypted communication link unless the browser determined that
`
`“https” were supported. Id. Accordingly, the claimed “establishing” step is
`
`obvious.
`
`3.
`
`“Initiating Establishment of the Encrypted Communication
`Link”
`
`Petitioner explained Yeager teaches that when a Web browser (“first
`
`device”) establishes an SSL connection with a Web server (“second device”), the
`
`browser receives an encryption key and digital certificate (each “encrypted
`
`communication link resources”) from the Web server (“a server that is separate
`
`from the first device”). Pet., 29.
`
`Patent Owner asserts Yeager does not teach this element because the Web
`
`server cannot be both the “second device” and the “server that is separate from the
`
`first device.” Patent Owner’s position is inconsistent with the claims, which
`
`provide that the server must only be “separate from the first device,” but do not
`
`require the server to be “separate from the second device.” If the claims implicitly
`8
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`required the “first device,” “second device,” and “server” to be located on distinct
`
`devices, there would be no need to explicitly require the server to be “separate
`
`from the first device.” Thus, the claim language contemplates that the “server”
`
`need not be separate from the “second device.”
`
`Petitioner’s reading of the claims is consistent with the ’643 specification,
`
`which shows that the various components of the system, including the gatekeeper
`
`computer alleged to correspond to the claimed “server,” can reside on separate
`
`devices or on the same device. Ex. 1001, 51:34-39, 40:30-42, 41:10-12. And, Dr.
`
`Monrose agreed that the specification provides the functionality of various
`
`components in the system could reside on separate device or be combined into a
`
`single device. Ex. 1046, 43:2-21. Likewise, Patent Owner argued in a proceeding
`
`involving the related ’135 patent that a “server” can include “a computer or
`
`program that responds to a request.” IPR2014-00171, Paper 41 at 44-45
`
`(emphasis added). Patent Owner explained that “the common usage in the field
`
`[is] that a ‘server’ may comprise hardware and/or software elements.” Id. at 45.
`
`Therefore, Yeager in view of IE5 Resource Kit would have taught a process
`
`having every step of independent claims 1 and 17 and would have rendered those
`
`claims obvious.
`
`9
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`B. Dependent Claims
`
`1.
`
`Claims 7 and 22
`
`The Petition established that Yeager discloses a local DNS server that acts as
`
`a “secure domain name service” as specified by claims 7 and 22. Pet., 38; Ex.
`
`1008, 138. Specifically, Petitioner explained a “secure domain name service” is a
`
`service that resolves secure domain names into “secure computer addresses,” (Pet.,
`
`13; Ex. 1001, 51:6-28), and that the address of a private Web server restricted to
`
`certain users on a private network would be a secure computer network address,
`
`(Pet., 35-38). Because the Web server is private, its domain name would not be
`
`registered with a public DNS, and thus, would not be resolvable by a conventional,
`
`public DNS server. Pet., 38-39; Ex. 1008, 13, 303, 318; Ex. 1003, ¶¶105-106.
`
`In response, Patent Owner first argues that Yeager does not disclose this
`
`element because an “SDNS” must resolve a “non-standard” domain name, and
`
`Yeager does not disclose such a name. Resp., 42. Patent Owner’s position is
`
`based on a disclaimer argument which is not applicable to the Board here. Tempo
`
`Lighting Inc. v. Tivoli, LLC, 742 F.3d 973, 978 (Fed. Cir. 2014). Moreover, its
`
`construction is not supported by the ’643 specification, as nothing requires an
`
`“SDNS” to resolve “non-standard” domain names. The specification simply
`
`provides that an SDNS has a table that correlates secure domain names and secure
`
`network addresses. Ex. 1001, 51:6-10. Patent Owner offers no reason to depart
`
`10
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`from the Board’s prior rejection of this requirement. See IPR2014-00403, Paper
`
`42, 8-20.
`
`Patent Owner also argues Yeager does not disclose local DNS servers on
`
`private networks, so it cannot disclose resolving “domain names that may not be
`
`processed by a conventional DNS.” Resp., 42-43. But, as Petitioner explained,
`
`Yeager discloses several examples of an organization maintaining a private
`
`network protected by a firewall, where the network includes both Web clients and
`
`Web servers. Pet., 35-38. Petitioner also explained that Yeager discloses a local
`
`DNS server that can resolve a domain name into an address of a Web server that is
`
`on a private network. Pet., 38. Yeager describes the local DNS server as follows:
`
`For every Web request, the browser contacts a local DNS server… If
`the local network name service is slow, each Web request will be
`slowed….
`
`The network name service is usually provided by the network service
`provider, so there may be little that an information provider can do
`about DNS problems. A medium-to-large organization may well wish
`to run its own local DNS service, though, to ensure adequate
`performance.
`
`Ex. 1008, 138.
`
`Dr. Tamassia explained a person of ordinary skill in the art would have
`
`understood that the “local DNS service” was a DNS server on a local or private
`
`network, i.e., an organization’s “own” local network. Pet., 38; Ex. 1003, ¶250. Dr.
`11
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`Tamassia also explained that a person of ordinary skill in the art would have
`
`understood that the private network configurations described in Yeager would
`
`include a “local DNS service.” Ex. 1003, ¶¶251-52. Thus, when a user attempted
`
`to navigate to a secure Web server on an intranet, the local DNS service acts as a
`
`“SDNS” by returning a secure address. Id., ¶¶251, 253-55.
`
`Patent Owner challenges this teaching by arguing that the “local DNS
`
`server” is the same as the “network name service,” and therefore, Yeager only
`
`describes DNS servers on public networks (i.e., those provided by a network
`
`service provider). Resp., 42-43. But Yeager clearly states that the “local DNS
`
`service” is an alternative to the public “network name service” provided by the
`
`network service provider that allows an organization to avoid the DNS problems
`
`associated with public DNS services. Ex. 1008, 138.
`
`To support its strained reading of Yeager, Patent Owner purports to rely on
`
`Dr. Monrose’s opinion, but Dr. Monrose simply repeats Patent Owner’s assertions
`
`without providing any additional analysis. Ex. 2015, ¶68. Dr. Monrose’s
`
`testimony on Yeager’s disclosure of a local DNS server also is entitled to no
`
`weight because during his deposition he refused to answer any questions about that
`
`passage of Yeager. In his declaration, Dr. Monrose discussed the “local DNS
`
`service” and “network name service” described in Yeager at 138. Ex. 2015, ¶68;
`
`Ex. 1046, 132:16-25. Yet Dr. Monrose repeatedly asserted that he had no opinions
`
`12
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`about the “local DNS service,” (Ex. 1046, 128:8-132:14, 134:9-136:23), and
`
`refused to answer any questions about that passage of Yeager, (id., 128:8-130:15
`
`(“I'm not going to sit here today and guess from just looking at two sentences”).
`
`Dr. Monrose also testified his analysis was limited to determining whether
`
`Petitioner’s assertions were correct, and that he had not formed any opinions about
`
`what Yeager may or may not disclose. Ex. 1046, 134:9-136:23. As explained in
`
`§ VII , below, Dr. Monrose’s testimony in this regard is improper and entitled to no
`
`weight. See LG Display Co., Ltd, v. Innovative Display Techs. LLC, IPR2014-
`
`01362, Paper 32 at 15-16 (Feb. 8, 2016). Thus, Petitioner established that claims 7
`
`and 22 are obvious.
`
`2.
`
`Claims 12 and 27
`
`Petitioner explained Yeager and IE5 Resource Kit teach “constructing a
`
`domain name” by replacing a non-secure domain name with a secure domain
`
`name. Pet., 39-41. Yeager discloses that a Web browser can run a script that
`
`changes URLs entered by a user to redirect the browser to a local cache server, and
`
`shows an example where a domain name in a URL is changed from “server.org” to
`
`“cache.local.org.” Pet., 40; Ex. 1008, 195-96. Petitioner explained that a person of
`
`ordinary skill in the art would have understood “cache.local.org” to refer to a
`
`domain name on a local, private network. Pet., 40; Ex. 1003, ¶264.
`
`13
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`Patent Owner argues that “cache.local.org” is not a secure domain name,
`
`relying on Dr. Monrose’s testimony. Resp., 44-45. But Dr. Monrose’s testimony
`
`is entitled to no weight, as he admitted he has no independent understanding of
`
`Yeager. Ex. 1046, 135:13-21; see §VII, below.
`
`Patent Owner also asserts that because this configuration of Yeager includes
`
`a proxy server, it does not disclose the “encrypted communication link” of claims 1
`
`and 17, which Patent Owner asserts requires “direct” communications. Resp., 45-
`
`46. Patent Owner’s “direct” requirement has no support in the claim language or
`
`the specification. First, nothing in the claim requires “direct” communication. See
`
`IPR2014-00482, Paper 34, 16-17 (finding no “direct” requirement in a related
`
`proceeding involving similar claim language). Next, Patent Owner argues that
`
`direct communications can traverse firewalls and routers as described in the ’643
`
`specification, but it fails to explain why a proxy server prevents “direct”
`
`communications. Resp., 5-6. The ’643 patent itself discloses examples of secure
`
`“communication links” traversing a proxy server and secure edge routers. Ex.
`
`1001, Fig. 33, 52:20-26 (“a user at computer 3301 can optionally select a secure
`
`communication link through proxy computer 3315”), 51:31-35 (describing
`
`provisioning a “secure edge router”).
`
`Finally, Dr. Monrose has admitted in related proceedings that the term
`
`“direct” has no set meaning and that it requires a “judgment” call to determine
`
`14
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`whether a communication link is “direct.” Ex. 1047, 261:20-262:9, 263:3-20.
`
`Such ambiguity cannot form the basis of a proper disclaimer, see Grober v. Mako
`
`Prods., Inc., 686 F.3d 1335, 1343 (Fed. Cir. 2012), and the Board should not read
`
`an ambiguous term into the claims. Thus, Petitioner established that Yeager and
`
`IE5 Resource Kit render claims 12 and 27 obvious.
`
`3.
`
`Claims 14 and 29
`
`Petitioner explained Yeager and IE5 Resource Kit teach “a virtual private
`
`network communication link” because the SSL connection provides encryption and
`
`the proxy server provides anonymity. Pet., 41-42. Patent Owner challenges these
`
`teachings by trying to read limitations into the claims, arguing a “[VPN]
`
`communication link” must be “direct.” But as explained above, see § III.B.2 , a
`
`“direct” requirement is not supported by the ’643 specification or the relevant
`
`prosecution history. For example, the ’643 patent discloses examples of a “VPN
`
`communication link” that traverse a proxy server. Ex. 1001, Fig. 33, 52:20-26,
`
`51:31-35. Therefore, use of a proxy server does not preclude use of a “VPN
`
`communication link.” The prosecution history also does not support reading a
`
`“direct” limitation into the claims because it shows that the meaning of the term
`
`“direct” is ambiguous, so there cannot be a clear and unequivocal disclaimer
`
`affecting claim scope. See, e.g., Ex. 1047, 261:20-262:9, 263:3-20 (in related
`
`proceeding, Dr. Monrose admitted he did not know what “direct” communications
`
`15
`
`
`
`IPR2015-01010
`
`
`
`Petitioner’s Reply
`
`requires and that determining whether it is disclosed is always a “judgment” call);
`
`Grober, 686 F.3d at 1343. Patent Owner’s contorted reading of the claims must be
`
`rejected. Thus, Petitioner established that Yeager and IE5 Resource Kit render
`
`claims 14 and 29 obvious.
`
`4.
`
`Claims 2-6, 8, 13, 15-16, 18-21, 23, 28, and 30-32
`
`Patent Owner does not separately challenge these claims so they fall with
`
`claims 1 and 17. See Resp., 47-48.
`
`IV. Yeager, IE5 Resource Kit, and RFC 1034 Render Claims 9 and 24
`Obvious
`
`Petitioner explained a person of ordinary skill in the art would have found it
`
`obvious to configure the DNS functionality described in Yeager to include
`
`returning a “list of network addresses associated with the domain name.” Pet., 50.
`
`Petitioner explained Yeager described a DNS server that maintained a list of IP
`
`addresses associated with a domain name, and that based on RFC 1034 (which
`
`discloses the DNS protocol), it would have been obvious that the DNS server could
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
