`
`limitations of claim 1.
`
`Step (1) of Claim 1 - When the client-side proxy (i.e., the (cid:5)client computer(cid:6))
`
`receives the HTTP request from the user agent, it generates (and transmits) a DNS
`
`request that is sent to the C-HTTP name server in the form of a C-HTTP name
`
`service request to ask the C-HTTP name server whether it can communicate with
`
`the specified host. (Ex.1002 at 65, sec. 2.3(2)). The C-HTTP name service request
`
`is a (cid:5)DNS request(cid:6) because it is a communication that contains a domain name
`
`(i.e., the hostname from the URL in the HTTP request) and requests an IP address
`
`for the domain name. Because the domain name sent in the DNS request is the
`
`hostname given to the server-side proxy, the domain name is literally (cid:5)associated
`
`with the target computer(cid:6) as required by the claim. Therefore, the DNS request
`
`(cid:5)requests an IP address corresponding to a domain name associated with the target
`
`computer(cid:6) as required by step (1). The client-side proxy is a (cid:5)client computer(cid:6)
`
`because it is a computer from which the DNS request is generated and transmitted.
`
`Step (2) of Claim 1 - Upon receiving the C-HTTP name service request (i.e.,
`
`DNS request) from the client-side proxy, the C-HTTP name server (cid:5)examines
`
`whether the requested server-side proxy is registered in the closed network.(cid:6)
`
`(Ex.1002 at 65, sec. 2.3(2)). The C-HTTP name server determines whether the
`
`DNS request transmitted by the client-side proxy in step (1) is requesting access to
`
`
`
`Page 36 of 67
`
`29
`
`VIRNETX EXHIBIT 2019, Part 2
`New Bay Capital v. Virnetx
`Case IPR2013-00377
`
`
`
`a secure web site based on whether the requested server-side proxy is registered in
`
`the closed network. The C-HTTP name server determines that access is being
`
`requested to a secure web site being proxied by the server-side proxy (i.e., that
`
`access is being requested to a (cid:5)secure web site(cid:6)/(cid:5)secure target web site(cid:6)) and sends
`
`a C-HTTP name service response to the client-side proxy containing (cid:5)the IP
`
`address and public key of the server-side proxy and both request and response
`
`Nonce values(cid:6) (Ex.1002 at 65, sec. 2.3(2)), if the requested server-side proxy is
`
`registered in the closed network. The C-HTTP name server determines that access
`
`is not being requested to a secure web site and sends (cid:5)a status code which indicates
`
`an error,(cid:6) if the requested server-side proxy is not registered in the closed network.
`
`(Ex.1002 at 65, sec. 2.3(2)-(3)). Thus, step (2) of claim 1 is satisfied by the
`
`determination made by the C-HTTP name server.
`
`Additionally, step (2) of claim 1 is satisfied by a determination made by the
`
`client-side proxy based on the type of response received from the C-HTTP name
`
`server. In particular, the client-side proxy determines that access is being
`
`requested to a secure web site being proxied by the server-side proxy (i.e., that
`
`access is being requested to a (cid:5)secure target web site(cid:6)), only if a C-HTTP name
`
`service response is returned, and determines that access is not being requested to a
`
`secure web site, if the response is an error status status.
`
`
`
`Page 37 of 67
`
`30
`
`
`
`Step (3) of Claim 1 - As discussed above for step (2), if the C-HTTP name
`
`server determines that the requested server-side proxy is registered in the closed
`
`network and therefore determines that access is being requested to a secure target
`
`web site, the C-HTTP name server sends a C-HTTP name service response to the
`
`client-side proxy. The sending of the C-HTTP name service response by the C-
`
`HTTP name server to the client-side proxy constitutes (cid:5)automatically initiating the
`
`VPN(cid:6) within the context of the claim because the C-HTTP name service response
`
`causes the client-side proxy to send a request for connection to the server-side
`
`proxy. (Ex.1002 at 65, sec. 2.3(3)). The (cid:3)135 Patent provides, as one example of
`
`automatically initiating the VPN, transmission of a message requesting that a VPN
`
`be created (see Ex.1001 at 38:30-33). The C-HTTP name service response is
`
`analogous because it is a message that causes the VPN to be created. Therefore,
`
`step (3) of claim 1 is satisfied by sending of the C-HTTP name service response
`
`message to the client-side proxy in response to determining that the DNS request is
`
`requesting access to a secure target web site.
`
`Additionally, step (3) of claim 1 is satisfied by actions taken by the client-
`
`side proxy to automatically initiate the VPN. In response to receiving a C-HTTP
`
`name service response (which the client-side proxy uses to determine that the DNS
`
`request is requesting access to a secure target web site), the client-side proxy
`
`(cid:5)sends a request for connection to the server-side proxy, which is encrypted using
`
`
`
`Page 38 of 67
`
`31
`
`
`
`the server-side proxy(cid:8)s public key and contains the client-side proxy(cid:8)s IP address,
`
`hostname, request Nonce value and symmetric data exchange key for request
`
`encryption.(cid:6) (Ex.1002 at 65, section 2.3(3)). This connection request sent by the
`
`client-side proxy also meets step (3) of claim 1.
`
`Ground 2. Claim 3 is Anticipated by Kiuchi
`
`As set forth in Ex.1009 (cid:9) 40 and Appendix C, Kiuchi also discloses all of the
`
`limitations of claim 3. In response to determining that the requested server-side
`
`proxy is not registered in the closed network (which indicates that the DNS request
`
`is not requesting access to a secure target web site), the C-HTTP name server
`
`returns to the client-side proxy (cid:5)a status code which indicates an error.(cid:6) (Ex.1002
`
`at 65, sec. 2.3(2)). In turn, (cid:5)[i]f the client-side proxy receives an error status, then
`
`it performs DNS lookup, behaving like an ordinary HTTP/1.0 proxy.(cid:6) (Ex.1002 at
`
`65, sec. 2.3(2)). It is well-known that such a DNS lookup involves sending a
`
`request to a DNS server and receiving an IP address back from the DNS server.
`
`(Ex.1010 at 70 et seq.). In this way, the domain name is resolved and the IP
`
`address is returned to the client-side proxy, specifically by the client-side proxy
`
`sending a lookup request to the conventional DNS server which resolves the
`
`domain name and returns the IP address to the client-side proxy. Thus, Kiuchi
`
`teaches the limitations of claim 3.
`
`Ground 3. Claim 7 is Anticipated by Kiuchi
`
`
`
`Page 39 of 67
`
`32
`
`
`
`As set forth in Ex.1009 (cid:9)(cid:9) 41-43 and Appendix C, Kiuchi also discloses all
`
`of the limitations of claim 7 in at least the following two ways:
`
`Gatekeeper Computer Functions Implemented in C-HTTP Name Server
`
`The (cid:8)135 Patent makes clear that the gatekeeper can be implemented as a
`
`function within the DNS server (see Ex.1001 at 38:53-55). As discussed under
`
`Ground 1, the C-HTTP name server is a DNS server that performs the step of
`
`(cid:5)automatically initiating the VPN(cid:6) by sending the C-HTTP name service response
`
`to the client-side proxy. In this context, the C-HTTP name server also performs
`
`the functions of a gatekeeper computer because it allocates VPN resources, e.g., it
`
`generates and provides the request and response Nonce values and returns the
`
`public key of the server-side proxy and the request and response Nonce values to
`
`the client-side proxy. (Ex.1002 at 65, sec. 2.2).
`
`Gatekeeper Computer Functions Implemented in Server-Side Proxy
`
`Additionally, as discussed under Ground 1, Kiuchi(cid:8)s client-side proxy
`
`performs the step of (cid:5)automatically initiating the VPN(cid:6) by sending a request for
`
`connection to the server-side proxy. In this context, the server-side proxy also
`
`performs the functions of a gatekeeper computer because it allocates VPN
`
`resources such as a Connection ID and a second symmetric data exchange key that
`
`are used in establishing a secure connection between the client-side proxy and the
`
`server-side proxy. (see Ex.1002 at 66, sec. 2.3(5)). Under the broadest reasonable
`
`
`
`Page 40 of 67
`
`33
`
`
`
`interpretation, the gatekeeper computer can be a function in the target computer.
`
`Furthermore, similar to the gatekeeper in the (cid:3)135 Patent, the server-side proxy
`
`receives a request for a VPN to be created (i.e., the request for connection from the
`
`client-side proxy) and effectively controls the creation of the VPN. Specifically, in
`
`the (cid:3)135 Patent, the gatekeeper may receive a request from the DNS proxy
`
`requesting that a VPN be created. (Ex.1001 at 38:30-33). Similarly, Kiuchi(cid:8)s
`
`server-side proxy receives a request for connection from the client-side proxy.
`
`(Ex.1002 at 65, sec. 2.3(4)). In order to create the VPN, the server-side proxy (i.e.,
`
`the gatekeeper) has to accept the request for connection from the client-side proxy,
`
`authenticate the client-side proxy, check the integrity of the Nonce values, and
`
`generate a connection ID and other parameters for the VPN (Ex.1002 at 65(4)-
`
`66(5)). The generation of the connection ID and second symmetric data exchange
`
`key by the server-side proxy is a further example of a gatekeeper computer
`
`function implemented in the server-side proxy.
`
`Ground 4. Claim 8 Would Have Been Obvious in view of Kiuchi
`
`As discussed in Ground 1, the C-HTTP name server performs the step of
`
`(cid:5)determining.(cid:6) As set forth in Ex.1009 (cid:9)(cid:9) 44-47 and Appendix C, it would have
`
`been apparent to a person of ordinary skill in the art as a mere design choice to
`
`consolidate domain name resolution functions in Kiuchi(cid:8)s C-HTTP name server.
`
`Kiuchi clearly recognizes and discloses that a conventional DNS lookup for the
`
`
`
`Page 41 of 67
`
`34
`
`
`
`domain name is needed when access is not being requested to a secure target web
`
`site, i.e., when the requested server-side proxy is not registered in the closed
`
`network. (Ex.1002 at 65, sec. 2.3(2)). This is identical to the (cid:3)135 Patent, where a
`
`DNS lookup is performed when access is not being requested to a secure target
`
`web site. (ex.1001 at 38:43-47).
`
`Kiuchi defines three new components for the system, namely the client-side
`
`proxy, the server-side proxy, and the C-HTTP name server. (Ex.1002 at 64, sec.
`
`2.1). While Kiuchi describes a system in which a conventional DNS lookup
`
`request is made from the client-side proxy, it would have been apparent to a person
`
`of ordinary skill in the art based on Kiuchi(cid:8)s teachings to make the conventional
`
`DNS lookup request from the C-HTTP name server. As discussed in Ground 1,
`
`the C-HTTP name server already determines whether the DNS request received
`
`from the client-side proxy is requesting access to a secure target web site. Rather
`
`than returning an error status to the client-side proxy when the DNS request is not
`
`requesting access to a secure target web site, it would have been trivial and obvious
`
`as a mere design choice for the C-HTTP name server to pass the domain name
`
`received in the C-HTTP name service request to the conventional DNS server, as
`
`depicted in the following Figure:
`
`
`
`Page 42 of 67
`
`35
`
`
`
`
`
`Such a configuration, which places a DNS proxy server function in a
`
`modified C-HTTP name server (similar to placement of the DNS proxy server
`
`function of the (cid:3)135 patent in the DNS server (cid:2) see Ex.1001 at FIG. 26), is merely
`
`a rearrangement of existing functions within the C-HTTP system and could be
`
`implemented with or without modifying Kiuchi(cid:8)s protocols. 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)
`
`
`
`Page 43 of 67
`
`36
`
`
`
`would indicate to the client-side proxy that the DNS request is not requesting
`
`access to a secure target web site and hence that no VPN is needed. The
`
`motivation for modifying Kiuchi in this way would have been to streamline the
`
`operation of the system, e.g., instead of having the C-HTTP name server send an
`
`error status to the client-proxy which would in turn initiate a conventional 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 conventional
`
`DNS server. Thus, the combination of claim 8 is obvious in view of Kiuchi. See
`
`KSR Intern. Co. v. Teleflex Inc., 550 U.S. 398, 401; 127 S.Ct. 1727, 173 (2007) ((cid:5)a
`
`combination of familiar elements according to known methods is likely to be
`
`obvious when it does no more than yield predictable results(cid:6)); Sakraida v. Ag Pro,
`
`Inc., 425 U.S. 273, 282, 96 S.Ct. 1532 (1976) (when a patent (cid:5)simply arranges old
`
`elements with each performing the same function it had been known to perform(cid:6)
`
`and yields no more than one would expect from such an arrangement, the
`
`combination is obvious).
`
`C. Request 2 (cid:3) Claims 1, 3, 7 and 8 are Anticipated by Kiuchi
`
`A careful consideration of the inner workings of the client-side proxy reveals
`
`that Kiuchi(cid:8)s client-side proxy performs a (cid:5)resolver(cid:6) function that receives a
`
`domain name resolution request from an internal client (in this case, the domain
`
`name extracted from the received HTTP request) and returns an IP address for the
`
`
`
`Page 44 of 67
`
`37
`
`
`
`domain name. (Ex.1009 (cid:9) 49). Petitioner presents the following Figure 4 to
`
`schematically show the resolver and client functions in the client-side proxy:
`
`
`
`As discussed above with reference to construction of (cid:5)Domain Name
`
`Service (DNS) request,(cid:6) resolver functions were known in the art well before the
`
`(cid:3)135 Patent was filed. (Ex.1009 (cid:9) 50). Thus, in Kiuchi, an internal resolution
`
`request (which is a (cid:5)DNS request(cid:6) because it is a communication that contains a
`
`domain name and requests an IP address for the domain name) is made to the
`
`resolver function (which is a collection of software functions within the client-side
`
`proxy), which acts as a DNS proxy server to contact the C-HTTP name server and
`
`
`
`Page 45 of 67
`
`38
`
`
`
`optionally also the conventional DNS server to obtain an IP address for the domain
`
`name and return the IP address to the internal client. (Ex.1009 (cid:9) 51).
`
`Furthermore, a careful consideration of the inner workings of the client-side
`
`proxy also reveals that the resolver function performs functions that map directly
`
`to the functions performed by the DNS proxy server of the (cid:3)135 Patent. Ex.1009 (cid:9)
`
`52). The DNS proxy server of the (cid:3)135 Patent receives a DNS request, determines
`
`whether access to a secure web site has been requested (e.g., based on a domain
`
`name extension or by reference to an internal table of such sites), automatically
`
`initiates a VPN if access to a secure target web site has been requested, and passes
`
`through the DNS request to a conventional DNS server if access to a non-secure
`
`site had been requested (see Ex.1001 at 38:23-47). Similarly, the resolver function
`
`of Kiuchi receives a DNS request, determines whether access to a secure web site
`
`has been requested (based on a query to the C-HTTP name server, which
`
`essentially is just a remote table lookup similar to the internal table lookup of the
`
`(cid:3)135 Patent), automatically initiates a VPN if access to a secure target web site has
`
`been requested, and passes through the DNS request to a conventional DNS server
`
`if access to a non-secure site had been requested.
`
`Thus, Kiuchi(cid:8)s resolver function is a DNS proxy server because it is a
`
`computer or program that responds to a domain name inquiry in place of a DNS.
`
`Consequently, Kiuchi(cid:8)s client-side proxy effectively includes a Client Module and
`
`
`
`Page 46 of 67
`
`39
`
`
`
`a DNS Proxy Server Module, as shown in Figure 4. For purposes of the following
`
`analysis, the Client Module of the client-side proxy is the (cid:5)client computer,(cid:6) the
`
`server-side proxy is the (cid:5)target computer,(cid:6) and the DNS Proxy Server Module is a
`
`DNS Proxy Server in the client-side proxy. In response to receiving an HTTP
`
`request from the user agent, the Client Module sends the domain name from the
`
`URL (i.e., a (cid:5)DNS request(cid:6)) to the DNS Proxy Server Module. This domain name
`
`will be the hostname of the server-side proxy, if the HTTP request is directed to a
`
`secure target web site on the origin server. The DNS Proxy Server Module sends a
`
`request to the C-HTTP name server and performs the (cid:5)determining(cid:6) and
`
`(cid:5)automatically initiating(cid:6) steps based on the type of response received from the
`
`C-HTTP name server (which depends on whether the DNS request is requesting
`
`access to a secure target web site in the C-HTTP closed network). A VPN is
`
`automatically initiated between the client-side proxy and the server-side proxy if
`
`the DNS request is requesting access to a secure target web site.
`
`Ground 5. Claim 1 is Anticipated by Kiuchi
`
`As set forth in Ex.1009 (cid:9)(cid:9) 53-58 and Appendix D, Kiuchi discloses all of the
`
`limitations of claim 1.
`
`Step (1) of Claim 1 (Ex.1009 (cid:9) 53) - When the Client Module (i.e., the
`
`(cid:5)client computer(cid:6)) receives the HTTP request from the user agent, it extracts the
`
`hostname (i.e., domain name) from the URL received in the HTTP request and
`
`
`
`Page 47 of 67
`
`40
`
`
`
`sends an internal resolver request containing the domain name to the DNS Proxy
`
`Server Module. This internal resolver request is a (cid:5)DNS request(cid:6) because it is a
`
`communication that contains a domain name (i.e., the hostname from the URL in
`
`the HTTP request) and requests an IP address for the domain name. Because the
`
`domain name sent in the DNS request is the hostname given to the server-side
`
`proxy, the domain name is literally (cid:5)associated with the target computer(cid:6) as
`
`required by the claim. Therefore, the DNS request (cid:5)requests an IP address
`
`corresponding to a domain name associated with the target computer(cid:6) as required
`
`by step (1). The Client Module is a (cid:5)client computer(cid:6) because it is a program from
`
`which the DNS request is generated and transmitted.
`
`Step (2) of Claim 1 (Ex.1009 (cid:9)(cid:9) 54-56) - Upon receiving the DNS request
`
`from the Client Module, the DNS Proxy Server Module sends the domain name to
`
`the C-HTTP name server in the form of a C-HTTP name service request to ask the
`
`C-HTTP name server whether the client-side proxy can communicate with the
`
`specified host. (Ex.1002 at 65, sec. 2.3(2)). The C-HTTP name server (cid:5)examines
`
`whether the requested server-side proxy is registered in the closed network.(cid:6)
`
`(Ex.1002 at 65, sec. 2.3(2)). The C-HTTP name server determines whether the
`
`DNS request transmitted by the Client Module in step (1) is requesting access to a
`
`secure web site based on whether the requested server-side proxy is registered in
`
`the closed network. The C-HTTP name server determines that access is being
`
`
`
`Page 48 of 67
`
`41
`
`
`
`requested to a secure web site being proxied by the server-side proxy (i.e., that
`
`access is being requested to a (cid:5)secure web site(cid:6)/(cid:5)secure target web site(cid:6)) and sends
`
`a C-HTTP name service response to the DNS Proxy Server Module containing
`
`(cid:5)the IP address and public key of the server-side proxy and both request and
`
`response Nonce values(cid:6) (Ex.1002 at 65, sec. 2.3(2)), if the requested server-side
`
`proxy is registered in the closed network. The C-HTTP name server determines
`
`that access is not being requested to a secure web site and sends (cid:5)a status code
`
`which indicates an error,(cid:6) if the requested server-side proxy is not registered in the
`
`closed network. (Ex.1002 at 65, sec. 2.3(2)-(3)). Thus, step (2) of claim 1 is
`
`satisfied by the determination made by the C-HTTP name server.
`
`Additionally, step (2) of claim 1 is satisfied by a determination made by the
`
`DNS Proxy Server Module based on the type of response received from the C-
`
`HTTP name server. In particular, the DNS Proxy Server Module determines that
`
`access is being requested to a secure web site being proxied by the server-side
`
`proxy (i.e., that access is being requested to a (cid:5)secure target web site(cid:6)), only if a C-
`
`HTTP name service response is returned, and determines that access is not being
`
`requested to a secure web site, if the response is an error status.
`
`Step (3) of Claim 1 (Ex.1009 (cid:9)(cid:9) 57-58) - If the DNS Proxy Server Module
`
`receives a C-HTTP name service response from the C-HTTP name server and
`
`therefore determines that access is being requested to a secure target web site, the
`
`
`
`Page 49 of 67
`
`42
`
`
`
`DNS Proxy Server Module and/or the Client Module automatically initiates the
`
`VPN, specifically by the DNS Proxy Server Module sending the IP address and
`
`VPN resources (e.g., the public key and Nonce values) to the Client Module and
`
`the Client Module (cid:5)[sending] a request for connection to the server-side proxy,
`
`which is encrypted using the server-side proxy(cid:8)s public key and contains the client-
`
`side proxy(cid:8)s IP address, hostname, request Nonce value and symmetric data
`
`exchange key for request encryption.(cid:6) (Ex.1002 at 65, right column, section
`
`2.3(3)). In this regard, it should be noted that the (cid:3)135 Patent provides, as one
`
`example of automatically initiating the VPN, transmission of a message requesting
`
`that a VPN be created (see Ex.1001 at 38:30-33). Sending the IP address and VPN
`
`resources by the DNS Proxy Server Module to the Client Module is analogous
`
`because it is a message that causes the VPN to be created. Therefore, step (3) of
`
`claim 1 is satisfied by the DNS Proxy Server Module.
`
`Additionally or alternatively, step (3) of claim 1 is satisfied by actions taken
`
`by the Client Module to automatically initiate the VPN. In response to receiving
`
`the IP address, public key, and Nonce values, the Client Module (cid:5)sends a request
`
`for connection to the server-side proxy, which is encrypted using the server-side
`
`proxy(cid:8)s public key and contains the client-side proxy(cid:8)s IP address, hostname,
`
`request Nonce value and symmetric data exchange key for request encryption.(cid:6)
`
`
`
`Page 50 of 67
`
`43
`
`
`
`(Ex.1002 at 65, section 2.3(3)). This connection request sent by the Client Module
`
`also meets step (3) of claim 1.
`
`Ground 6. Claim 3 is Anticipated by Kiuchi
`
`As set forth in Ex.1009 (cid:9) 59 and Appendix D, Kiuchi also discloses all of
`
`the limitations of claim 3. In response to determining that the DNS request in step
`
`(2) is not requesting access to a secure target web site (i.e., in response to receiving
`
`the status code which indicates an error), the DNS Proxy Server Module performs
`
`a DNS lookup as (cid:5)an ordinary HTTP/1.0 proxy(cid:6) (Ex.1002 at 65, section 2.3(2))
`
`and returns an IP address to the Client Module. It is well-known that such a DNS
`
`lookup involves sending a request to a DNS server and receiving an IP address
`
`back from the DNS server. (Ex.1010 at 70 et seq.). In this way, the domain name
`
`is resolved and the IP address is returned to the client computer (i.e., Client
`
`Module), specifically by the DNS Proxy Server Module performing the DNS
`
`lookup (through a request to a conventional DNS) and returning the IP address to
`
`the Client Module. Thus, Kiuchi teaches the limitations of claim 3.
`
`Ground 7. Claim 7 is Anticipated by Kiuchi
`
`As set forth in Ex.1009 (cid:9) 60 and Appendix D, Kiuchi also discloses all of
`
`the limitations of claim 7. As discussed in Ground 5, Kiuchi(cid:8)s DNS Proxy Server
`
`Module and/or Client Module performs the step of (cid:5)automatically initiating the
`
`VPN(cid:6) by sending a request for connection to the server-side proxy. In this context,
`
`
`
`Page 51 of 67
`
`44
`
`
`
`the server-side proxy also performs the functions of a gatekeeper computer because
`
`it allocates VPN resources, such as a Connection ID and a second symmetric data
`
`exchange key, that are used in establishing a secure connection between the client-
`
`side proxy and the server-side proxy. (Ex.1002 at 66, section 2.3(5)). Under the
`
`broadest reasonable interpretation, the gatekeeper computer can be a function in
`
`the target computer.
`
`Furthermore, similar to the gatekeeper in the (cid:3)135 Patent, the server-side
`
`proxy receives a request for a VPN to be created and effectively controls the
`
`creation of the VPN. Specifically, in the (cid:3)135 Patent, the gatekeeper may receive a
`
`request from the DNS proxy requesting that a VPN be created. (Ex.1001 at 38:30-
`
`33). Similarly, Kiuchi(cid:8)s server-side proxy receives a request for connection from
`
`the client-side proxy. (Ex.1002 at 65, sec. 2.3(4)). In order to create the VPN, the
`
`server-side proxy (i.e., the gatekeeper) has to accept the request for connection
`
`from the client-side proxy, authenticate the client-side proxy, check the integrity of
`
`the Nonce values, and generate a connection ID and other parameters for the VPN
`
`(Ex.1002 at 65(4)-66(5)). The generation of the connection ID and second
`
`symmetric data exchange key by the server-side proxy is a further example of the
`
`gatekeeper computer function implemented in the server-side proxy.
`
`Ground 8. Claim 8 is Anticipated by Kiuchi
`
`
`
`Page 52 of 67
`
`45
`
`
`
`As set forth in Ex.1009 (cid:9) 59 and Appendix D, Kiuchi also discloses all of
`
`the limitations of claim 8. As discussed in Ground 5, the DNS Proxy Server
`
`Module determines whether the DNS request transmitted by the Client Module in
`
`step (1) is requesting access to a secure web site based on whether the C-HTTP
`
`name server returns the IP address and VPN resources (i.e., the public key of the
`
`server-side proxy and both request and response Nonce values) or returns a status
`
`code which indicates an error. Thus, step (2) is performed in a DNS proxy server
`
`as required by claim 8.
`
`Also, Kiuchi teaches that (cid:5)If a client-side proxy receives an error status, then
`
`it performs DNS lookup, behaving like an ordinary HTTP/1.0 proxy.(cid:6) (Ex.1002 at
`
`65, section 2.3, paragraph 2). Specifically, the DNS Proxy Server Module
`
`performs a DNS lookup in response to receiving the error status and hence
`
`performs a DNS lookup in response to determining that the DNS request is not
`
`requesting access to a secure target web site. A person of ordinary skill would
`
`have understood that Kiuchi's reference to performing a "DNS lookup ... like an
`
`ordinary HTTP/1.0 proxy" involves resolving a domain name into an IP address
`
`and returning the IP address to the client computer that requested it, specifically by
`
`forwarding the DNS request to the conventional DNS server, receiving an IP
`
`address from the DNS server, and returning the IP address to the Client Module.
`
`For example, RFC 1123 (Ex.1010) defines how computers on the Internet should
`
`
`
`Page 53 of 67
`
`46
`
`
`
`operate and states that when using domain names, "Host domain names MUST be
`
`translated to IP addresses as described in Section 6.1." (Ex.1010 at 13 (emphasis
`
`added).) Section 6.1, in turn, states that "Every host MUST implement a resolver
`
`for the Domain Name System (DNS), and it MUST implement a mechanism using
`
`this DNS resolver to convert host names to IP addresses and vice-versa." (ld. at
`
`72.). Thus, in response to determining that the DNS request in step (2) is not
`
`requesting access to a secure target web site, the DNS Proxy Server Module passes
`
`the domain name generated by the Client Module to the conventional DNS server
`
`and hence passes through the request to the conventional DNS server in order to
`
`perform the DNS lookup. Thus, Kiuchi teaches all the limitations of claim 8.
`
`D. Request 3 (cid:3) Claims 1, 3, 7 and 8 are Unpatentable over Dalton in
`view of Kiuchi
`
`Dalton was published in the Proceedings of JENC8, May 1997 and was
`
`republished in Computer Networks and ISDN Systems, Vol. 29, No. 15, November
`
`1, 1997 (pp. 1799-1808). (Exs.1003 and 1024). Thus, Dalton (like Kiuchi,
`
`discussed above) is prior art under 35 U.S.C. (cid:4)102(b).
`
`Prior to October 1998, use of the Internet was expanding exponentially.
`
`Organizations with multiple locations were moving away from costly private
`
`circuits for local communication to closed virtual private networks implemented on
`
`the Internet. (Ex.1009 (cid:9) 62). Kiuchi is just one of many references describing how
`
`to implement a closed network on the Internet. The (cid:3)135 patent concedes that in
`
`
`
`Page 54 of 67
`
`47
`
`
`
`the prior art, a (cid:5)tremendous variety of methods have been proposed and
`
`implemented to provide security and anonymity for communications over the
`
`Internet.(cid:6) (Ex. 1001, 1:15-17). The cost incentive to set up secure connections
`
`over the Internet instead of resorting to private leased circuits was a major factor in
`
`the shift to reliance on the Internet. (Ex.1009 (cid:9) 62).
`
`As discussed above, Kiuchi addressed the hospital space, recognizing that its
`
`technology was equally applicable for use by other institutions. Kiuchi explicitly
`
`explained the incentive to privately communicate over the Internet:
`
`The Internet is expected to become available to almost all major
`hospitals. Although a closed network can be constructed using a
`privately-leased circuit, additional investment for its construction is
`necessary. If a closed network can be constructed on the Internet, it
`would be convenient, speedy and reasonable in terms of cost. In
`addition, if a closed network is realized by privately leased circuits, it
`is not always easy to operate several closed networks flexibly and
`simultaneously.
`
`(Ex.1002 at 69, sec. 4.5, emphasis added)
`
`Kiuchi disclosed (cid:5)a closed HTTP-based virtual network [that] can be
`
`constructed for closed groups; for example, the headquarters and branches of
`
`a given corporation.(cid:6) (Ex. 1002, p. 69, sec. 5). Kiuchi re-emphasized the
`
`cost incentive for moving to the Internet: (cid:5)if resources which might
`
`otherwise be invested in private circuits are channeled into the Internet, it
`
`will contribute to its further development.(cid:6) Id.
`
`
`
`Page 55 of 67
`
`48
`
`
`
`Meanwhile, Dalton described a firewalled Domain Name System in a single
`
`machine, referred to as a Compartmented Mode Workstation (CMW), that
`
`provides a DNS service such that clients on an internal (closed) network can have
`
`access to both public and private hosts on the internal network as well as access to
`
`hosts on an external network, while hosts on the external network can have access
`
`to only public hosts on the internal network. (Ex.1009 (cid:9) 63). Dalton illustrates a
`
`simple example of the CMW-based system having two zones (i.e.,
`
`internal/protected and external/public) as follows (Ex.1003 at 711-4, Figure 2):
`
`
`
`As set forth in Ex.1009 (cid:9)(cid:9) 64-65, the CMW intercepts and processes DNS
`
`requests from external clients on the public Internet and internal clients on the
`
`closed, private Local Area Network (LAN). External clients are only permitted to
`
`access specific servers on the LAN. However, internal clients are permitted to
`
`access all servers on the LAN as well as servers on the Internet. When the CMW
`
`receives a DNS request from an internal client on the LAN, it determines whether
`
`
`
`Page 56 of 67
`
`49
`
`
`
`the DNS request is requesting access to an internal host on the LAN based on a set
`
`of DNS records maintained in the CMW. If the DNS request is requesting access
`
`to an internal host on the LAN, then the CMW can resolve the IP address locally,
`
`as represented by the arrow looping back to the LAN in the above figure.
`
`However, if the DNS request is requesting access to an external host on the
`
`Internet, then the CMW forwards the DNS request to a DNS server on the Internet,
`
`as represented by the arrow from the name service daemon in the (cid:5)INSIDE(cid:6) box to
`
`the (cid:5)OUTSIDE(cid:6) box in the above figure. Dalton makes clear that an internal host
`
`can be a World Wide Web (web) server (Ex.1003 at 711-3) and that a client can
`
`include a browser (Ex.1003 at 711-6). Thus, Dalton te