throbber
As set forth in Ex.1009 (cid:9)(cid:9) 29-39 and Appendix C, Kiuchi discloses all of the
`
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket