NO:
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`__________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________________
`
`THE MANGROVE PARTNERS MASTER FUND, LTD.
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`__________________
`
`Case IPR2015-_____
`Patent U.S. 7,490,151
`__________________
`
`PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO.
`7,490,151
`UNDER 35 U.S.C. § 312 AND 37 C.F.R. § 42.104
`
`Mail Stop Patent Board
`Patent Trial and Appeal Board
`US Patent and Trademark Office
`PO Box 1450
`Alexandria, Virginia 22313-1450
`
`

`
`TABLE OF CONTENTS
`I. MANDATORY NOTICES UNDER 37 C.F.R § 42.8(a)(1) .................... 1
`A. Real Party-In-Interest Under 37 C.F.R. § 42.8(b)(1) ........................... 1
`B. Related Matters Under 37 C.F.R. § 42.8(b)(2)..................................... 1
`C. Lead And Back-Up Counsel Under 37 C.F.R. § 42.8(b)(3) ................ 2
`D. Service Information .............................................................................. 3
`II. PAYMENT OF FEES – 37 C.F.R. § 42.103 ............................................ 3
`III.REQUIREMENTS FOR IPR UNDER 37 C.F.R. § 42.104 ..................... 3
`A. Grounds for Standing Under 37 C.F.R. § 42.104(a) ............................ 3
`B. Challenge Under 37 C.F.R. § 42.104(b) and Relief Requested ........... 3
`IV.SUMMARY OF THE ‘151 PATENT....................................................... 5
`A. Brief Description .................................................................................. 5
`B. Summary of the Prosecution History of the ‘151 Patent...................... 7
`C. Claim Construction under 37 C.F.R. §§ 42.104(b)(3) ......................... 8
`1.
`“Domain Name”................................................................................ 9
`2.
`“DNS Request” ................................................................................. 9
`3.
`“Determining”................................................................................. 10
`4.
`“Secure Server”............................................................................... 13
`5.
`“Automatically” .............................................................................. 14
`6.
`“Client” ........................................................................................... 15
`7.
`“Between [A] and [B]” ................................................................... 15
`V. MANNER OF APPLYING CITED PRIOR ART TO EVERY CLAIM
`FOR WHICH AN IPR IS REQUESTED, THUS ESTABLISHING A
`REASONABLE LIKELIHOOD THAT AT LEAST ONE CLAIM OF THE
`‘151 PATENT IS UNPATENTABLE ......................................................... 16
`A.
`[GROUND 1] – Kiuchi Anticipates Claims 1, 2, 6-8, and 12-14 ...... 16
`1. Kiuchi Anticipates Claim 1............................................................. 25
`2. Kiuchi Anticipates Claim 7............................................................. 32
`3. Kiuchi Anticipates Claim 13........................................................... 33
`4. Kiuchi Anticipates Claims 2, 8, and 14 .......................................... 35
`5. Kiuchi Anticipates Claims 6 and 12 ............................................... 36
`B.
`[GROUND 2] – Kiuchi In View of RESCORLA Renders Obvious
`Claims 1, 2, 6-8, and 12-14 ....................................................................... 37
`C.
`[GROUND 3] – Kiuchi In View of RFC 1034 Renders Obvious
`Claims 1, 2, 6-8, and 12-14 ....................................................................... 42
`1. Kiuchi In View of RFC 1034 Renders Obvious Claim 1 ............... 46
`2. Kiuchi In View of RFC 1034 Renders Obvious Claim 7 ............... 52
`3. Kiuchi In View of RFC 1034 Renders Obvious Claim 13 ............. 53
`
`i
`
`

`
`4. Kiuchi In View of RFC 1034 Renders Obvious Claims 2, 8, and 14
`56
`5. Kiuchi In View of RFC 1034 Renders Obvious Claims 6 and 12.. 56
`D.
`[GROUND 4] – Kiuchi In View of RFC 1034 and Further In View of
`Rescorla Renders Obvious Claims 1, 2, 6-8, and 12-14 ........................... 57
`VI.CONCLUSION ....................................................................................... 58
`
`ii
`
`

`
`Ex. 1001
`
`Ex. 1002
`
`Ex. 1003
`
`Ex. 1004
`
`Ex. 1005
`
`Ex. 1006
`
`Ex. 1007
`
`Ex. 1008
`
`Ex. 1009
`
`Ex. 1010
`
`Ex. 1011
`
`Ex. 1012
`
`Ex. 1013
`
`Ex. 1014
`
`Ex. 1015
`Ex. 1016
`Ex. 1017
`Ex. 1018
`Ex. 1019
`Ex. 1020
`Ex. 1021
`Ex. 1022
`
`EXHIBITS
`
`U.S. Patent No. 7,490,151 to Munger et al. (the "'151
`Patent")
`Takahiro Kiuchi and Shigekoto Kaihara, "C-HTTP - The
`Development of a Secure, Closed HTTP-based Network on
`the Internet," published by IEEE in the Proceedings of
`SNDSS 1996 ("Kiuchi")
`Declaration of Dr. Roch Guerin
`E. Rescorla and A. Schiffman, “The Secure Hypertext
`Transfer Protocol,” Internet Draft (Feb. 1996)
`Mockapetris, P., RFC 1034, "Domain Names–Concepts and
`Facilities," Nov. 1997
`Excerpts from the Prosecution History of the ‘151 Patent
`Patent Owner's Preliminary Response, Paper 7, in IPR2014-
`00610
`Excerpts from Webster’s Third New International Dictionary
`(1971)
`VirnetX's Reply Claim Construction Brief in VirnetX Inc. v.
`Cisco Systems, Inc. et al., 6:10-cv-417 (Dec. 19, 2011) (E.D.
`Tex.)
`Bradner, S., RFC 2026, “The Internet Standards Process –
`Revision 3,” Oct. 1996
`Decision to Institute Inter Partes Review, Paper 9, in
`IPR2014-00610 (Oct. 15, 2014)
`Chatel, M., RFC 1919, “Classical versus Transparent IP
`Proxies,” March 1996
`Fielding et al., RFC 2068, “Hypertext Transfer Protocol –
`HTTP/1.1,” Jan. 1997
`Berners-Lee et al., RFC 1945, "Hypertext Transfer Protocol -
`- HTTP/1.0," May 1996
`(Reserved)
`(Reserved)
`(Reserved)
`(Reserved)
`(Reserved)
`(Reserved)
`(Reserved)
`(Reserved)
`
`iii
`
`

