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

EXHIBITS
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

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 NamesConcepts and
Facilities," Nov. 1997
Excerpts from the Prosecution History of the 151 Patent
Patent Owner's Preliminary Response, Paper 7, in IPR201400610
Excerpts from Websters 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.
311319 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-ininterest.
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

504 W. 136th St. #1B

New York, NY 10031
T: 917-626-1356
Email: jtb@jtbaileylaw.com

Wiggin and Dana LLP

450 Lexington Avenue
New York, NY 10017
T: 212-551-2841
Email: akasdan@wiggin.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

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

151 Patent Claims

Basis for Rejection
1, 2, 6-8 and 12-14 Anticipated under 102 by Kiuchi

Ground 2

1, 2, 6-8 and 12-14

Ground 3

1, 2, 6-8 and 12-14

Ground 4

1, 2, 6-8 and 12-14

Obvious under 103 based on Kiuchi

in view of Rescorla
Obvious under 103 based on Kiuchi
in view of RFC 1034
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.

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

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:
1.
A data processing device, comprising memory storing a
domain name server (DNS) proxy module that intercepts DNS
requests sent by a client and, for each intercepted DNS request,
performs the steps of:
(i)
determining whether the intercepted DNS request
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

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 Owners 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 WEBSTERS 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 Owners 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
PTABs 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:2225 (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. WEBSTERS 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 WEBSTERS 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 Owners 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 patents
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 users computer. Thus,
under this terms 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 Owners
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 WEBSTERS 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 Owners 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 CHTTP system. See Ex. 1003, 17.

17

Leveraging these parts, Kiuchi describes a process by which a clientside 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
Kiuchis 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 CHTTP 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 proxys 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 proxys public
key and the Nonce values, the client-side proxy attempts to establish a CHTTP 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 clientside proxy information with the C HTTP name server (5 and 6), and the
server-side proxy sends confirmation of the connection to the client-side
proxy (7), if the server-side proxy is able to properly authenticate the clientside proxy. See Ex. 1002, pp. 65-66, 2.3, steps 3-5; see also Ex. 1003,
27.

23

Considering these steps in further detail, the client-side proxy, in

response to receiving the IP address and associated information from the CHTTP server, sends a request for connection to the server-side proxy, as
illustrated by (4) in Diagram 4. See Ex. 1002, p. 65, 2.3; see also Ex. 1003,
28. The client-side proxy encrypts the request for connection using the
server-side proxys public key and includes in the request the client-side
proxy's IP address, hostname, request Nonce value and symmetric data
exchange key for request encryption. See Ex. 1002, p. 65, 2.3; see also
Ex. 1003, 28. After receiving the request, the server-side proxy asks the
C-HTTP name server whether the client-side proxy is an appropriate
member of the closed network, as illustrated by (5) in Diagram 4, and, in
response, the C-HTTP name server examines whether the client-side proxy
is permitted to access the server-side proxy. Ex. 1002, pp. 65-66, 2.3; see

24

also Ex. 1003, 28. If the C-HTTP name server determines that access is
permitted, the C-HTTP name server sends [to the server-side proxy] the IP
address and public key of the client-side proxy and both request and
response Nonce values, as illustrated by (6) in Diagram 4. Ex. 1002, p. 66,
2.3; see also Ex. 1003, 28.
After the C-HTTP name server provides both client-side and serverside proxies with each peer's public key, the proxies establish a C-HTTP
connection. Ex. 1002 p. 66, 2.3; see also Ex. 1003, 29. The C-HTTP
connection provides [a] secure HTTP communication mechanisms in
which communications over the C-HTTP connection are encrypted. Ex.
1002, pp. 64-66, Abstract; see also Ex. 1003, 29.
1.

KIUCHI ANTICIPATES CLAIM 1

a.

PREAMBLE

Kiuchi discloses [a] data processing device, comprising memory

storing a domain name server (DNS) proxy module that intercepts DNS
requests sent by a client, as recited in claim 1. See Ex. 1003 at 18, 20-21.
For example, Kiuchis client-side proxy working in concert with the CHTTP name server is a domain name server (DNS) proxy module that
intercepts DNS requests sent by a user agent acting as a client. See id. As
described in Kiuchi, the client-side proxy is a program installed on a
25

firewall, so the client-side proxy is stored in the memory of a data

processing device. See Ex. 1002 at p. 65, 2.2.
In particular, as described above, Kiuchis client-side proxy receives a
request from the user agent. See Ex. 1002, p. 65 at 2.3; see also Ex. 1003,
18, 20-21. The user agents request is a request for content corresponding
to a hostname in a URL (e.g., an HTML document). See id. The request
from the client-side proxy therefore requests resources corresponding to the
hostname. In this case, the hostname is a domain name, under that terms
broadest reasonable interpretation, because the hostname corresponds to an
IP address. The user agent is a client, under that terms broadest
reasonable interpretation, because the user agent is a computer or program
from which a data request to a server is generated. The request from the user
agent sent to the client-side proxy is a DNS request, under that terms
broadest reasonable interpretation, because the request is a request for a
resource (e.g., an HTML document) corresponding to a domain name (the
hostname).
Kiuchi discloses the DNS proxy module performing the step of
determining whether the intercepted DNS request corresponds to a secure
server, under the broadest reasonable interpretation, as recited in claim 1.
For example, as described above, the client-side proxy receives a request

26

from the user agent, and the request includes a hostname. See Ex. 1002, p.
65, 2.3. In some instances, the hostname corresponds to an origin server
associated with a server-side proxy and designates the server-side proxy. See
Ex. 1002, p. 65, 2.3; see also Ex. 1003, 22.
The origin server is a secure server, under the broadest reasonable
interpretation of secure server, because it communicates over a transmission
path that restricts access to data or other information on the path. In
addition, the origin server meets the narrower interpretation of secure
server previously proposed by the Patent Owner because authorization is
needed to access the origin server and the origin server can communicate in
an encrypted channel. In particular, as described above, before the serverside proxy will accept a client-side proxys request for connection, the
server-side proxy asks the C-HTTP name server whether the client-side
proxy is an appropriate member of the closed network and, in response, the
C-HTTP name server examines whether the client-side proxy is permitted
to access to the server-side proxy and therefore the origin server. Ex. 1002,
pp. 65-66, 2.3; see also Ex. 1003, 27-28. If the C-HTTP server
determines
that access is permitted, the C-HTTP name server sends the IP address and
public key of the client-side proxy and both request and response Nonce

27

values, which are used to establish the C-HTTP connection. Ex. 1002, p.
66, 2.3. As described above, the C-HTTP connection is an encrypted
channel that allows communications between the user agent and the origin
server via the server-side proxy. See Ex. 1003, 31. Accordingly,
authorization is required to establish the C-HTTP connection and therefore
to access the server-side proxy and origin server, and the C-HTTP
connection is an encrypted channel in which the server-side proxy (and
through it the origin server) can communicate. Communications between the
user agent and the client-side proxy as well as those between the original
server and the server-side proxy are behind the firewall of their respective
site, and therefore protected (Ex. 1002, p. 64 Sec. 2.1 ll. 2-3). This, together
with the security afforded by the encrypted C-HTTP connection over the
public communication path between the client-side proxy and the server-side
proxy, ensures that communications between the user agent and the original
server are over a secure channel. As such, both the server-side proxy and
origin server are a secure servers, under that terms broadest reasonable
interpretation.
b.

STEP (i)

The client-side proxy determines whether the request from the user
agent corresponds to a secure server. See Ex. 1003, 26. In particular, when

28

the client-side proxy receives the request from the user agent, the client-side
proxy determines whether the request corresponds to a secure server by
asking the C-HTTP name server whether it can communicate with the host
specified in a given URL. Ex. 1002, p. 65, 2.3; see Ex. 1003, 23-24,
26. If the requested server-side proxy [associated with the hostname] is
registered in the closed network, then the client-side proxy receives, from
the C-HTTP server, the IP address and public key of the server-side proxy
and both request and response Nonce values. Id. Otherwise, if the serverside proxy associated with the origin server is not registered in the closed
network, then the client-side proxy receives a status code which indicates
an error. Id.
c.

STEP (ii)

Kiuchi discloses a DNS proxy module that performs the step of 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, as recited in claim 1. See Ex. 1003, 23.
As described above, in Kiuchi, if the client-side proxy receives
from the C-HTTP name server the status code that indicates an error, (and
therefore the request does not correspond to a secure server), then the clientside proxy behave[s] like an ordinary HTTP/1.0 proxy by perform[ing]

29

DNS lookup. See Ex. 1002 at p. 65, 2.3; see also Ex. 1003 at 23. To do
so, the client-side proxy sends a request to a standard/public DNS. Id. The
standard/public DNS server returns an IP address corresponding to the
hostname in the URL to the client-side proxy. Id.
d.

STEP (iii)

Kiuchi also discloses a DNS proxy module that performs the step of
when the intercepted DNS request corresponds to a secure server,
automatically initiating an encrypted channel between the client and the
secure server, as recited in claim 1.
As described above, Kiuchi describes that, if the client-side proxy
receives from the C-HTTP name server the IP address and public key of the
server-side proxy and both request and response Nonce values (and
therefore the request corresponds to a secure server), the client-side proxy
uses this information to initiate a sequence of steps for a secure C-HTTP
session. Ex. 1002, p. 65, 2.2-2.3; see also Ex. 1003, 23-25. In
particular, the client-side proxy first sends a request for connection to the
server-side proxy. Id. The client-side proxy encrypts the request for
connection using the server-side proxys public key and includes in the
request the client-side proxy's IP address, hostname, request Nonce value
and symmetric data exchange key for request encryption. Id. After

30

receiving the request for connection from the client-side proxy, the serverside proxy verifies that the client-side proxy is an appropriate member of
the closed network and, if so, receives from the C-HTTP server the IP
address and public key of the client-side proxy and both request and
response Nonce values. Ex. 1002, p. 66, 2.3. After both client-side
and server-side proxies obtain each peer's public key, the proxies establish a
C-HTTP connection. See id.; see also Ex. 1003, 29. The C-HTTP
connection provides [a] secure HTTP communication mechanisms in
which communications over the C-HTTP connection are encrypted. Ex.
1002, pp. 64-66.
As a result, the client-side proxy initiates an encrypted channel
between the user agent and the origin server via the server-side proxy. See
Ex. 1003, 28, 31. In particular, by sending a request for connection to the
server-side proxy, the client-side proxy initiates an encrypted channel on
public communication paths between the user agent and the origin server
(i.e., the communication path over the Internet between the client-side proxy
and the server-side proxy). See id. Furthermore, this process is performed
without the involvement of a user. See id., 30. As such, this channel is
automatically initiated, under that terms broadest reasonable interpretation
and the narrower interpretation proposed by the Patent Owner.

31

Therefore, Kiuchi discloses that the client-side proxy automatically

initiates an encrypted channel between the user agent (acting as a client) and
the origin server (a secure server) via the server-side proxy (also a secure
server).
2.

KIUCHI ANTICIPATES CLAIM 7

Kiuchi discloses a computer readable medium comprised of

computer readable instructions that, when executed cause a data processing
device to perform the steps specified by those instructions, as recited in
claim 7. See Ex. 1002, p. 65, 2.2. In particular, the client-side proxy
described in Kiuchi, which works in concert with the C-HTTP name server,
contains computer readable instructions that cause the client-side proxy to
implement the C-HTTP protocol. Id.
Steps (ii), (iii), and (iv) of claim 7 are identical to steps (i), (ii), and
(iii) of claim 1. As explained in II.A.1, above, Kiuchi describes systems
that perform steps (ii), (iii), and (iv) of claim 7. Claim 7 further specifies the
step of (i) intercepting a DNS request sent by a client. As explained in
II.A.1, above, Kiuchi describes that the client-side proxy receives a request
sent by the user agent. See Ex. 1002, p. 65, 2.3. The request is a DNS
request, under that terms broadest reasonable construction, because the
request is a request for a resource (e.g., an HTML document) corresponding

32

to a domain name (the hostname). Thus, Kiuchi shows (i) intercepting a

DNS request sent by a client. See Ex. 1003, 20-21. Kiuchi therefore
describes all the elements specified in claim 7, and anticipates this claim.
3.

KIUCHI ANTICIPATES CLAIM 13

a.

PREAMBLE

Kiuchi discloses a computer readable medium storing a domain

name server (DNS) module comprised of computer readable instructions
that, when executed cause a data processing device to perform the steps of,
as recited in claim 13. See Ex. 1002 at p. 65, 2.2. In particular, the clientside proxy described in Kiuchi, which works in concert with the C-HTTP
name server, contains computer readable instructions that cause the clientside proxy to implement the C-HTTP protocol, which was described in
V.A.1, above. Id.
b.

STEPS (i) AND (ii)

As explained in V.A.1, Kiuchi discloses (i) determining whether a

DNS request sent by a client corresponds to a secure server and (ii) when
the 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; as recited in claim 13. See Ex. 1003, 23-26.

33

c.

STEP (iii)

Kiuchi also discloses (iii) when the intercepted DNS request

corresponds to a secure server, automatically creating a secure channel
between the client and the secure server, as recited in claim 13. As
explained in V.A.1, Kiuchi describes that, if the client-side proxy
determines that the query request from the user agent corresponds to a
secure destination, then the client-side proxy uses the IP address and public
key of the server-side proxy and both request and response Nonce values to
send an encrypted request for connection to the server-side proxy for a
secure C-HTTP session. Ex. 1002, p. 65, 2.2-2.3; see also Ex. 1003,
26-28. In response to receiving this request for connection, the server-side
proxy verifies that the client-side proxy is a member of the closed network.
Id. After verification, both client-side and server-side proxies use each peer's
public key to establish a C-HTTP connection. See Ex. 1002 p. 66, 2.3; see
also Ex. 1003, 29. The C-HTTP connection provides [a] secure HTTP
communication mechanisms in which communications over the C-HTTP
connection are encrypted. Ex. 1002, pp. 64-66, Abstract.
As a result, the client-side proxy creates a secure channel between the
user agent and the origin server via the server-side proxy. See Ex. 1003,
29, 31. In particular, by sending a request for connection to the server-side

34

proxy, the client-side proxy creates a secure channel on the public

communication paths from the user agent to the origin server (i.e., the
communication path over the Internet between the client-side proxy and the
server-side proxy). See id. Furthermore, this process is performed without
the involvement of a user. See Ex. 1003, 30. As such, this channel is
automatically created, under that terms broadest reasonable interpretation as
well as the narrower interpretation proposed by the Patent Owner. Therefore,
Kiuchi discloses that the client-side proxy automatically creates a secure
channel between the user agent (acting as a client) and the origin server (a
secure server) via the server-side proxy (also a secure server).
4.

KIUCHI ANTICIPATES CLAIMS 2, 8, AND 14

Claims 2, 8, and 14 depend from claims 1, 7, and 13, respectively, and

further specify wherein step (iii) comprises the steps of: (a) determining
whether the client is authorized to access the secure server; and (b) when the
client is authorized to access the secure server, sending a request to the
secure server to establish an encrypted[/secure] channel between the secure
server and the client.
a.

STEP (a)

This step is disclosed in Kiuchi. Specifically, Kiuchi discloses that

when the client-side proxy receives an HTTP request from a user agent, it
35

sends a request to a C-HTTP name server. See Ex. 1002, p. 65. 2.3; see
also Ex. 1003, 22. The C-HTTP name server then authenticates the request
and then evaluates it to determine if the connection is permitted. See Ex.
1002, pp. 65-66, 2.3; see also Ex. 1003 at 23.
b.

STEP (b)

This step is also disclosed in Kiuchi. Specifically, in Kiuchi, if the CHTTP name server determines the connection is not permitted, it returns an
error code. See Ex. 1002, p. 65. 2.3; see also Ex. 1003, 23-24. If, on the
other hand, the C-HTTP name server determines the connection is permitted,
it returns the IP address and public key of the server-side proxy and both
request and response Nonce values. Ex. 1002, p. 65, 2.3(2); see also Ex.
1003, 23. When the client-side proxy receives the IP address, public key,
and Nonce values (as opposed to an error message), the client-side proxy
sends a request to the server-side proxy (a secure server) to establish an
encrypted channel between the server-side proxy and the user agent. See Ex.
1002 at p. 65, 2.3(3); see also Ex. 1003 at 26-29, 31.
5.

KIUCHI ANTICIPATES CLAIMS 6 AND 12

Claims 6 and 12 depend from claims 1 and 7, respectively, and further

specify wherein automatically initiating the encrypted channel between the
client and the secure server avoids sending a true IP address of the secure
36

server to the client.

As explained in V.A.1, above, Kiuchi discloses that automatically
initiating/creating the encrypted/secure channel between the user agent
(acting as a client) and the origin server (a secure server) avoids sending a
true IP address of the origin server to the user agent. Instead, as described in
V.A.1, Kiuchi discloses that, after the client-side proxy intercepts the
query request from the user agent, the client-side proxy determines that the
request from the user agent is authorized and uses the received IP address of
the server-side proxy to send a request for connection to the server-side
proxy. See Ex. 1002, p. 65, 2.3; see also Ex. 1003, 26. Kiuchi discloses
that [f]rom the view of the user agent or client-side proxy, all resources
appear to be located in a server-side proxy on the firewall. In reality,
however, the server-side proxy forwards requests to the origin server. Ex.
1002, p. 66. Therefore, the client-side proxy avoids sending the true IP
address of the secure server to the client.
B.

[GROUND 2] KIUCHI IN VIEW OF RESCORLA

RENDERS OBVIOUS CLAIMS 1, 2, 6-8, AND 12-14

Claims 1, 2, 6-8, and 12-14 are anticipated by Kiuchi for the reasons
set forth in V.A.1 to V.A.5, above. To the extent Patent Owner contends
that Kiuchi does not expressly show automatically initiating/creating an
encrypted/secure channel between the client and the secure server a

37

position that would be inconsistent with its prior interpretations of the

limitation the claims are still invalid as obvious.
In particular, were the Patent Owner to contend that an
encrypted/secure channel between a client and a secure server must be an
encrypted/secure channel that extends from the client to the secure server,
rather than just an intermediate portion there-between, a person of ordinary
skill in the art in February of 2000 would have considered these claims
obvious based on Kiuchi in view of, inter alia, the information in an Internet
Draft by E. Rescorla and A. Schiffman published in February 1996 entitled
The Secure Hypertext Transfer Protocol that was part of the development
of RFC 2660 (hereinafter Rescorla or Ex. 1004). See Ex. 1003 32-36,
51.
Rescorla discloses a client and server authenticating each other and
exchanging sensitive information confidentially using secure communication
mechanisms between an HTTP client-server pair, i.e., a Secure HTTP (SHTTP) protocol. See Ex. 1004, pp. 5, 8-10, 13-14.
A person of ordinary skill would have considered it obvious to
configure Kiuchis user agent and origin server to implement end-to-end
secure transactions using the Secure HTTP (S-HTTP) protocol disclosed in
Rescorla. Kiuchi opens the door to this possibility and in fact suggests this

38

combination through the following disclosure: [a]lthough the current CHTTP implementation assumes the use of HTTP/1.0 compatible user agents
and servers, it is possible to develop C-HTTP proxies which can
communicate with other secure HTTP compatible user agents and servers.
Ex. 1002, p. 69, 4.4; see Ex. 1003, 33. To permit this, Kiuchi describes
that C-HTTP can co-exist with other secure HTTP proposals. See id.
Kiuchi also describes the motivation to do so by describing the resulting
benefit of assuring both institutional and personal level security: [i]f CHTTP is used with these protocols, which assure end-to-end or individual
security, both institutional and personal level security protection can be
provided. Id. As an example of a secure HTTP protocol that can be used at
a user agent and at an origin server, Kiuchi expressly refers to an earlier
Internet-Draft published as part of the development of RFC 2660. See Ex.
1002, pp. 69-70 at 6 (Reference No. 12) (Rescorla E., Schiffman A. The
Securer Hypertext Transfer Protocol, Internet Draft, 1995 (Work in progress,
available on the World Wide Web as ftp:ds.internic.net/internet-drafts/draftietf-wts-shttp-00.txt)); see also Ex. 1003, 51.
Rescorla discloses the use of encryption between clients and servers:
Secure HTTP (S-HTTP) provides secure communication mechanisms
between an HTTP client server pair in order to enable spontaneous

39

commercial transactions for a wide range of applications. Ex. 1004 at 1;

see also Ex. 1003, 34. In particular, Rescorla describes that Secure HTTP
supports a variety of security mechanisms to HTTP clients and servers and
that [s]everal cryptographic message format standards may be incorporated
into S-HTTP clients and servers. Ex. 1004 at 1.1. S-HTTP provides full
flexibility of cryptographic algorithms, modes and parameters. Id.
The combination of Kiuchi and Rescorla would result in encrypted
communications between the user agent and origin server using S-HTTP
messages instead of standard HTTP/1.0 messages. See Ex. 1003 at 34. In
this way, one of ordinary skill in the art would understand that the use of SHTTP could simply replace the HTTP 1.0 messages otherwise employed in
the C-HTTP security scheme described by Kiuchi. See id. As described by
Kiuchi, [t]his means that even if individual security management is not
sufficient, data security can be guaranteed. In this case, administrators of
proxies on the firewall cannot know the contents of any information
exchanged. Ex. 1002 at p. 69, 4.4.
Thus, upon receipt of an S-HTTP compliant request from the user
agent for information stored on an origin server, the client-side proxy would
automatically establish a C-HTTP connection with the server-side proxy, as
described above, and the exchange of the S-HTTP messages would ensure

40

end-to-end encryption between the user agent and origin server. See Ex.
1003, 35. If, on the other hand, the user agent is requesting information
from a non-secure server outside the C-HTTP network that does not
implement S-HTTP, the user agent would communicate using standard
HTTP. See Ex. 1004 at 1.1 (S-HTTP supports interoperation among a
variety of implementations, and is compatible with HTTP. S-HTTP aware
clients can communicate with S-HTTP oblivious servers and vice-versa,
although such transactions obviously would not use S-HTTP security
features.); see also Ex. 1003, 35.
Based on the motivation provided in Kiuchi, it would have been an
obvious design choice to one of ordinary skill in the art to incorporate the
cryptography provided by Secure HTTP, as taught by Rescorla, into
Kiuchis user agent and origin server, in order to provide end-to-end
encryption and personal-level security. See Ex. 1003, 36. Therefore,
Kiuchi (which discloses an encrypted/secure C-HTTP connection from the
client-side proxy to the server-side proxy) in view of Rescorla (which
discloses encrypted/secure end-to-end communications between the user
agent and origin server) discloses an encrypted/secure channel that starts at
the user agent (acting as a client) and ends at the origin server (a secure
server). See Ex. 1003, 36.

41

C. [GROUND 3] KIUCHI IN VIEW OF RFC 1034 RENDERS

OBVIOUS CLAIMS 1, 2, 6-8, AND 12-14
Claims 1, 2, 6-8, and 12-14 are anticipated by Kiuchi for the reasons
set forth in V.A.1 to V.A.5, above. However, the Patent Owner has
made, and will likely continue to make, various claim-construction-based
arguments that Kiuchi does not anticipate because the allegedly wrong
network entity within Kiuchis architecture has responsibility for a given
task. See, e.g., Ex. 1007 (IPR2014-610 Patent Owners Preliminary
Response), pp. 5-7. While the PTAB has, to-date, correctly rejected such
arguments (see, e.g., Ex. 1011, pp. 11-12), even if accepted such arguments
would not make the Challenged Claims patentable.
It was well known to those of skill in the art that the responsibilities
for various tasks within a DNS could be distributed among network entities.
RFC 1034 describes two approaches for doing so. See Ex. 1003, 37-43.
RFC 1034 discloses a name server that answers standard queries in either a
so-called recursive mode or iterative mode. Ex. 1003, 21; Ex. 1005, p. 4.
In iterative mode, the server is unable to provide an answer to the request
and refers to some other server closer to the answer. Id. In recursive
mode, the server returns either an error or the answer, but never referrals.
Id.

42

As explained in further detail below, obvious modifications to Kiuchi

according to the well-known approaches of RFC 1034 would result in a
system that is nearly identical to the preferred embodiment described in the
151 specification and renders the challenged claims obvious under any
proposed claim interpretations.
Overview of Kiuchi and RFC 1034
Section V.A describes the details of Kiuchis C-HTTP system. As
described with regard to Diagram 3, Kiuchi teaches that, after the user
selects a hyperlink, the C-HTTP system performs the following steps: (1) a
request sent from the user agent to the client-side proxy for the selected
URL; (2) a request to the C-HTTP name server for an IP address
corresponding to the hostname included in the selected URL; and (3) a
response from the C-HTTP name server that either includes the IP address
associated with the server-side proxy or an error message. See Ex. 1003,
18. If the C-HTTP server returns an error message, then the client-side proxy
performs a DNS lookup using the standard/public DNS. See Ex. 1002, p. 65,
2.3; Ex. 1003, 23-24. The process by which the client-side proxy
resolves the hostname included in the selected URL may be referred to as
the iterative approach to resolving a hostname: if a particular name server
is presented with a query that can only be answered by some other server,

43

rather than itself resolving the query, the server lets the client pursue the
query Ex. 1005 (RFC 1034), p. 4. However, there is another general
approach to hostname resolution that may be referred to as the recursive
approach. See Ex. 1005, p. 4; see also Ex. 1003, 38. In the recursive
approach, if a particular name server is presented with a query that can only
be answered by some other server, the first server pursues the query for the
client at another server. Ex. 1005, p. 4; see also Ex. 1003, 38. It would
have been obvious to one of ordinary skill in the art to modify the client-side
proxy and C-HTTP name server of Kiuchi to implement this alternative
recursive approach. See Ex. 1003, 38-40. Specifically, a person of
ordinary skill in the art would have recognized that the standard/public DNS
lookup step performed by the client-side proxy in response to receiving an
error message from the C-HTTP name server could instead be performed by
the C-HTTP name server. See id.
Such a modification of Kiuchis client-side proxy and C-HTTP name
server would have been a straightforward design choice based on the
guidance in RFC 1034. See Ex. 1003, 40. On pages 21 and 22, RFC 1034
outlines the manner in which a name server may implement a recursive
resolution process. See id. Applied to the client-side proxy and C-HTTP
name server, the C-HTTP name server could be configured to first determine

44

whether a host name for which resolution is sought by the client-side proxy
is registered as part of the C-HTTP closed network. See id. If it is, the CHTTP name server will return the IP address, encryption key, and Nonce
values as described by Kiuchi. See id. However, if the hostname being
resolved is not part of the C-HTTP closed network, the C-HTTP name server
would make a query for the hostname to a standard/public DNS server on
the client-side proxys behalf. See id. If the C-HTTP name server is able to
resolve the hostname through this standard DNS query, it would return the
IP address to the client-side proxy. See id. Otherwise, the C-HTTP name
server would return an error. See id.
The client-side proxy would be modified to recognize the difference
between a response from the C-HTTP name server corresponding to a secure
destination within the C-HTTP network and a standard destination resolved
through the conventional DNS. See Ex. 1003, 41. For example, a C-HTTP
name service response message containing an IP address without a public
key and Nonce values (e.g., using values of zero or other convention for the
public key and Nonce fields, or modifying the protocol to use a previously
unused flag in the response to indicate that a public key and Nonce values
are not provided) could indicate to the client-side proxy that the DNS
request is not requesting access to a secure target web site and hence that no

45

VPN is needed. See id.

These types of modifications to the client-side proxy and C-HTTP
name server were well within the ability of a person of ordinary skill in the
art by 1996. See Ex. 1003, 42.
One of ordinary skill in the art would have been motivated to modify
Kiuchi in this way, because doing so would streamline the operation of the
system, as contemplated by RFC 1034. See Ex. 1003, 43. For example,
instead of having the C-HTTP name server send an error status to the clientproxy, which would in turn initiate a standard/public DNS inquiry, the
modification eliminates the error status message from the process by having
the C-HTTP name server directly initiate the request to the standard/public
DNS server. See id. Moreover, as described in RFC 1034, employing the
recursive mode of name resolution is the simplest mode for the client. Ex.
1005, p. 21; see also Ex. 1003, 47.
1.

KIUCHI IN VIEW OF RFC 1034 RENDERS OBVIOUS

CLAIM 1

The combination of Kiuchi and RFC 1034 discloses [a] data

processing device, comprising memory storing a domain name server (DNS)
proxy module that intercepts DNS requests sent by a client, as recited in
claim 1. See Ex. 1003 at 18, 20-21. As described above, Kiuchi explains

46

that, if a request by a user agent does not correspond to a domain name of

another member of the C-HTTP network, the client-side proxy performs a
conventional DNS lookup request. See Ex. 1002 at 65, 2.3(2). In this
instance, the function of DNS proxy is distributed across the client-side
proxy and the C-HTTP name server. Alternatively, a person of ordinary skill
in the art would have recognized that this conventional DNS lookup step
could also be implemented by making a simple adaptation of the C-HTTP
name server shown in Kiuchi, and that person would know how to do that
based on the guidance in RFC 1034. Specifically, the C-HTTP name server,
which already performs a DNS look-up for secure pages, could be modified
to also perform a DNS look-up for non-secure pages. Ex. 1003, 37-44.
In particular, as described above, Kiuchis client-side proxy receives a
request from the user agent that includes a URL with a hostname. Ex. 1002,
p. 65, 2.3; see also Ex. 1003, 18, 20-21. In response, the client-side
proxy sends a request to the C-HTTP name server asking 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 to the client-side
proxy. Ex. 1002, p. 65, 2.3. The request from the client-side proxy
therefore requests the IP address corresponding to the hostname.

47

In this case, the requested hostname is a domain name, under that

terms broadest reasonable interpretation, because the hostname corresponds
to an IP address. The client-side proxy is a client, under that terms
broadest reasonable interpretation, because the client-side proxy is a
computer or program from which a data request to a server is generated. The
request from the client-side proxy sent to the C-HTTP server is a DNS
request under either of the interpretations noted in IV.C.2, because the
request is a request for a resource (the IP address) corresponding to a domain
name (the hostname).
The combination of Kiuchi and RFC 1034 discloses the DNS proxy
module performing the step of determining whether the intercepted DNS
request corresponds to a secure server, as recited in claim 1. For example,
as described above, the C-HTTP server receives a request from the clientside proxy, and the request includes a hostname. Ex. 1002, p. 65, 2.3. In
some instances, the hostname corresponds to an origin server associated with
a server-side proxy and designates the server-side proxy. See Ex. 1002, p.
65, 2.3; see also Ex. 1003, 22.
The origin server is a secure server, under that terms broadest
reasonable interpretation as well as the narrower interpretation proposed by
the Patent Owner because authorization is needed to access the origin server

48

and the origin server can communicate in an encrypted channel. In

particular, as described above, before the server-side proxy will accept a
client-side proxys request for connection, the server-side proxy asks the CHTTP name server whether the client-side proxy is an appropriate member
of the closed network and, in response, the C-HTTP name server examines
whether the client- side proxy is permitted to access to the server-side
proxy. Ex. 1002, pp. 65-66, 2.3; see also Ex. 1003, 27-28. If the CHTTP server determines that access is permitted, the C-HTTP name server
sends the IP address and public key of the client-side proxy and both request
and response Nonce values, which are used to establish the C-HTTP
connection. Ex. 1002, p. 66, 2.3. As described above, the C-HTTP
connection is an encrypted channel that allows communications between the
user agent and the origin server. See Ex. 1003, 31. Accordingly,
authorization is required to establish the C-HTTP connection and therefore
access the origin server, and the C-HTTP connection is an encrypted channel
in which the origin server can communicate. As such, the origin server is a
secure server under both the broadest reasonable interpretation and the
narrower interpretation proposed by the Patent Owner.
Furthermore, the C-HTTP name server determines whether the
request from the client-side proxy corresponds to a secure server. See Ex.

49

1003, 26. In particular, when the C-HTTP server receives the request from
the client-side proxy, the C-HTTP name server first authenticates the clientside proxy to determine if the request is legitimate. Ex. 1002, p. 65, 2.3. If
the request is legitimate, the C-HTTP name server determines whether the
request corresponds to a secure server by determining whether the
requested server-side proxy [associated with the hostname] is registered in
the closed network. Id.
The combination of Kiuchi and RFC 1034 discloses the DNS proxy
module performing the step of 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, as recited in
claim 1. Ex. 1003 39-41. For example, as described above, in the
combination of Kiuchi and RFC 1034, if the C-HTTP server determines that
the requested URL specifies a non-secure destination (that is, the host
corresponding to the domain name is not in the closed network), then the CHTTP name server forwards the request to a standard/public DNS server.
See Ex. 1002, p. 65, 2.3; see also Ex. 1003, 40. The standard/public DNS
server would return an IP address corresponding to the hostname in the URL
to the C-HTTP name server, which would in turn return the IP address to the
client-side proxy. Id.

50

The combination of Kiuchi and RFC 1034 discloses the DNS proxy
module performing the step of when the intercepted DNS request
corresponds to a secure server, automatically initiating an encrypted channel
between the client and the secure server, as recited in claim 1. For example,
as described above, Kiuchi describes that, if the C-HTTP server determines
that the query request corresponds to a secure destination, then the C-HTTP
server provides the client-side proxy with the IP address and public key of
the server-side proxy and both request and response Nonce values for a
secure C-HTTP session. Ex. 1002, p. 65, 2.2-2.3; see also Ex. 1003,
23, 40. In response to receiving this information, the client-side proxy sends
a request for connection to the server-side proxy. See id. After receiving the
request, the server-side proxy asks the C-HTTP name server whether the
client-side proxy is an appropriate member of the closed network and, in
response, the C-HTTP name server examines whether the client-side proxy
is permitted to access to the server-side proxy. Ex. 1002, pp. 65-66, 2.3;
see also Ex. 1003, 28. If the C-HTTP server determines that access is
permitted, the C-HTTP name server sends the IP address and public key of
the client-side proxy and both request and response Nonce values. Ex.
1002, p. 66, 2.3.
After the C-HTTP name server provides both client-side and server-

51

side proxies with each peer's public key, the proxies establish a C-HTTP
connection. Ex. 1002 p. 66, 2.3; see Ex. 1003, 29. The C-HTTP
connection provides [a] secure HTTP communication mechanisms in
which communications over the C-HTTP connection are encrypted, Ex.
1002, pp. 64-66, Abstract.
As a result, by returning the IP address of the server-side proxy, the
public key of the server-side proxy, and Nonce values, the C-HTTP name
server initiates an encrypted channel from the client-side proxy to the serverside proxy, which in turn is connected to the origin server. See Ex. 1003,
29, 31. Furthermore, this process is performed without the involvement of a
user. See Ex. 1003, 30. As such, this channel is automatically initiated,
under that terms broadest reasonable interpretation and the narrower
interpretation proposed by the Patent Owner. See Ex. 1003, 29, 31.
Therefore, Kiuchi discloses that the C-HTTP server automatically initiates
an encrypted channel between the client-side proxy (acting as a client) and
the origin server (a secure server).
2.

KIUCHI IN VIEW OF RFC 1034 RENDERS OBVIOUS

CLAIM 7

The combination of Kiuchi and RFC 1034 discloses a computer

readable medium comprised of computer readable instructions that, when

52

executed cause a data processing device to perform the steps specified by

those instructions, as recited in claim 7. See Ex. 1002, p. 65, 2.2. In
particular, the C-HTTP server described in Kiuchi contains computer
readable instructions that cause the C-HTTP server to implement the CHTTP protocol. See Ex. 1002, p. 65, 2.2 (When a given institution wants
to participate in a closed network, it must 1) install a client-side and/or
server-side proxy on its firewall . . . .).
Steps (ii), (iii), and (iv) of claim 7 are identical to steps (i), (ii), and
(iii) of claim 1. As explained in V.C.1, above, the combination of Kiuchi
and RFC 1034 describes systems that comprise steps (ii), (iii), and (iv) of
claim 7. Claim 7 further specifies the step of (i) intercepting a DNS request
sent by a client. As explained in V.C.1, above, Kiuchi describes that the
C-HTTP name server receives a request sent by the client-side proxy. See
Ex. 1002, p. 65, 2.3. As explained in V.C.1, this request is a DNS
request. Thus, the combination of Kiuchi and RFC 1034 shows (i)
intercepting a DNS request sent by a client. See Ex. 1003 20-21. The
combination of Kiuchi and RFC 1034 therefore describes all the elements
specified in claim 7, and renders obvious this claim.
3.

