Documente Academic
Documente Profesional
Documente Cultură
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
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
Ex. 1023
Ex. 1024
(Reserved)
E. Rescorla and A. Schiffman, RFC 2660, The Secure
Hypertext Transfer Protocol, Aug. 1999
iv
Petitioner, The Mangrove Partners Master Fund, Ltd., is the real party-ininterest.
B.
BACKUP COUNSEL
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.
Ground 2
Ground 3
Ground 4
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.
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.
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
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
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
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
AUTOMATICALLY
14
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.
In prior litigation involving the 151 patent, the Patent Owner argued
that between should mean extend from one endpoint to the other, and
15
16
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
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
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.
PREAMBLE
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
32
PREAMBLE
33
c.
STEP (iii)
34
STEP (a)
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.
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
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
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
42
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
46
47
48
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.
52
53
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
57
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