`
`Ex. 1023
`
`Ex. 1024
`
`(Reserved)
`E. Rescorla and A. Schiffman, RFC 2660, “The Secure
`Hypertext Transfer Protocol,” Aug. 1999
`
`iv
`
`

`
`The Mangrove Partners Master Fund, Ltd. (“Petitioner” or
`
`“Mangrove”) petitions for Inter Partes Review (“IPR”) under 35 U.S.C. §§
`
`311–319 and 37 C.F.R. § 42 of claims 1, 2, 6-8, and 12-14 (“the Challenged
`
`Claims”) of U.S. Patent No. 7,490,151 (“the ‘151 patent”). As explained in
`
`this petition, there exists a reasonable likelihood that Mangrove will prevail
`
`with respect to at least one of the Challenged Claims.
`
`The Challenged Claims are unpatentable based on teachings set forth
`
`in at least the references presented in this petition. Mangrove respectfully
`
`submits that an IPR should be instituted, and that the Challenged Claims
`
`should be canceled as unpatentable.
`
`I. MANDATORY NOTICES UNDER 37 C.F.R § 42.8(A)(1)
`A. REAL PARTY-IN-INTEREST UNDER 37 C.F.R. § 42.8(B)(1)
`Petitioner, The Mangrove Partners Master Fund, Ltd., is the real party-in-
`
`interest.
`
`B. RELATED MATTERS UNDER 37 C.F.R. § 42.8(B)(2)
`The ‘151 patent is the subject of a number of civil actions including:
`
`(i) Civ. Act. No. 6:13-cv-00211-LED (E.D. Tex.), filed February 26, 2013;
`
`(ii) Civ. Act. No. 6:12-cv-00855- LED (E.D. Tex.), filed November 6, 2012;
`
`and (iii) Civ. Act. No. 6:10-cv-00417-LED (E.D. Tex.), filed August 11,
`
`2010.
`
`The ’151 patent is also the subject of inter partes reexamination nos.
`
`

`
`95/001,697 and 95/001,714. In the formerly merged proceedings, the Office
`
`issued a Non-Final Action on April 20, 2012 rejecting all 16 claims of the
`
`’151 patent. In particular, all claims of the ‘151 patent were rejected as
`
`either anticipated by Kiuchi (Ex. 1002) or obvious over Kiuchi in view of
`
`other references included in this petition. Those claims were also rejected on
`
`additional grounds as being anticipated or obvious based on a number of
`
`other prior art references.
`
`In addition, the ‘151 patent was the subject of a petition for inter
`
`partes review filed by Microsoft Corporation (IPR2014-00610), which was
`
`instituted based on many of the same grounds detailed below and
`
`subsequently terminated pursuant to a settlement agreement between the
`
`parties in that proceeding. The ‘151 patent was also the subject of petitions
`
`for inter partes review filed by New Bay Capital, LLC (IPR2013-00376),
`
`which was subsequently dismissed, and by Apple Inc. ( IPR2013-00354) and
`
`RPX Corporation (IPR2014-00173), both of which were not instituted due to
`
`their being time-barred.
`
`C. LEAD AND BACK-UP COUNSEL UNDER 37 C.F.R. §
`42.8(B)(3)
`Petitioner provides the following designation of counsel.
`
`LEAD COUNSEL
`
`BACKUP COUNSEL
`
`Abraham Kasdan, Reg. No. 32,997
`
`James T. Bailey, Reg. No. 44,518
`
`2
`
`

`
`Wiggin and Dana LLP
`450 Lexington Avenue
`New York, NY 10017
`T: 212-551-2841
`Email: akasdan@wiggin.com
`
`504 W. 136th St. #1B
`New York, NY 10031
`T: 917-626-1356
`Email: jtb@jtbaileylaw.com
`
`D. SERVICE INFORMATION
`Please address all correspondence and service to counsel at the
`
`address provided in Section I(C). Petitioner also consents to electronic
`
`service by email at IP@wiggin.com.
`
`II. PAYMENT OF FEES – 37 C.F.R. § 42.103
`Petitioner authorizes the Patent and Trademark Office to charge
`
`Deposit Account No. 23-1665 for the fee set in 37 C.F.R. § 42.15(a) for this
`
`Petition and further authorizes payment for any additional fees to be charged
`
`to this Deposit Account.
`
`III. REQUIREMENTS FOR IPR UNDER 37 C.F.R. § 42.104
`A. GROUNDS FOR STANDING UNDER 37 C.F.R. § 42.104(A)
`Mangrove certifies that the ‘151 Patent is eligible for IPR. Mangrove
`
`is not barred or estopped from requesting this review challenging the
`
`Challenged Claims on the below-identified grounds.
`
`B. CHALLENGE UNDER 37 C.F.R. § 42.104(B) AND RELIEF
`REQUESTED
`
`Petitioner requests an IPR of the Challenged Claims on the grounds
`
`set forth in the table shown below, and requests that each of the Challenged
`
`3
`
`

`
`Claims be found unpatentable. An explanation of how these claims are
`
`unpatentable under the statutory grounds identified below is provided in the
`
`form of a detailed description that indicates where each element can be
`
`found in the cited prior art, and the relevance of that prior art. Additional
`
`explanation and support for each ground of rejection is set forth in Exhibit -
`
`1003, the Declaration of Dr. Roch Guerin (“Guerin Declaration”),
`
`referenced throughout this Petition.
`
`Ground
`Ground 1
`
`Basis for Rejection
`‘151 Patent Claims
`1, 2, 6-8 and 12-14 Anticipated under § 102 by Kiuchi
`
`Ground 2
`
`Ground 3
`
`Ground 4
`
`1, 2, 6-8 and 12-14 Obvious under § 103 based on Kiuchi
`in view of Rescorla
`1, 2, 6-8 and 12-14 Obvious under § 103 based on Kiuchi
`in view of RFC 1034
`1, 2, 6-8 and 12-14 Obvious under § 103 based on Kiuchi
`in view of RFC 1034 and further in
`view of Rescorla
`
`Each of the prior art references relied upon herein qualifies as prior art
`
`to the ‘151 Patent under 35 U.S.C § 102(b).
`
`First, Kiuchi qualifies as prior art under 35 U.S.C § 102(b).
`
`Specifically, Kiuchi (Ex. 1002) is a printed publication that was presented at
`
`the 1996 Symposium on Network and Distributed Systems Security
`
`(SNDSS) on February 22 & 23, 1996, and published by IEEE in the
`
`Proceedings of SNDSS 1996. Ex. 1002.
`
`4
`
`