KIUCHI IN VIEW OF RFC 1034 RENDERS OBVIOUS

CLAIM 13

53

The combination of Kiuchi and RFC 1034 discloses a computer

readable medium storing a domain name server (DNS) module comprised of
computer readable instructions that, when executed cause a data processing
device to perform the steps of, as recited in claim 13. See Ex. 1002, p. 65,
2.2. In particular, the C-HTTP server described in Kiuchi contains computer
readable instructions that cause the C-HTTP server to implement the CHTTP protocol, which was described in V.C.1, above. Id.
As explained in V.C.1, the combination of Kiuchi and RFC 1034
discloses (i) determining whether a DNS request sent by a client
corresponds to a secure server and (ii) when the 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; as recited in
claim 13. Ex. 1003 39-41.
The combination of Kiuchi and RFC 1034 also discloses (iii) when
the intercepted DNS request corresponds to a secure server, automatically
creating a secure channel between the client and the secure server, as
recited in claim 13. As explained in V.C.1, Kiuchi describes that, if the CHTTP server determines that the query request corresponds to a secure
destination, then the C-HTTP server provides the client-side proxy with the
IP address and public key of the server-side proxy and both request and

54

response Nonce values for a secure C-HTTP session. Ex. 1002, p. 65,
2.2-2.3; see also Ex. 1003, 26-28. In response to receiving this
information, the client-side proxy sends a request for connection to the
server-side proxy. See id. After receiving the request, the server-side proxy
asks the C-HTTP name server whether the client-side proxy is an
appropriate member of the closed network and, in response, the C-HTTP
name server examines whether the client-side proxy is permitted to access
to the server-side proxy. Ex. 1002, pp. 65-66, 2.3; see Ex. 1003, 27-28.
If the C-HTTP server determines that access is permitted, the C-HTTP
name server sends the IP address and public key of the client-side proxy and
both request and response Nonce values. Ex. 1002, p. 66, 2.3.
After the C-HTTP name server provides both client-side and serverside proxies with each peer's public key, the proxies establish a C-HTTP
connection. Ex. 1002 p. 66, 2.3. The C-HTTP connection provides [a]
secure HTTP communication mechanisms in which communications over
the C-HTTP connection are encrypted Ex. 1002, pp. 64-66, Abstract.
As a result, by returning the IP address of the server-side proxy, the
public key of the server-side proxy, and Nonce values, the C-HTTP server
creates a secure channel from the client-side proxy to the server-side proxy,
which in turn is connected to the origin server. See Ex. 1003, 29, 31.

