`
`modified C-HTTP name server determines whether the requested host is a member
`
`of the closed network. If the requested host is a member of the closed network
`
`(i.e., a server-side proxy), then a C-HTTP name service response is returned to the
`
`client-side proxy including an IP address for the server-side proxy and Nonce
`
`values, and a secure, encrypted channel is automatically initiated/created between
`
`the client-side proxy and the server-side proxy. However, if the requested host is
`
`not a member of the closed network, then the DNS proxy module or DNS module
`
`performs a lookup to the conventional DNS server and returns the IP address to the
`
`client-side proxy.
`
`As set forth in Ex.1009 ¶¶ 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’s C-HTTP name server.
`
`Kiuchi clearly recognizes and discloses that a conventional DNS lookup for the
`
`domain name is needed when access is not being requested to a secure server, 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 ‘151 Patent, where a DNS
`
`lookup is performed when access is not being requested to a secure server.
`
`(Ex.1001 at 38:12-16).
`
`
`Page 35 of 68
`
`28
`
`VIRNETX EXHIBIT 2022-Part 2
`Apple v. Virnetx
`Case IPR2013-00394
`
`
`
`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’s teachings to make the conventional
`
`DNS lookup request from the C-HTTP name server. As discussed above, the C-
`
`HTTP name server already determines whether the DNS request received from the
`
`client-side proxy is requesting access to a secure server (i.e., a server-side proxy).
`
`Rather than returning an error status to the client-side proxy when the DNS request
`
`is not requesting access to a secure server, 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 (i.e.,
`
`a “DNS function”), as depicted in the following Figure:
`
`
`Page 36 of 68
`
`29
`
`
`
`
`
`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 ‘151 patent in the DNS server – see Ex.1001 at FIG. 26), is merely
`
`a rearrangement of existing functions within the C-HTTP system and could be
`
`implemented with little or no modification to Kiuchi’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)
`
`would indicate to the client-side proxy that the DNS request is not requesting
`
`
`Page 37 of 68
`
`30
`
`
`
`access to a secure server and hence that no secure/encrypted channel 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 consolidation of domain name resolution functions in the
`
`C-HTTP name server is obvious in view of Kiuchi. See KSR Intern. Co. v. Teleflex
`
`Inc., 550 U.S. 398, 401; 127 S.Ct. 1727, 173 (2007) (“a combination of familiar
`
`elements according to known methods is likely to be obvious when it does no more
`
`than yield predictable results”); Sakraida v. Ag Pro, Inc., 425 U.S. 273, 282, 96
`
`S.Ct. 1532 (1976) (when a patent “simply arranges old elements with each
`
`performing the same function it had been known to perform” and yields no more
`
`than one would expect from such an arrangement, the combination is obvious).
`
`The modified C-HTTP name server includes a “DNS proxy module”
`
`because it contains a program that responds to a domain name inquiry in place of a
`
`DNS (i.e., it responds to a DNS request in place of a conventional DNS server
`
`when the requested host is a member of the closed network). The modified C-
`
`HTTP name server also includes a “DNS module” because it includes a program
`
`that performs a lookup service and returns an IP address for a requested domain
`
`
`Page 38 of 68
`
`31
`
`
`
`name (i.e., it first performs a lookup to determine if the requested host is registered
`
`in the closed network, and then, if needed, performs a lookup to the conventional
`
`DNS server); in Kiuchi, this DNS module also performs the functions of a DNS
`
`proxy by responding to a DNS request in place of the conventional DNS server
`
`when the requested host is a member of the closed network, as discussed above.
`
`The C-HTTP is a data processing device having a memory storing a “DNS
`
`proxy module” or “DNS module” that intercepts DNS requests sent by the client-
`
`side proxy (i.e., the “client”) and performs the steps recited in the claims. The
`
`client-side proxy is a “client” because it is a computer that sends a DNS request.
`
`The server-side proxy is a “secure server” because it is a server that requires
`
`authorization for access and can communicate in an encrypted channel.
`
`Ground 1. Claim 1 is Obvious Over Kiuchi
`
`As set forth in Ex.1009 ¶¶ 29-47 and Appendix C, Kiuchi teaches all of the
`
`limitations of claim 1. With regard to claim 1, the modified C-HTTP name server
`
`including a DNS proxy module is a data processing device. The functions
`
`performed in the modified C-HTTP name server are necessarily stored in computer
`
`program code in memory, as is the case for any such processing device. (Ex.1009 ¶
`
`44).
`
`When the client-side proxy (i.e., the “client”) receives the HTTP request
`
`from the user agent, it generates (and transmits) a DNS request that is sent to the
`
`
`Page 39 of 68
`
`32
`
`
`
`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 “DNS request” 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. If the
`
`domain name sent in the DNS request is the hostname given to the server-side
`
`proxy, then the DNS request corresponds to a secure server (i.e., the server-side
`
`proxy).
`
`The DNS proxy module of the modified C-HTTP name server receives DNS
`
`requests sent by the client-side proxy (i.e., the “client”). Receipt of DNS requests
`
`by the DNS proxy module from the client-side proxy constitutes intercepting DNS
`
`requests because the DNS proxy module receives such DNS requests ahead of a
`
`DNS function (e.g., ahead of the conventional DNS server). For each intercepted
`
`DNS request, the DNS proxy module in the modified C-HTTP name server
`
`performs the steps recited in the claims, as follows:
`
`Step (1) of Claim 1 - Upon receiving the C-HTTP name service request (i.e.,
`
`DNS request) from the client-side proxy, the DNS proxy module of the modified
`
`C-HTTP name server “examines whether the requested server-side proxy is
`
`registered in the closed network.” (Ex.1002 at 65, sec. 2.3(2)). The DNS proxy
`
`module determines whether the intercepted DNS request sent by the client-side
`
`
`Page 40 of 68
`
`33
`
`
`
`proxy corresponds to a server-side proxy in the closed network (i.e., a “secure
`
`server”) based on whether the requested server-side proxy is registered in the
`
`closed network. The DNS proxy module determines that the DNS request
`
`corresponds to a secure server, if the requested server-side proxy is registered in
`
`the closed network. The DNS proxy module determines that the DNS request does
`
`not correspond to a secure server, if the requested server-side proxy is not
`
`registered in the closed network. (Ex.1002 at 65, sec. 2.3(2)-(3)). Thus, step (1) of
`
`claim 1 is satisfied by the determination made by the DNS proxy module of the
`
`modified C-HTTP name server.
`
`Step (2) of Claim 1 – As discussed above for step (1), the DNS proxy
`
`module determines that the DNS request does not correspond to a secure server, if
`
`the requested server-side proxy is not registered in the closed network. When the
`
`DNS proxy module makes this determination, it performs a DNS lookup to the
`
`conventional DNS server (i.e., a DNS function that returns an IP address of a
`
`nonsecure computer), which involves forwarding the domain name (DNS request)
`
`to the conventional DNS server and receiving an IP address back from the DNS
`
`server. (Ex.1009 ¶¶ 44-47). Specifically, Kiuchi teaches that “If a client-side
`
`proxy receives an error status, then it performs DNS lookup, behaving like an
`
`ordinary HTTP/1.0 proxy.” (Ex.1002 at 65, section 2.3, paragraph 2). In the
`
`modified C-HTTP server, this DNS lookup function resides in the C-HTTP name
`
`
`Page 41 of 68
`
`34
`
`
`
`server rather than in the client-side proxy. Thus, the modified C-HTTP server
`
`including the “DNS proxy module” or “DNS module” performs a DNS lookup if
`
`the requested server-side proxy is not registered in the closed network and hence
`
`performs a DNS lookup when the DNS request does not correspond to a secure
`
`server. 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
`
`forwarding the DNS request to the conventional DNS server and receiving an IP
`
`address from the DNS server. For example, RFC 1123 (Ex.1010) defines how
`
`computers on the Internet should 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 does not correspond to a secure server, the modified C-HTTP name
`
`server with “DNS proxy module” or “DNS module” forwards the DNS request to
`
`the conventional DNS server.
`
`Step (3) of Claim 1 - As discussed above for step (1), the DNS proxy
`
`module determines that the DNS request corresponds to a secure server, if the
`
`requested server-side proxy is registered in the closed network. When the DNS
`
`
`Page 42 of 68
`
`35
`
`
`
`proxy module makes this determination, it sends a C-HTTP name service response
`
`to the client-side proxy containing the IP address and public key of the server-side
`
`proxy (i.e., the “secure server”) as well as request and response Nonce values. In
`
`turn, the client-side proxy “sends a request for connection to the server-side
`
`proxy,” which is encrypted using the server-side proxy’s public key and contains
`
`the client-side proxy’s IP address, hostname, request Nonce value and symmetric
`
`data exchange key for request encryption.” (Ex.1002 at 65, right column, section
`
`2.3(3)). The sending of the C-HTTP name service response by the DNS proxy
`
`module to the client-side proxy constitutes “automatically initiating” a secure,
`
`encrypted channel 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)). In this regard, it should be noted
`
`that the ‘151 Patent provides, as one example of automatically initiating/creating a
`
`secure, encrypted channel, transmission of a message requesting that a VPN be
`
`created (see Ex.1001 at 37:66-38:2). The C-HTTP name service response is
`
`analogous because it is a message that causes the secure, encrypted channel 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 corresponds to a secure server.
`
`
`Page 43 of 68
`
`36
`
`
`
`Therefore, steps (1)-(3) of claim 1 are satisfied by the DNS proxy module or
`
`DNS module in the modified C-HTTP name server.
`
`Ground 2. Claim 13 is Obvious Over Kiuchi
`
`Claim 13 is virtually identical to claim 1. Instead of being directed to the
`
`data processing device, claim 13 is a Beauregard claim directed to the computer
`
`readable medium contained within the data processing device and containing the
`
`programs for directing the steps. These program steps are contained in the
`
`program code for a C-HTTP name server accordingly modified.
`
`As discussed above, modified C-HTTP name server includes a “DNS
`
`module” for purposes of claim 13 because it is a program that performs a lookup
`
`service and returns an IP address for a requested domain name (i.e., it first
`
`determines whether the requested host is a member of the closed network, and
`
`then, if needed, performs a lookup to the conventional DNS server); in Kiuchi, this
`
`DNS module also performs the functions of a DNS proxy by responding to a DNS
`
`request in place of the conventional DNS server when the requested host is a
`
`member of the closed network, as discussed above.
`
`The main difference in the steps as claimed is that claim 13 recites
`
`“automatically creating a secure channel between the client and the secure server.”
`
`The use of public key and Nonce values create an encrypted channel which is
`
`therefore secure since those VPN resources are only made available to the client-
`
`
`Page 44 of 68
`
`37
`
`
`
`side proxy (i.e., the “client”) and the server-side proxy (i.e., the “secure server”).
`
`There is no user involvement in the creation of the secure channel. It is automatic.
`
`Just as the ‘151 patent describes “Use of a DNS Proxy to Transparently Create
`
`Virtual Private Networks” by sending a message to a gatekeeper (Ex.1001 at
`
`37:66-38:2), so too does Kiuchi disclose creating a secure, encrypted channel when
`
`the C-HTTP name server sends out public key and Nonce values in response to a
`
`DNS request. Thus, for the reasons set out above with respect to claim 1 and in
`
`view of the claim charts, claim 13 should be rejected for obviousness over Kiuchi.
`
`C. Request 2 – Claims 1 and 13 are Anticipated by Kiuchi
`
`A careful consideration of the inner workings of the client-side proxy reveals
`
`that Kiuchi’s client-side proxy performs a “resolver” 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
`
`domain name. (Ex.1009 ¶ 49). Petitioner presents the following Figure 4 to
`
`schematically show the resolver and client functions in the client-side proxy:
`
`
`Page 45 of 68
`
`38
`
`
`
`
`
`As discussed above with reference to construction of “Domain Name
`
`Service (DNS) request,” resolver functions were known in the art well before the
`
`‘151 Patent was filed. (Ex.1009 ¶ 50). Thus, in Kiuchi, an internal resolution
`
`request (which is a “DNS request” 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
`
`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 ¶ 51).
`
`
`Page 46 of 68
`
`39
`
`
`
`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 ‘151 Patent. (Ex.1009 ¶
`
`52). The DNS proxy server of the ‘151 Patent receives a DNS request, determines
`
`whether the DNS request corresponds to a secure server (e.g., based on a domain
`
`name extension or by reference to an internal table of sites), automatically
`
`initiates/creates a secure, encrypted channel if the DNS request corresponds to a
`
`secure server, and forwards the DNS request to a conventional DNS server if the
`
`DNS request does not correspond to a secure server (see Ex.1001 at 38:23-47).
`
`Similarly, the resolver function of Kiuchi receives a DNS request, determines
`
`whether the DNS request corresponds to a secure server (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 ‘151 Patent), automatically initiates/creates a secure,
`
`encrypted channel if the DNS request corresponds to a secure server, and forwards
`
`the DNS request to a conventional DNS server if the DNS request does not
`
`correspond to a secure server.
`
`Thus, Kiuchi’s resolver function is a “DNS proxy module” within the client-
`
`side proxy because it is a program that responds to a domain name inquiry in place
`
`of a DNS (i.e., it responds to a DNS request in place of a conventional DNS server
`
`when the requested host is a member of the closed network). Kiuchi’s resolver
`
`
`Page 47 of 68
`
`40
`
`
`
`function also is a “DNS module” within the client-side proxy because it is a
`
`program that performs a lookup service and returns an IP address for a requested
`
`domain name (i.e., it first performs a lookup to the C-HTTP name server, and then,
`
`if needed, performs a lookup to the conventional DNS server, in both cases by
`
`remote function calls); in Kiuchi, this DNS module also performs the functions of
`
`a DNS proxy by responding to a DNS request in place of the conventional DNS
`
`server when the requested host is a member of the closed network, as discussed
`
`above. Consequently, Kiuchi’s client-side proxy effectively includes a Client
`
`Module and a DNS proxy module/DNS module (referred to in Figure 4 as the
`
`“DNS Proxy Server Module”). For purposes of the following analysis, the Client
`
`Module of the client-side proxy is the “client,” the server-side proxy is the “secure
`
`server,” and the DNS Proxy Server Module is a “DNS proxy module” or “DNS
`
`module” 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 “DNS request”) 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 resource on the origin server. The
`
`client-side proxy is a data processing device having a memory storing a “DNS
`
`proxy module” or “DNS module” that intercepts DNS requests sent by the Client
`
`Module (i.e., the “client”) and performs the steps recited in the claims. The Client
`
`
`Page 48 of 68
`
`41
`
`
`
`Module is a “client” because it is a program that sends a DNS request. The server-
`
`side proxy is a “secure server” because it is a server that requires authorization for
`
`access and can communicate in an encrypted channel. A secure, encrypted channel
`
`is automatically initiated/created between the client-side proxy and the server-side
`
`proxy if the DNS request corresponds to the server-side proxy (i.e., the “secure
`
`server”).
`
`Ground 3. Claim 1 is Anticipated by Kiuchi
`
`As set forth in Ex.1009 ¶¶ 53-59 and Appendix D, Kiuchi discloses all of the
`
`limitations of claim 1. With regard to claim 1, the client-side proxy including the
`
`DNS Proxy Server Module is a data processing device. The functions performed
`
`in the client-side proxy, including the DNS Proxy Server Module, are necessarily
`
`stored in computer program code in memory, as is the case for any such processing
`
`device. (Ex. 1009 ¶ 44). As discussed above, the DNS Proxy Server Module is a
`
`“DNS proxy module” for purposes of claim 1 because it is a program that responds
`
`to a domain name inquiry in place of a DNS (i.e., it responds to a DNS request in
`
`place of a conventional DNS server when the requested host is a member of the
`
`closed network).
`
`When the Client Module (i.e., the “client”) 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 sends an internal resolver request containing the domain
`
`
`Page 49 of 68
`
`42
`
`
`
`name to the DNS Proxy Server Module. This internal resolver request is a “DNS
`
`request” 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. If the domain name sent in the DNS request is the hostname given
`
`to the server-side proxy, then the DNS request corresponds to a secure server (i.e.,
`
`the server-side proxy).
`
`The DNS Proxy Server Module receives DNS requests sent by the Client
`
`Module (i.e., the “client”). Receipt of DNS request by the DNS Proxy Server
`
`Module from the Client Module constitutes intercepting DNS requests because the
`
`DNS Proxy Server Module receives such DNS requests ahead of a DNS function
`
`(e.g., ahead of the C-HTTP name server and ahead of the conventional DNS
`
`server). For each intercepted DNS request, the DNS Proxy Server Module
`
`performs the steps recited in the claims, as follows:
`
`Step (1) of Claim 1 (Ex.1009 ¶¶ 53-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 “examines
`
`whether the requested server-side proxy is registered in the closed network.”
`
`(Ex.1002 at 65, sec. 2.3(2)). The C-HTTP name server sends a C-HTTP name
`
`
`Page 50 of 68
`
`43
`
`
`
`service response to the DNS Proxy Server Module containing “the IP address and
`
`public key of the server-side proxy and both request and response Nonce values”
`
`(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 sends “a status code which indicates an
`
`error,” if the requested server-side proxy is not registered in the closed network.
`
`(Ex.1002 at 65, sec. 2.3(2)-(3)).
`
`The DNS Proxy Server Module determines whether the DNS request sent by
`
`the Client Module corresponds to a secure server based on the type of response
`
`received from the C-HTTP name server. In particular, the DNS Proxy Server
`
`Module determines that the DNS request corresponds to a secure server, only if a
`
`C-HTTP name service response is returned, and determines that the DNS request
`
`does not correspond to a secure server, if the response is an error status.
`
`Step (2) of Claim 1 (Ex.1009 ¶ 57) - As discussed above for step (1), the
`
`DNS Proxy Server Module determines that the DNS request does not correspond
`
`to a secure server, if the response from the C-HTTP name server is an error status.
`
`When the DNS Proxy Server Module makes this determination, it performs a DNS
`
`lookup to the conventional DNS server (i.e., a DNS function that returns an IP
`
`address of a nonsecure computer), which involves forwarding the domain name
`
`(DNS request) to the conventional DNS server and receiving an IP address back
`
`from the DNS server. (Ex.1009 ¶¶ 59). Specifically, Kiuchi teaches that “If a
`
`
`Page 51 of 68
`
`44
`
`
`
`client-side proxy receives an error status, then it performs DNS lookup, behaving
`
`like an ordinary HTTP/1.0 proxy.” (Ex.1002 at 65, section 2.3, paragraph 2).
`
`Thus, the client-side proxy, and more specifically the DNS Proxy Server Module
`
`in the client-side proxy, performs a DNS lookup in response to receiving the error
`
`status and hence performs a DNS lookup when the DNS request does not
`
`correspond to a secure server. 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 forwarding the DNS request to the conventional DNS server and
`
`receiving an IP address from the DNS server. For example, RFC 1123 (Ex.1010)
`
`defines how computers on the Internet should 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 does not correspond to a secure server, the DNS
`
`Proxy Server Module forwards the DNS request to the conventional DNS server.
`
`Step (3) of Claim 1 (Ex.1009 ¶ 59) – As discussed above for step (1), the
`
`DNS Proxy Server Module determines that the DNS request corresponds to a
`
`secure server, only if the response from the C-HTTP name server is a C-HTTP
`
`
`Page 52 of 68
`
`45
`
`
`
`name service response. When the DNS Proxy Server Module makes this
`
`determination, it sends the IP address and VPN resources (e.g., the public key and
`
`Nonce values) received in the C-HTTP name service response to the Client
`
`Module. In turn, the Client Module “sends a request for connection to the server-
`
`side proxy,” which is encrypted using the server-side proxy’s public key and
`
`contains the client-side proxy’s IP address, hostname, request Nonce value and
`
`symmetric data exchange key for request encryption.” (Ex.1002 at 65, right
`
`column, section 2.3(3)). The sending of the IP address and VPN resources by the
`
`DNS Proxy Server Module to the Client Module constitutes “automatically
`
`initiating” a secure, encrypted channel within the context of the claim because this
`
`transaction causes the client-side proxy to send a request for connection to the
`
`server-side proxy. (Ex.1002 at 65, sec. 2.3(3)). In this regard, it should be noted
`
`that the ‘151 Patent provides, as one example of automatically initiating/creating a
`
`secure, encrypted channel, transmission of a message requesting that a VPN be
`
`created (see Ex.1001 at 37:66-38:2). 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 secure, encrypted channel to be created.
`
`Therefore, steps (1)-(3) of claim 1 are satisfied by the DNS Proxy Server
`
`Module.
`
`Ground 4. Claim 13 is Anticipated by Kiuchi
`
`
`Page 53 of 68
`
`46
`
`
`
`Claim 13 is virtually identical to claim 1. Instead of being directed to the
`
`data processing device, claim 13 is a Beauregard claim directed to the computer
`
`readable medium contained within the data processing device and containing the
`
`programs for directing the steps. These program steps are contained in the
`
`program code for a client-side proxy. As discussed above, the DNS Proxy Server
`
`Module is a “DNS module” for purposes of claim 13 because it is a program that
`
`performs a lookup service and returns an IP address for a requested domain name
`
`(i.e., it first performs a lookup to the C-HTTP name server, and then, if needed,
`
`performs a lookup to the conventional DNS server, in both cases by remote
`
`function calls); in Kiuchi, this DNS module also performs the functions of a DNS
`
`proxy by responding to a DNS request in place of the conventional DNS server
`
`when the requested host is a member of the closed network, as discussed above.
`
`The main difference in the steps as claimed is that claim 13 recites
`
`“automatically creating a secure channel between the client and the secure server.”
`
`The use of public key and Nonce values create an encrypted channel which is
`
`therefore secure since those VPN resources are only made available to the client-
`
`side proxy (i.e., the “client computer”) and the server-side proxy (i.e., the “secure
`
`server”). There is no user involvement in the creation of the secure channel. It is
`
`automatic. Just as the ‘151 patent describes “Use of a DNS Proxy to Transparently
`
`Create Virtual Private Networks” by sending a message to a gatekeeper (Ex.1001
`
`
`Page 54 of 68
`
`47
`
`
`
`at 37:66-38:2), so too does Kiuchi disclose creating a secure channel when the C-
`
`HTTP name server sends out public key and Nonce values in response to a DNS
`
`request. Thus, for the reasons set out above with respect to claim 1 and in view of
`
`the claim charts, claim 13 should be rejected for obviousness over Kiuchi.
`
`D. Request 3 – Claims 1 and 13 are Unpatentable over Dalton in view of
`Kiuchi
`
`Dalton was published in the Proceedings of JENC8, May 1997. (Ex. 1003)
`
`
`
`Dalton was republished in Computer Networks and ISDN Systems, Vol. 29, No.
`
`15, November 1, 1997 (pp1799-1808). (Ex. 1024) Thus, Dalton (like Kiuchi,
`
`discussed above) is prior art under 35 U.S.C. §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 ¶62). Kiuchi is just one of many references describing how
`
`to implement a closed network on the Internet. The ‘151 patent concedes that in the
`
`prior art a “tremendous variety of methods have been proposed and implemented
`
`to provide security and anonymity for communications over the Internet.” (Ex.
`
`1001, 1:27-29) 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 ¶62)
`
`
`Page 55 of 68
`
`48
`
`
`
`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, p. 69, sec. 4.5, emphasis added)
`
`
`
`Kiuchi disclosed “a closed HTTP-based virtual network [that] can be
`
`constructed for closed groups; for example, the headquarters and branches of
`
`a given corporation.” (Ex. 1002, p. 69, sec. 5) Kiuchi re-emphasized the cost
`
`incentive for moving to the Internet: “if resources which might otherwise be
`
`invested in private circuits are channeled into the Internet, it will contribute
`
`to its further development.” Id.
`
`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 through
`
`the CMW to only public hosts on the internal network (Ex. 1009¶63). Dalton
`
`
`Page 56 of 68
`
`49
`
`
`
`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 ¶¶ 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, thus the LAN is protected by the CMW.
`
`However, internal clients are permitted to access all serv