`
`Recorla also qualifies as prior art under 35 U.S.C § 102(b).
`
`Specifically, Rescorla (Ex. 1004) is an Internet-Draft that was published in
`
`February 1996 by the Internet Engineering Task Force (IETF) as part of the
`
`development of RFC 2660. That Internet-Draft was publically distributed no
`
`later than February 1996. Ex. 1004; see also Ex. 1003, ¶¶ 45-52.
`
`RFC 1034 likewise qualifies as prior art under 35 U.S.C § 102(b).
`
`Specifically, RFC 1034 (Ex. 1005) was published in November 1987 by the
`
`Internet Engineering Task Force (IETF). RFC 1034 was publically
`
`distributed no later than November 1987. Ex. 1005.
`
`IV. SUMMARY OF THE ‘151 PATENT
`
`A. BRIEF DESCRIPTION
`
`The ‘151 patent generally addresses secure communications over the
`
`Internet. As acknowledged in the ‘151 patent, “[a] tremendous variety of
`
`methods have been proposed and implemented to provide security and
`
`anonymity for communications over the Internet.” Ex. 1001 at 1:27-29. The
`
`majority of the ‘151 specification is dedicated to describing one particular
`
`way of providing secure and anonymous communications using an allegedly
`
`inventive protocol called the “Tunneled Agile Routing Protocol (TARP).”
`
`See, e.g., id. at 3:5-6:3. The challenged claims of the ‘151 patent, however,
`
`5
`
`