55

Furthermore, this process is performed without the involvement of a user.

See Ex. 1003, 30. As such, this channel is automatically created, under that
terms broadest reasonable interpretation and the narrower interpretation
proposed by the Patent Owner. Therefore, Kiuchi discloses that the C-HTTP
server automatically creates a secure channel between the client-side proxy
(acting as a client) and the origin server (a secure server).
4.

KIUCHI IN VIEW OF RFC 1034 RENDERS OBVIOUS

CLAIMS 2, 8, AND 14

Claims 2, 8, and 14 depend from claims 1, 7, and 13, respectively, and

further specify wherein step (iii) comprises the steps of: (a) determining
whether the client is authorized to access the secure server; and (b) when the
client is authorized to access the secure server, sending a request to the
secure server to establish an encrypted[/secure] channel between the secure
server and the client. For the same reasons explained in V.A.4, above, the
combination of Kiuchi and RFC 1034 discloses these features.
5.

KIUCHI IN VIEW OF RFC 1034 RENDERS OBVIOUS

CLAIMS 6 AND 12

Claims 6 and 12 depend from claims 1 and 7, respectively, and further

specify wherein automatically initiating the encrypted channel between the
client and the secure server avoids sending a true IP address of the secure
server to the client. For the same reasons explained in V.A.5, above, the
56

