throbber
proxy (i.e., the “secure server”). The DNS proxy module or DNS module of the
`
`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).
`
`
`
`28
`
`Page 35 of 68
`
`VIRNETX EXHIBIT 2013-Part 2
`Apple v. Virnetx
`Case IPR2013-00354
`
`

`
`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:
`
`
`
`29
`
`Page 36 of 68
`
`

`
`
`
`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
`
`
`
`30
`
`Page 37 of 68
`
`

`
`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
`
`
`
`31
`
`Page 38 of 68
`
`

`
`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
`
`
`
`32
`
`Page 39 of 68
`
`

`
`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
`
`
`
`33
`
`Page 40 of 68
`
`

`
`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
`
`
`
`34
`
`Page 41 of 68
`
`

`
`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
`
`
`
`35
`
`Page 42 of 68
`
`

`
`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.
`
`
`
`36
`
`Page 43 of 68
`
`

`
`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-
`
`
`
`37
`
`Page 44 of 68
`
`

`
`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:
`
`
`
`38
`
`Page 45 of 68
`
`

`
`
`
`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).
`
`
`
`39
`
`Page 46 of 68
`
`

`
`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
`
`
`
`40
`
`Page 47 of 68
`
`

`
`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
`
`
`
`41
`
`Page 48 of 68
`
`

`
`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
`
`
`
`42
`
`Page 49 of 68
`
`

`
`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
`
`
`
`43
`
`Page 50 of 68
`
`

`
`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
`
`
`
`44
`
`Page 51 of 68
`
`

`
`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
`
`
`
`45
`
`Page 52 of 68
`
`

`
`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
`
`
`
`46
`
`Page 53 of 68
`
`

`
`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
`
`
`
`47
`
`Page 54 of 68
`
`

`
`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)
`
`
`
`48
`
`Page 55 of 68
`
`

`
`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
`
`
`
`49
`
`Page 56 of 68
`
`

`
`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 permi

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