`
`are not limited to TARP and instead all address one of five alleged
`
`“improvements” added by CIP application serial number 09/504,783 filed on
`
`February 15, 2000. Id. at 6:4-16. The claims of the ‘151 Patent are directed
`
`to a system and method for securely communicating over the Internet. Ex.
`
`1001 at 3:8. More specifically, the claims all address “a DNS proxy server
`
`that transparently creates a virtual private network in response to a domain
`
`name inquiry.” Id. at 6:7-9.
`
`A Domain Name System (“DNS”) server provides a look-up function
`
`that returns the IP address of a requested computer or host. Id. at 36:61-63.
`
`A user sends a request to the DNS server to look up the IP address
`
`associated with the name of a destination host. Id. at 37:4-7. The DNS server
`
`returns the IP address to the client, which is then able to use the IP address to
`
`communicate with the host. Id. at 37:6-9.
`
`The ‘151 patent describes a domain name service system configured
`
`to perform the operations of: (1) intercepting a DNS request sent by a client;
`
`(2) determining whether the intercepted DNS request corresponds to a
`
`secure server, (3) when the intercepted DNS request does not correspond to
`
`a secure server, forwarding the DNS request to a DNS function that returns
`
`an IP address of a nonsecure computer, and (4) when the intercepted DNS
`
`request corresponds to a secure server, automatically initiating an encrypted
`
`6
`
`

`
`channel between the client and the secure server. Ex. 1001 at 37: 25-38.
`
`The ‘151 patent includes 16 claims, of which claims 1, 7 and 13 are
`
`independent.
`
`Claim 1 of the ‘151 Patent is reproduced below:
`
`A data processing device, comprising memory storing a
`1.
`domain name server (DNS) proxy module that intercepts DNS
`requests sent by a client and, for each intercepted DNS request,
`performs the steps of:
`
`determining whether the intercepted DNS request
`(i)
`corresponds to a secure server;
`
`(ii) when the intercepted DNS request does not
`correspond to a secure server, forwarding the DNS
`request to a DNS function that returns an IP address of a
`nonsecure computer, and
`
`(iii) when the intercepted DNS request corresponds to a
`secure server, automatically initiating an encrypted
`channel between the client and the secure server.
`
`B. SUMMARY OF THE PROSECUTION HISTORY OF THE
`‘151 PATENT
`
`U.S. Patent No. 7,490,151 issued on February 10, 2009 from U.S.
`
`Patent Application No. 10/259,494 (“the ‘494 application”), which was filed
`
`on September 30, 2002 with 20 claims as a division of U.S. Patent
`
`Application No. 09/504,783 (“the ’783 application”). See Ex. 1006, pp. 8,
`
`79-82. No reasons for allowance are expressly stated in the ‘151 patent file
`
`history. Moreover, the Patent Owner never explicitly distinguished the
`
`7
`
`

`
`ultimately allowed and issued claims from the cited prior art, instead
`
`focusing its responsive arguments on claims that were later cancelled. See,
`
`e.g., Ex. 1006, pp. 359-363, 385-388, 398-399, 559-561. Ultimately the
`
`patent issued on February 10, 2009, though it is not clear whether any
`
`particular feature led to the allowance.
`
`C. CLAIM CONSTRUCTION UNDER 37 C.F.R. §§ 42.104(B)(3)
`
`A claim subject to IPR is given its “broadest reasonable construction
`
`in light of the specification of the patent in which it appears.” 37 C.F.R. §
`
`42.100(b); see also Patent Trial Practice Guide, 77 Fed. Reg. 48,756,
`
`48,766 (Aug. 14, 2012). Under the broadest reasonable standard, claim terms
`
`are given their ordinary and customary meaning as would be understood by
`
`one of ordinary skill in the art in the context of the entire disclosure. In re
`
`Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007). Any special
`
`definition for a claim term must be set forth in the specification with
`
`reasonable clarity, deliberateness, and precision. In re Paulsen, 30 F.3d
`
`1475, 1480 (Fed. Cir. 1994). In this regard, however, care must be taken not
`
`to read a particular embodiment appearing in the written description into the
`
`claim if the claim language is broader than the embodiment. In re Van
`
`Geuns, 988 F.2d 1181, 1184 (Fed. Cir. 1993).
`
`Petitioner submits constructions for the following terms. All
`
`8
`
`