combination of Kiuchi and RFC 1034 discloses these features.

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
As noted above, claims 1, 2, 6-8, and 12-14 are anticipated by Kiuchi.
In the alternative, Petitioner has proposed Grounds 2 and 3, noting that if
particular narrower claim interpretation arguments by the Patent Owner were
accepted the Challenged Claims would be obvious in view of Kiuchi
combined with either Rescorla or RFC 1034 for the reasons set forth in
V.B.1 to V.C.5, above. However, even if multiple narrow claim
interpretations advocated by the Patent Owner were simultaneously adopted,
it still would not make the Challenged Claims patentable.
As noted in the accompanying declaration of Dr. Roch Guerin, the
obvious modifications to Kiuchi in light of Rescorla are compatible with the
modifications to Kiuchi in light of RFC 1034. See Ex. 1003, 37-44.
Specifically, it would have been obvious to simultaneously make the
modifications in light of Rescorla resulting in end-to-end encryption and the
modifications in light of RFC 1034 making the C-HTTP name server
recursive so that it can handle both queries for secure and non-secure
servers. See Ex. 1003, 44. Such a combination would render all of the
challenged claims obvious even if all of the claim interpretation arguments

57

advocated by the Patent Owner were adopted.

VI. CONCLUSION
The cited prior art references identified in this petition contain
pertinent technological teachings, either explicitly or inherently disclosed,
which were not previously considered in the manner presented herein, or
relied upon during original examination of the 151 patent.
In sum, these references provide new, non-cumulative technological
teachings which indicate a reasonable likelihood of success as to Petitioners
assertion that the Challenged Claims of the 151 patent are not patentable
pursuant to the grounds presented in this Petition. Accordingly Petitioner
respectfully requests institution of an IPR for those claims of the 151 patent
for each of grounds presented herein.

58