-
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 BoardPatent Trial and Appeal BoardUS Patent and
Trademark OfficePO Box 1450Alexandria, Virginia 22313-1450
-
i
TABLE OF CONTENTS
I. MANDATORY NOTICES UNDER 37 C.F.R 42.8(a)(1)
.................... 1A. Real Party-In-Interest Under 37 C.F.R.
42.8(b)(1) ........................... 1B. Related Matters Under 37
C.F.R. 42.8(b)(2)..................................... 1C. Lead And
Back-Up Counsel Under 37 C.F.R. 42.8(b)(3) ................ 2D.
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
..................... 3A. Grounds for Standing Under 37 C.F.R.
42.104(a) ............................ 3B. Challenge Under 37
C.F.R. 42.104(b) and Relief Requested ........... 3
IV.SUMMARY OF THE 151
PATENT....................................................... 5A.
Brief Description
..................................................................................
5B. Summary of the Prosecution History of the 151
Patent...................... 7C. Claim Construction under 37 C.F.R.
42.104(b)(3) ......................... 8
1. Domain
Name................................................................................
92. DNS Request
.................................................................................
93.
Determining.................................................................................
104. Secure
Server...............................................................................
135. Automatically
..............................................................................
146. Client
...........................................................................................
157. 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
...... 161. Kiuchi Anticipates Claim
1............................................................. 252.
Kiuchi Anticipates Claim
7............................................................. 323.
Kiuchi Anticipates Claim
13........................................................... 334.
Kiuchi Anticipates Claims 2, 8, and 14
.......................................... 355. 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
.......................................................................
37C. [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
............... 462. Kiuchi In View of RFC 1034 Renders Obvious
Claim 7 ............... 523. Kiuchi In View of RFC 1034 Renders
Obvious Claim 13 ............. 53
-
ii
4. Kiuchi In View of RFC 1034 Renders Obvious Claims 2, 8, and
1456
5. Kiuchi In View of RFC 1034 Renders Obvious Claims 6 and 12..
56D. [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
-
iii
EXHIBITS
Ex. 1001U.S. Patent No. 7,490,151 to Munger et al. (the "'151
Patent")
Ex. 1002
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")
Ex. 1003 Declaration of Dr. Roch Guerin
Ex. 1004E. Rescorla and A. Schiffman, The Secure Hypertext
Transfer Protocol, Internet Draft (Feb. 1996)
Ex. 1005Mockapetris, P., RFC 1034, "Domain NamesConcepts and
Facilities," Nov. 1997
Ex. 1006 Excerpts from the Prosecution History of the 151
Patent
Ex. 1007Patent Owner's Preliminary Response, Paper 7, in
IPR2014-00610
Ex. 1008Excerpts from Websters Third New International
Dictionary (1971)
Ex. 1009VirnetX's Reply Claim Construction Brief in VirnetX Inc.
v. Cisco Systems, Inc. et al., 6:10-cv-417 (Dec. 19, 2011) (E.D.
Tex.)
Ex. 1010Bradner, S., RFC 2026, The Internet Standards Process
Revision 3, Oct. 1996
Ex. 1011Decision to Institute Inter Partes Review, Paper 9, in
IPR2014-00610 (Oct. 15, 2014)
Ex. 1012Chatel, M., RFC 1919, Classical versus Transparent IP
Proxies, March 1996
Ex. 1013Fielding et al., RFC 2068, Hypertext Transfer Protocol
HTTP/1.1, Jan. 1997
Ex. 1014Berners-Lee et al., RFC 1945, "Hypertext Transfer
Protocol -- HTTP/1.0," May 1996
Ex. 1015 (Reserved)Ex. 1016 (Reserved)Ex. 1017 (Reserved)Ex.
1018 (Reserved)Ex. 1019 (Reserved)Ex. 1020 (Reserved)Ex. 1021
(Reserved)Ex. 1022 (Reserved)
-
iv
Ex. 1023 (Reserved)
Ex. 1024E. Rescorla and A. Schiffman, RFC 2660, The Secure
Hypertext Transfer Protocol, Aug. 1999
-
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-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.
-
2
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
-
3
Wiggin and Dana LLP450 Lexington AvenueNew York, NY 10017T:
212-551-2841Email: [email protected]
504 W. 136th St. #1BNew York, NY 10031T: 917-626-1356Email:
[email protected]
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 [email protected].
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
-
4
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 151 Patent Claims Basis for RejectionGround 1 1, 2, 6-8
and 12-14 Anticipated under 102 by Kiuchi
Ground 2 1, 2, 6-8 and 12-14 Obvious under 103 based on Kiuchi
in view of Rescorla
Ground 3 1, 2, 6-8 and 12-14 Obvious under 103 based on Kiuchi
in view of RFC 1034
Ground 4 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.
-
5
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,
-
6
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
-
7
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
-
8
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
-
9
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.
-
10
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
-
11
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
-
12
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
-
13
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
-
14
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
-
15
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
-
16
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
-
17
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.
-
18
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
-
19
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
-
20
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.
-
21
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
-
22
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;
-
23
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 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 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 client-
side proxy. See Ex. 1002, pp. 65-66, 2.3, steps 3-5; see also
Ex. 1003,
27.
-
24
Considering these steps in further detail, the client-side
proxy, in
response to receiving the IP address and associated information
from the C-
HTTP 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
-
25
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
server-
side 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 C-
HTTP 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
-
26
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
-
27
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 server-
side 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
-
28
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
-
29
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 server-
side 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 client-
side proxy behave[s] like an ordinary HTTP/1.0 proxy by
perform[ing]
-
30
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
-
31
receiving the request for connection from the client-side proxy,
the server-
side 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.
-
32
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
-
33
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 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, 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.
-
34
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
-
35
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
-
36
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 C-
HTTP 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
-
37
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 RESCORLARENDERS 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
-
38
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 (S-
HTTP) 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
-
39
combination through the following disclosure: [a]lthough the
current C-
HTTP 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 C-
HTTP 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/draft-
ietf-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
-
40
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 S-
HTTP 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
-
41
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.
-
42
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.
-
43
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,
-
44
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
-
45
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 C-
HTTP 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
-
46
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 client-
proxy, 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
-
47
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.
-
48
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 client-
side 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
-
49
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 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, 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, 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.
-
50
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 client-
side 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 C-
HTTP 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.
-
51
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-
-
52
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 server-
side 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
-
53
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 C-
HTTP 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
-
54
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 C-
HTTP 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 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
-
55
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
server-
side 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.
-
56
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
-
57
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
-
58
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.