`
`remaining terms should be given their plain meaning.
`
`1.
`
`“DOMAIN NAME”
`
`The Patent Owner has asserted to the PTAB that a “domain name”
`
`means “a name corresponding to a network address.” Nonetheless, Patent
`
`Owner has urged that no interpretation of this term is needed, because it
`
`does not appear alone in the claims, but rather only as part of a larger phrase.
`
`Ex. 1007, p. 21. However, the term is part of the interpretation of “DNS
`
`Request” that the Patent Owner supported and the PTAB adopted in prior
`
`IPR proceedings. Ex. 1011, p. 6 (IPR2014-00610 Paper 9, Decision to
`
`Institute). In view of the Patent Owner’s own assertions, it is reasonable, for
`
`purposes of this proceeding in which the broadest reasonable interpretation
`
`standard applies, to consider the term “domain name” as encompassing “a
`
`name corresponding to a network address.”
`
`2.
`
`“DNS REQUEST”
`
`The Patent Owner has asserted to the PTAB that that a “DNS request”
`
`means “a request for a resource corresponding to a domain name.” Ex. 1007,
`
`p. 22. In IPR2014-00610 the PTAB agreed with and adopted this
`
`interpretation. Petitioner agrees that the term “DNS request” should be
`
`interpreted to mean “a request for a resource corresponding to a domain
`
`name.”
`
`9
`
`

`
`Moreover, as explained immediately above, the parties agree that the
`
`term “domain name” means “a name corresponding to a network address.”
`
`To the extent the PTAB declines to provide an explicit interpretation of
`
`“domain name” as discussed immediately above, that agreed understanding
`
`should be incorporated into the interpretation of “DNS request,” which
`
`should then be interpreted to mean “a request for a resource corresponding
`
`to a network address.”
`
`3.
`
`“DETERMINING”
`
`Petitioner agrees with the PTAB that the word “determining” should
`
`be given its “plain and ordinary meaning” of “’to come to a decision
`
`concerning as the result of investigation or reasoning’ or ‘to cause or elicit a
`
`determination of.’” Ex. 1011, pp. 11-12 (quoting WEBSTER’S THIRD
`
`NEW INTERNATIONAL DICTIONARY 616 (1971)) (Ex. 1008)
`
`In IPR2014-00610, the Patent Owner argued that Kiuchi did not
`
`disclose the step of “determining whether the intercepted DNS request
`
`corresponds to a secure server” found in claim 1. In particular, Patent
`
`Owner argued that the “client side proxy” described in Kiuchi, which makes
`
`up a portion of the “domain name server (DNS) proxy module” of the
`
`preamble of claim 1, does not itself perform the determining step because it
`
`“asks” a different entity, the C-HTTP name server, for information used in
`
`10
`
`

`
`the determination. Patent Owner argued it was “[t]he C-HTTP name server,
`
`not the client-side proxy” that performed the determining step. Ex. 1007
`
`(Patent Owner’s Preliminary Response IPR2014-00610) p. 5 (emphasis in
`
`original)
`
`The PTAB correctly rejected this argument as inconsistent with the
`
`plain and ordinary meaning of “determining.” Ex. 1011, pp. 11-12. The
`
`PTAB’s reasoning is not only consistent with the plain meaning of
`
`determining, it is consistent with the specification of the ‘151 patent.
`
`For example, claims 2, 8 and 14 depend upon independent claim 1, 7
`
`and 13 respectively, share the same preambles, and each dependent claim
`
`includes the step of “determining whether the client is authorized to access
`
`the secure server.” Ex. 1001 47:1-4, 39-42, 48:30-33. As described in the
`
`specification, the “determining” step of claims 2, 8, and 14 may be made by
`
`the DNS proxy module by querying a separate entity (the gatekeeper):
`
`“FIG. 27 shows steps that can be executed by DNS proxy
`
`server 2610 to handle requests for DNS look-up for secure
`
`hosts. . . . In step 2702, if access to a secure host was
`
`requested, then in step 2704 a further check is made to
`
`determine whether the user is authorized to connect to the
`
`secure host. Such a check can be made with reference to an
`
`internally stored list of authorized IP addresses, or can be
`
`made by communicating with gatekeeper 2603 (e.g., over an
`
`11
`
`

`
`‘administrative’ VPN that is secure).” Ex. 1001 38:36-50
`
`(emphasis added); see also id. FIGS. 26-27.
`
`As shown in Figure 26, the “gatekeeper 2603” is a separate entity
`
`from the “DNS proxy server 2610.” Ex. 1001 FIG. 26; see also id. at 38:22-
`
`25 (“Gatekeeper 2603 can be implemented on a separate computer (as
`
`shown in FIG. 26) or as a function within modified DNS server 2602.”)
`
`Accordingly, as confirmed by the specification, the word “determining”
`
`should be given its plain and ordinary meaning of “to come to a decision
`
`concerning as the result of investigation or reasoning” or “to cause or elicit a
`
`12
`
`

`
`determination of.” WEBSTER’S THIRD NEW INTERNATIONAL
`
`DICTIONARY 616 (1971)) (Ex. 1008)
`
`4.
`
`“SECURE SERVER”
`
`The Patent Owner has asserted to the PTAB that a “secure server”
`
`means “a server that requires authorization for access and that can
`
`communicate in an encrypted channel.” Ex. 1007, pp. 23-24. However, as
`
`the PTAB pointed out, there is nothing in the plain meaning of “secure
`
`server” nor the specification of the ‘151 patent that requires that a “secure
`
`server” must communicate in an “encrypted channel,” as opposed to any
`
`13
`
`

`
`channel that is secure by means other than encryption. Ex. 1011, p. 7.
`
`Accordingly, as the PTAB previously found, the broadest reasonable
`
`interpretation of “secure server” should be interpreted to mean “ a server that
`
`communicates over a transmission path that restricts access to data or other
`
`information on the path.”
`
`5.
`
`“AUTOMATICALLY”
`
`The Patent Owner has asserted to the PTAB “automatically
`
`initiating/creating an encrypted/ secure channel” means “initiating/creating
`
`the encrypted/secure channel without involvement of a user.” Ex. 1007, pp.
`
`24-25. However, as the PTAB has previously pointed out, “the term
`
`‘automatic’ has a plain and ordinary meaning of ‘marked by action that . . .
`
`arises as a really or apparently necessary reaction to or consequence of a
`
`given set of circumstances’ or ‘having a self-acting or self-regulating
`
`mechanism.’” Ex. 1011, p. 7, quoting WEBSTER’S THIRD NEW
`
`INTERNATIONAL DICTIONARY 148 (1971) (Ex. 1008). As the PTAB
`
`previously found, neither the plain meaning of “automatically” nor the ‘151
`
`specification support the Patent Owner’s proposed added limitation that
`
`“automatically” means “without user involvement.” Ex. 1011, pp. 6-7.
`
`Accordingly, the word “automatically” should be interpreted under its
`
`ordinary meaning as “marked by action that arises as a really or apparently
`
`14
`
`

`
`necessary reaction to or consequence of a given set of circumstances” or
`
`“having a self-acting or self-regulating mechanism.”
`
`6.
`
`“CLIENT”
`
`Petitioner agrees with the PTAB that a “client,” under the broadest
`
`reasonable interpretation of that term, should be interpreted as “a device,
`
`computer, system, or program from which a data request to a server is
`
`generated.” Ex. 1011, pp. 7-8. This is consistent with the ‘151 patent’s
`
`specification and the understanding one of ordinary skill in the art would
`
`ascribe to this term when identifying the broadest reasonable interpretation.
`
`See Ex. 1003. ¶ 16.
`
`In particular, the ‘151 patent describes that “user's computer 2501
`
`includes a client application 2504 (for example, a web browser) and an IP
`
`protocol stack 2505.” Ex. 1001 at 37:1-3. Notably this sentence uses the
`
`term “client” with regard to an application, not the “user’s computer.” Thus,
`
`under this term’s broadest reasonable interpretation, the ‘151 patent supports
`
`that “client” may refer to an application, not just a physical machine.
`
`7.
`
`“BETWEEN [A] AND [B]”
`
`In prior litigation involving the ‘151 patent, the Patent Owner argued
`
`that “between” should mean “extend from one endpoint to the other,” and
`
`15
`
`

`
`instead stated that “between” should only apply to the “public
`
`communication paths.” Ex. 1009, p. 10. Under the Patent Owner’s
`
`contentions, an encrypted/secure channel is “between” a client and a secure
`
`server where the channel is on the public communication paths between the
`
`client and the secure server, regardless of whether the encrypted/secure
`
`channel extends completely from the client to the secure server.
`
`In a prior IPR proceeding, the Patent Owner contended that, despite
`
`its earlier contentions regarding the meaning of “between,” no construction
`
`was necessary. See, e.g., Ex. 1011, p. 8. However, the PTAB adopted a
`
`plain and customary meaning of “between” to mean “in the space that
`
`separates.” Id. quoting WEBSTER’S THIRD NEW INTERNATIONAL
`
`DICTIONARY 209 (1971)) (Ex. 1008). Petitioner agrees with the plain and
`
`customary meaning adopted by the PTAB, and notes that it is broad enough
`
`to encompass the Patent Owner’s prior litigation position.
`
`V. MANNER OF APPLYING CITED PRIOR ART TO EVERY
`CLAIM FOR WHICH AN IPR IS REQUESTED, THUS
`ESTABLISHING A REASONABLE LIKELIHOOD THAT AT
`LEAST ONE CLAIM OF THE ‘151 PATENT IS
`UNPATENTABLE
`
`A.
`
`[GROUND 1] – KIUCHI ANTICIPATES CLAIMS 1, 2, 6-8,
`AND 12-14
`
`Kiuchi is a printed publication that was presented at the 1996
`
`16
`
`

`
`Symposium on Network and Distributed Systems Security (SNDSS) on
`
`February 22 & 23, 1996, and published by IEEE in the Proceedings of
`
`SNDSS 1996. Kiuchi was distributed publicly without restriction no later
`
`than February 1996. See Ex. 1002. Ex. 1002. Kiuchi is therefore prior art to
`
`the ‘151 patent at least under § 102(b).
`
`Overview of Kiuchi
`
`Kiuchi describes a system and a protocol called “C-HTTP” that
`
`“provides secure HTTP communication mechanisms within a closed group
`
`of institutions on the Internet, where each member is protected by its own
`
`firewall.” Ex. 1002, p. 64, Abstract. Kiuchi describes that C-HTTP can be
`
`used to create “a closed HTTP-based virtual network . . . for closed groups;
`
`for example, the headquarters and branches of a given corporation.” Ex.
`
`1002, p. 69, § 5. The following Diagram 1 illustrates relevant parts within
`
`the C-HTTP system described by Kiuchi, and will be used to describe the C-
`
`HTTP system. See Ex. 1003, ¶ 17.
`
`17
`
`

`
`Leveraging these parts, Kiuchi describes a process by which a client-
`
`side proxy establishes a secure connection with a server-side proxy using the
`
`C-HTTP protocol over the Internet (i.e., a C-HTTP connection), thus
`
`establishing a closed virtual network including a user agent and an origin
`
`server. See Ex. 1002, p. 64, § 2.1; p. 69, § 5; see also Ex. 1003, ¶ 18.
`
`Through the C-HTTP connection, a user agent associated with the client-side
`
`proxy may request information stored on an origin server associated with the
`
`server-side proxy. See id. In order to establish a C-HTTP connection, Kiuchi
`
`teaches discrete steps that will be described using the following block
`
`diagram. See Ex. 1002, pp. 65-66, § 2.3; see also, Diagram 2, where each
`
`step is numbered to indicate a temporal sequence of the steps taught by
`
`18
`
`

`
`Kiuchi (Ex. 1003, ¶ 19).
`
`To enable initiation of this set of steps, the user agent displays HTML
`
`documents to an end-user. See Ex. 1002, p. 65, § 2.3. Through interaction
`
`with the user agent, the end user selects a hyperlink URL included within an
`
`HTML document. See id. Kiuchi provides an example of the selected URL:
`
`“http://server.in.current.connection/sample.html=@=6zdDfldfcZLj8V!i”,
`
`where “server. in.current.connection” is the hostname, “sample.html” is the
`
`name of the resource being requested, and “6zdDfldfcZLj8V!i” is a
`
`connection ID. See Ex. 1002, p. 65, § 2.3; see also Ex. 1003, ¶ 20.
`
`Thereafter, as illustrated by Diagram 3, initial steps are performed by
`
`Kiuchi’s system in response to user selection of the hyperlink. These steps
`
`include: (1) a request being sent from the user agent to the client-side proxy
`
`19
`
`

`
`for the selected URL; (2) a request being sent from the client-side proxy to
`
`the C-HTTP name server for an IP address corresponding to the hostname
`
`included in the selected URL; and (3) a response being returned from the C-
`
`HTTP name server that either includes the IP address associated with the
`
`server-side proxy or an error message. Ex. 1003, ¶ 24. If the C-HTTP name
`
`server returns an error message (i.e., if the hostname does not correspond to
`
`a secure server in the closed network, or the connection is not permitted),
`
`then the client-side proxy performs a DNS lookup using the standard/public
`
`DNS, as illustrated by the dashed line. See Ex. 1002, p. 65, § 2.3; see also
`
`Ex. 1003, ¶ 24.
`
`20
`
`

`
`Analyzing these steps in further detail, when the end user selects the
`
`hyperlink in the displayed HTML document, the user agent sends a request
`
`for the URL to the client-side proxy, as illustrated by (1) in Diagram 3. See
`
`Ex. 1002, p. 65, § 2.3. When the client-side proxy receives the URL
`
`(including the hostname) from the user agent, it determines whether the
`
`connection ID included in the URL matches the IDs of any current
`
`connections being maintained by the client-side proxy. See id. If the
`
`connection ID is not found in the current connection table in the client-side
`
`proxy, the client-side proxy attempts to establish a new connection with the
`
`host corresponding to the hostname included in the URL. See id.
`
`To establish a new connection with the corresponding host, as illustrated by
`
`(2) in Diagram 3, the client-side proxy sends a request to ask the C-HTTP
`
`name server whether the client-side proxy can communicate with the host
`
`associated with the hostname and, if so, to resolve the hostname included in
`
`the URL such that the corresponding IP address is returned by the C-HTTP
`
`name server to the client-side proxy. See Ex. 1002, p. 65, § 2.3(2). In some
`
`instances, the hostname corresponds to an origin server associated with a
`
`server-side proxy and is associated with an IP address for the server-side
`
`proxy. See Ex. 1002, p. 65, § 2.3; see also Ex. 1003, ¶¶ 20-22. In other
`
`instances, the hostname corresponds to a server on the Internet outside the
`
`21
`
`

`
`C-HTTP network. See Ex. 1002, p. 65, § 2.3; see also Ex. 1003, ¶ 22.
`
`Upon receipt of the request, the C-HTTP name server first
`
`authenticates the client-side proxy (and, by association, the user agent) to
`
`determine if the request is legitimate. See Ex. 1002, p. 65, § 2.3; see also Ex.
`
`1003, ¶ 23. When the request is legitimate, the C-HTTP name server
`
`determines whether a “server-side proxy [associated with the hostname] is
`
`registered in the closed network.” See id. As illustrated by (3) in Diagram 3,
`
`if connection is not permitted, then the C-HTTP name server returns an error
`
`message, in response to which the client-side proxy performs a look-up with
`
`a standard/public DNS server, behaving like an ordinary HTTP proxy. See
`
`id. The standard/public DNS server then returns an IP address of the host
`
`corresponding to the hostname, which the client-side proxy uses to connect
`
`to the host on behalf of the user agent. See id.
`
`On the other hand, if the server-side proxy is permitted to accept a
`
`connection from the client-side proxy, then the C-HTTP name server sends a
`
`response to the client-side proxy’s request that includes “the IP address and
`
`public key of the server-side proxy and both request and response Nonce
`
`values,” as illustrated by (3) in Diagram 3. See Ex. 1002, p. 65, § 2.3; Ex.
`
`1003, ¶¶ 23-24. Notably, the C-HTTP name server never provides the IP
`
`address of the origin server to the client-side proxy. Ex. 1002 p. 65, § 2.2;
`
`22
`
`

`
`Ex. 1003, ¶ 25. Rather, when the C-HTTP name server returns the IP
`
`address of the server-side proxy along with the server-side proxy’s public
`
`key and the Nonce values, the client-side proxy attempts to establish a C-
`
`HTTP connection with the server-side proxy using the IP address received
`
`from the C-HTTP name server. See Ex. 1002, p. 65, § 2.3; Ex. 1003, ¶ 25.
`
`The steps for doing so are illustrated in Diagram 4. See Ex. 1003, ¶ 25.
`
`In particular, Kiuchi describes that the client-side proxy, in response
`
`to receiving the IP address of the server-side proxy and other information
`
`from the C-HTTP name server, sends a “[r]equest for connection to the
`
`server-side proxy” (4), the server-side proxy performs a “[l]ookup of client-
`
`side proxy information”