IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`Larson et al.
`In re Patent of:
`U.S. Patent No.: 7,987,274
`Issue Date:
`July 26, 2011
`Appl. Serial No.: 11/839,987
`Filing Date:
`August 16, 2007
`Title:
`METHOD FOR ESTABLISHING SECURE COMMUNICATION LINK
`BETWEEN COMPUTERS OF VIRTUAL PRIVATE NETWORK
`
` Attorney Docket No.: 38868-0003IP2
`
`
`
`DECLARATION OF DR. ROCH GUERIN
`
`1.
`
`My name is Dr. Roch Guerin. I am the chair of the Computer Science &
`
`Engineering department at Washington University in St. Louis. I have been asked to offer
`
`technical opinions relating to U.S. Patent No. 7,987,274, and prior art references relating to its
`
`subject matter. My current curriculum vitae is attached and some highlights follow.
`
`2.
`
`I earned my diplôme d'ingénieur (1983) from École nationale supérieure des
`
`télécommunications, in Paris, France. Thereafter, I earned my M.S. (1984) and PhD (1986) in
`
`electrical engineering from California Institute of Technology in Pasadena, California.
`
`3.
`
`Prior to becoming a professor in engineering, I held various positions at the IBM
`
`T.J. Watson Research Center. Specifically, from 1986 to 1990, I was a research staff member
`
`within the Communication Department, where I worked to design and evaluate high-speed
`
`switches and networks. From 1990 to 1991, I was a research staff member within the IBM High
`
`Performance Computing and Communications Department, where I worked to develop and
`
`deploy an integrated broadband network. From 1992 to 1997, I was the manager of Broadband
`
`Networking within IBM’s Security and Networking Systems Department, where I led a group of
`
`researchers in the area of design, architecture, and analysis of broadband networks. One of the
`
`projects on which I worked, for example, led to U.S. Patent No. 5,673,318, which regards “[a]
`
`Page 1 of 27
`
`VIRNETX EXHIBIT 2024
`Apple v. VirnetX
`Trial IPR2014-00238
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`method and system for providing data authentication, within a data communication environment,
`
`in a manner which is simple, fast, and provably secure,” and of which I am a named inventor.
`
`See U.S. Patent No. 5,673,318, abstract. From 1997 to 1998, I was the manager of Network
`
`Control and Services within IBM’s Security and Networking Systems Department, where I led a
`
`department responsible for networking and distributed applications, including topics such as
`
`advance reservations, policy support, including for Resource Reservation Protocol (RSVP),
`
`quality of service (QoS) routing , and security, and integrated switch and scheduling designs.
`
`4.
`
`I have been a professor of engineering for the past fifteen years. As such, but
`
`prior to becoming the chair of the Computer Science & Engineering department at Washington
`
`University in St. Louis, I was the Alfred Fitler Moore Professor of Telecommunications
`
`Networks (an honorary chair) in the Department of Electrical and Systems Engineering at the
`
`University of Pennsylvania. As a professor of engineering, I have taught many courses in
`
`networking, including Advanced Networking Protocols (TCOM 502), which addressed, among
`
`other things, virtual private networks.
`
`5.
`
`I have authored over fifty journal publications, including “On the Feasibility and
`
`Efficacy of Protection Routing in IP Networks,” which was honored as the IEEE INFOCOM
`
`2010 Best Paper Award. I have been named a Fellow by both the IEEE and ACM, and, from
`
`2009 to 2012, I was the Editor-in-Chief of the IEEE/ACM Transactions on Networking.
`
`Furthermore, I am a named inventor on over thirty issued U.S. patents.
`
`6.
`
`I am familiar with the content of U.S. Patent No. 7,987,274 (the “‘274 patent”).
`
`Additionally, I have reviewed the following: Takahiro Kiuchi et al., Proceedings of the
`
`Symposium on Network and Distributed System Security, C-HTTP -- The Development of a
`
`Secure, Closed HTTP-based Network on the Internet (Feb., 1996) (“Kiuchi”); U.S. Patent No.
`
`Page 2 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`6,225,993 to Lindblad et al. (“Lindblad”); U.S. Patent No. 8,200,837 to Bhatti et al. (“Bhatti”);
`
`E. Gavron, RFC 1535, A Security Problem and Proposed Correction With Widely Deployed DNS
`
`Software (Oct. 1993); RFC 791, Internet Protocol (Sep. 1981); Kenneth F. Alden & Edward P.
`
`Wobber, The AltaVista Tunnel: Using the Internet to Extend Corporate Networks, p. 6 (9 Digital
`
`Technical Journal 2) (1997); and T. Berners-Lee et al., RFC 1945, Hypertext Transfer Protocol -
`
`- HTTP/1.0 (May 1996). I have also reviewed certain sections of the prosecution history of the
`
`‘274 patent, the prosecution histories of reexamination control numbers 95/001,270 and
`
`95/001,792; and the claim construction orders from VirnetX Inc. v. Microsoft Corp., Docket No.
`
`6:07CV80 (E.D. Tex.) and VirnetX Inc. v. Cisco Systems, Inc. et al., Docket No. 6:10cv417 (E.D.
`
`Tex.).
`
`7.
`
`Counsel has informed me that I should consider these materials through the lens
`
`of one of ordinary skill in the art related to the ‘274 patent at the time of the invention, and I have
`
`done so during my review of these materials. I believe one of ordinary skill as of April 26, 2000
`
`(the earliest possible priority date of the ‘274 patent) would have a Master’s degree in computer
`
`science or computer engineering, or in a related field such as electrical engineering, as well as
`
`about two years of experience in computer networking and in some aspect of security with
`
`respect to computer networks. I base this on my own personal experience, including my
`
`knowledge of colleagues and others at the time.
`
`8.
`
`I have no financial interest in either party or in the outcome of this proceeding. I
`
`am being compensated for my work as an expert on an hourly basis. My compensation is not
`
`dependent on the outcome of these proceedings or the content of my opinions.
`
`9.
`
`My opinions, as explained below, are based on my education, experience, and
`
`background in the fields discussed above.
`
`Page 3 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`10.
`
`This declaration is organized as follows:
`
`I.
`
`II.
`
`III.
`
`IV.
`
`Brief Overview of the ‘274 Patent (page 4)
`
`Terminology (page 7)
`
`Kiuchi and Combinations Based on Kiuchi (page 12)
`
`Conclusion (page 27)
`
`Brief Overview of the ‘274 Patent
`
`The ‘274 patent is directed to a “method for establishing [a] secure
`
`I.
`
`11.
`
`communication link between computers of [a] virtual private network.” Ex. 1001, Title. The
`
`‘274 patent includes 18 claims, of which claim 1 is independent.
`
`12.
`
`A section of the ‘274 patent’s specification titled “F. One-Click Secure On-Line
`
`Communications and Secure Domain Name Service” describes “a technique for establishing a
`
`secure communication link between a first computer and a second computer over a computer
`
`network,” with reference to FIGS. 33-35. Ex. 1001, 45:8-10. Referring to Annotation A of FIG.
`
`33 below, a computer 3301 establishes a VPN communication link with a server computer 3320,
`
`or a secure edge router for the server computer 3320. See Ex. 1001, 46:29-31, 47:41-44.
`
`Page 4 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`Annotation A
`
`
`
`13.
`
`The server computer 3320 is associated with a secure top-level domain name. See
`
`Ex. 1001, 46:33-34. Domain names are a type of human-readable name/address for resources on
`
`a network, such as the Internet. See RFC 1535, p. 1 (1993) (“Current Domain Name Server
`
`clients are designed to ease the burden of remembering IP dotted quad addresses. As such they
`
`translate human-readable names into addresses and other resource records.”). Domain names are
`
`resolved by name servers into numerical addresses that are utilized for packet forwarding over
`
`networks. See id.; see also RFC 791, pp. 2, 5-6 (1981). As such, domain names may be
`
`maintained in the human-readable form, which is easier for a human operator to utilize than the
`
`numerical addresses relied upon by the networks for forwarding packets. Ex. 1003, 1:49-56.
`
`14. With respect to the term “secure top-level domain name,” the ‘274 patent notes
`
`that “[b]ecause the secure top-level domain name is a non-standard domain name, a query to a
`
`standard domain name service (DNS) will return a message indicating that the universal resource
`
`locator (URL) is unknown.” Ex. 1001, 46:41-44. Thus, in the context of the ‘274 patent, a
`
`Page 5 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`secure top-level domain name is differentiated from a standard domain name in that a secure top-
`
`level domain name cannot be resolved by a standard domain name service.
`
`15.
`
`In order to resolve the secure top-level domain name of the server computer 3320,
`
`the computer 3301 sends a query to a secure domain name service (SDNS) 3313, as illustrated in
`
`the following Annotation B of FIG. 33. See Ex. 1001, 46:58-62. This query to the SDNS 3313
`
`can either be sent “in the clear” or can use a VPN communication link. See Ex. 1001, 47:52-54.
`
`With respect to the term “secure domain name service,” the ‘274 patent indicates that “SDNS
`
`3313 contains a cross-reference database of secure domain names and corresponding secure
`
`network addresses.” Ex. 1001, 47:15-16. In other words, the SDNS 3313 differs from a
`
`standard name service in that it is configured to resolve secure domain names.
`
`Annotation B
`
`
`
`16.
`
`Based on its cross-reference database, the SDNS 3313 responds to the query of
`
`computer 3301 with a secure network address for the server 3320. See Ex. 1001, 47:48-51. The
`
`secure network address is then used to establish, a VPN communication link 3321 between the
`
`Page 6 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`computer 3301 and server 3320. See Ex. 1001, 47:38-65. The ‘274 patent describes that the
`
`SDNS 3313 and VPN gatekeeper 3314 may work together to establish a VPN communication
`
`link 3321 between computer 3301 and server 3320, or, alternatively, that the computer 3301 may
`
`establish the VPN communication link 3321 with server 3320 on its own. See id. Regardless of
`
`how the VPN communication link 3321 is established between computer 3301 and server 3320,
`
`the computer 3301 utilizes the secure network address it receives from SDNS 3313 to send an
`
`access request to the server 3320 over the earlier-established VPN communication link 3321, as
`
`illustrated in the following Annotation C of FIG. 33. See Ex. 1001, 47:66 to 48:1. In the
`
`primary embodiment described by the ‘274 patent, the resource accessed by computer 3301 on
`
`the server 3320 may be a secure website requested by a browser 3306 on computer 3301. See
`
`Ex. 1001, 47:19-37.
`
`Annotation C
`
`II.
`
`Terminology
`
`
`
`Page 7 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`17.
`
`I have been informed that claim terminology must be given the broadest
`
`reasonable interpretation during an IPR proceeding. I have been informed that this means the
`
`claims should be interpreted as broadly as their terms reasonably allow, but that such
`
`interpretation should not be inconsistent with the patent’s specification and with usage of the
`
`terms by one of ordinary skill in the art. Counsel has also informed me that this may yield
`
`interpretations that are broader than the interpretation applied during a District Court proceeding,
`
`such as the pending VirnetX Inc. v. Microsoft Corp. litigation
`
`18.
`
`I have been informed that it would be useful to provide some guidance in this
`
`proceeding with respect to certain terms, and has asked me to consider the terms below and
`
`corresponding constructions. As part of that, for each term addressed below, I considered each
`
`term’s context within the claim, use within the specification, and my understanding of how one
`
`of ordinary skill in the art would understand the term around the time of the purported invention.
`
`19.
`
`I have considered whether a broadest reasonable interpretation of “virtual private
`
`network” would be broad enough to cover “a network of computers that privately communicate
`
`with each other by encrypting traffic on insecure communication paths between the computers.”
`
`I believe that it would, since such an interpretation is not inconsistent with the ‘274 patent’s
`
`specification and the understanding one of ordinary skill in the art would ascribe to this term
`
`when looking for the broadest reasonable construction. There is not an explicit definition of
`
`“virtual private network” in the ‘274 patent. However, in describing the “advantages of the
`
`present invention,” the ‘274 patent describes the VPN connection between computer 3301 and
`
`secure server 3320 as “a secure communication link between a first computer and a second
`
`computer over a computer network, such as the Internet.” See Ex. 1001, 6:39-42.
`
`Page 8 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`20. Moreover, some of the VPNs described in the ‘274 patent rely upon encryption,
`
`and the ‘274 patent acknowledges that “[o]ther types of VPNs can alternatively be used” for
`
`securing communications over the Internet 3302. Ex. 1001, 39:49-54; 47:11. I therefore believe
`
`that a broadest reasonable interpretation of “virtual private network” would be broad enough to
`
`cover “a network of computers that privately communicate with each other by encrypting traffic
`
`on insecure communication paths between the computers.”
`
`21.
`
`I have considered whether a broadest reasonable interpretation of “virtual private
`
`network communication link” would be broad enough to cover “any communication link
`
`between two end points in a virtual private network.” I believe that it would, since such an
`
`interpretation is not inconsistent with the ‘274 patent’s specification and the understanding one
`
`of ordinary skill in the art would ascribe to this term when considering the broadest reasonable
`
`construction. There is not an explicit definition of “communication link” in the ‘274 patent.
`
`Instead, the ‘274 specification broadly describes a virtual private network (VPN) communication
`
`link through a computer network between two end points. See Ex. 1001, 45:41-46. However,
`
`the use of the term “communication link” in the claims and specification of the ‘274 patent does
`
`not limit the recited communication link to any particular end points. Indeed, the ‘274 patent
`
`makes clear that the VPN communication link can be established with an edge router (e.g., a
`
`firewall). Ex. 1001, 47:41-44. I therefore believe that a broadest reasonable interpretation of
`
`“virtual private network communication link” would be broad enough to cover “any
`
`communication link between two end points in a virtual private network.”
`
`22.
`
`I have considered whether a broadest reasonable interpretation of “secure
`
`computer network address” would be broad enough to cover “a network address that requires
`
`authorization for access and is associated with a computer configured to be accessed through a
`
`Page 9 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`virtual private network.” I believe that it would, since such an interpretation is not inconsistent
`
`with the ‘274 patent’s specification and the understanding one of ordinary skill in the art would
`
`ascribe to this term when considering the broadest reasonable construction. There is not an
`
`explicit definition of “secure computer network address” in the ‘274 patent. However, the ‘274
`
`patent describes that secure server 3320 has a secure computer network address, and that
`
`“[s]erver 3320 can only be accessed through a VPN communication link.” Ex. 1001, 47:40-41.
`
`Moreover, before providing computer 3301 with the information for the server 3320, the patent
`
`specification indicates that the SDNS 3313 may verify a user’s identity, which is a form of
`
`authentication and authorization. See Ex. 1001, 47:33-37. I therefore believe that a broadest
`
`reasonable interpretation of “secure computer network address” would be broad enough to cover
`
`“a network address that requires authorization for access and is associated with a computer
`
`configured to be accessed through a virtual private network.”
`
`23.
`
`I have considered whether a broadest reasonable interpretation of “secure domain
`
`name” would be broad enough to cover “a non-standard domain name that corresponds to a
`
`secure computer network address and cannot be resolved by a conventional domain name service
`
`(DNS).” I believe that it would, since such an interpretation is not inconsistent with the ‘274
`
`patent’s specification and the understanding one of ordinary skill in the art would ascribe to this
`
`term when considering the broadest reasonable interpretation. There is not an explicit definition
`
`of “secure domain name” in the ‘274 patent. However, the ‘274 patent describes that “[b]ecause
`
`the secure top-level domain name is a non-standard domain name, a query to a standard domain
`
`name service (DNS) will return a message indicating that the universal resource locator (URL) is
`
`unknown.” Ex. 1001, 46:41-44. Usage of “secure domain name” throughout the specification is
`
`consistent with this statement. See generally Ex. 1001, 45:8 to 49:13. I therefore believe that a
`
`Page 10 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`broadest reasonable interpretation of “secure domain name” would be broad enough to cover “a
`
`non-standard domain name that corresponds to a secure computer network address and cannot be
`
`resolved by a conventional domain name service (DNS).”
`
`24.
`
`I have considered whether a broadest reasonable interpretation of “secure domain
`
`name service” would be broad enough to cover “a service that can resolve secure computer
`
`network addresses for a secure domain name for which a conventional domain name service
`
`cannot resolve addresses.” I believe that it would, since such an interpretation is not inconsistent
`
`with the ‘274 patent’s specification and the understanding one of ordinary skill in the art would
`
`ascribe to this term when considering the broadest reasonable construction. There is not an
`
`explicit definition of “secure domain name service” in the ‘274 patent. However, the ‘274 patent
`
`describes that “SDNS 3313 contains a cross-reference database of secure domain names and
`
`corresponding secure network addresses.” Ex. 1001, 47:15-16. Moreover, the ‘274 patent
`
`describes that a standard DNS cannot resolve secure domain names. See Ex. 1001, 46:41-44. I
`
`therefore believe that a broadest reasonable interpretation of “secure domain name service”
`
`would be broad enough to cover “a service that can resolve secure computer network addresses
`
`for a secure domain name for which a conventional domain name service cannot resolve
`
`addresses.”
`
`25.
`
`I have been asked to consider a broadest reasonable interpretation of “tunnel
`
`packeting.” There is not an explicit definition of “tunnel packeting” in the ‘274 patent. In fact,
`
`the ‘274 patent does not use the phrase “tunnel packeting” outside of the issued claims.
`
`Moreover, the phrase “tunnel packeting” is not a term of art. Thus, the term “tunnel packeting”
`
`is without ordinary meaning. Therefore, I review its component terms, noting the presence of
`
`“tunnel” and a form of the word “packet.” Reading these terms in the context of the patent’s
`
`Page 11 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`disclosure, which also uses the term “tunnel” and “packet,” and in the absence of any other
`
`guidance from the patent’s file history, I would find it unreasonable to interpret the term “tunnel
`
`packeting” any more narrowly than “encapsulating a first packet of a first protocol in a second
`
`packet of a second protocol,” if attributing any limitation at all to this term.
`
`26.
`
`I have considered whether a broadest reasonable interpretation of “tunneling”
`
`would be broad enough to cover “encapsulating a first protocol data unit in a second protocol.” I
`
`believe it would, since such an interpretation is not inconsistent with the ‘274 patent’s
`
`specification and the understanding one of ordinary skill in the art would ascribe to this term
`
`when considering the broadest reasonable construction. There is not an explicit definition of
`
`“tunneling” in the ‘274 patent. However, as noted above, the ‘274 patent describes that “[t]he
`
`client-side proxy application program tunnels the unencrypted, unprotected communication
`
`packets through a new protocol, thereby protecting the communications from a denial of service
`
`at the server side.” Ex. 1001, 49:31-34. This is an example of a tunnel in which packets are
`
`encapsulated, which could be implemented at the network layer. However, at the time of the
`
`‘274 patent, it was well known that tunnels could also be implemented at other layers, such as
`
`the application layer (e.g., an HTTP tunnel). Kenneth F. Alden & Edward P. Wobber, The
`
`AltaVista Tunnel: Using the Internet to Extend Corporate Networks, p. 6 (9 Digital Technical
`
`Journal 2) (1997) (favoring protocol levels higher than the network layer for implementation of a
`
`firewall and operating system independent tunnel). With such thin reference to “tunneling” in
`
`the ‘274 patent, and with tunneling generally read to include implementations at different layers,
`
`I believe that a broadest reasonable interpretation of “tunneling” would be broad enough to cover
`
`“encapsulating a first protocol data unit in a second protocol.”
`
`III. Kiuchi and Combinations Involving Kiuchi
`
`A.
`
`Kiuchi
`
`Page 12 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`27.
`
`In general, Kiuchi describes a secure, closed HTTP-based network (C—HTTP) on
`
`the Internet, where each member of the network is protected by its own firewall. See Ex. 1004,
`
`p. 64, abstract. Kiuchi describes that this secure, closed network can be used as a virtual network
`
`for connecting “closed groups; for example, the headquarters and branches of a given
`
`corporation.” Ex. 1004, p. 69, § 5. The following Diagram 1 illustrates relevant parts within the
`
`C-HTTP system described by Kiuchi, and will be used to describe the system.
`
`I
`I
`I
`I
`
`:
`
`I
`I
`I
`I
`
`One or More
`Origin Servers
`
`:
`User Agent
`DNS
`
`C-HTTP Secure
`Name Service
`
`(see p. 68, 42(2))
`
`Standard/Public
`
`Diagram 1
`
`28.
`
`Kiuchi describes a process by which a client-side proxy establishes a closed
`
`virtual network over the Internet with a server-side proxy, through which a user agent associated
`
`with the client-side proxy may request information stored on one or more origin servers
`
`associated with the server-side proxy. See Ex. 1004, p. 64, § 2.1. In particular, Kiuchi describes
`
`a number of discrete steps for establishing a secure C-HTTP connection, and, thus, creating the
`
`HTI'P—based virtual network. See Ex. 1004, pp. 65-66, § 2.3. These discrete steps for
`
`establishing the C-HTTP connection are illustrated in the following Diagram 2, in which each
`
`step is numbered to indicate a temporal sequence of the steps described by Kiuchi. These
`
`Page 13 of 27
`
`

`
`numbered steps will each be described in detail with reference to subsequent diagrams created
`
`for explaining Kiuchi in this Declaration.
`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`User Agent
`
`One or More
`Origin Servers
`
`Name Service
`
`
`C—HT|'P Secure
`
`Standard/Public
`DNS
`
`Diagram 2
`
`29.
`
`According to Kiuchi, the HTTP-compatible user agent may be used to display
`
`HTML docmnents to an end-user. See Ex. 1004, p. 65, § 2.3. Through interaction with the user
`
`agent, the end user may select a hyperlink URL included within an HTML document. See id.
`
`For example, the URL may take the form: http://server.in.cu1rent.connection/sample.html=
`
`@=6zdDfldfcZLj8V!i. Id. In this example URL, “server.in.current.connection” is the hostname,
`
`“sample.ht1nl” is the name of the resource being requested, and “6zdDfldfcZLj8V!i” is a
`
`connection 1]) used by the client—side proxy. As shown in this example, the “hostname”
`
`described by Kiuchi includes a domain name. When the end user selects the hyperlink in the
`
`displayed HTML document, the user agent sends a request for the URL to the client—side proxy.
`
`See id.
`
`Page 14 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`30. When the client-side proxy receives the URL (including the hostname) from the
`
`user agent, it determines whether the connection ID included in the URL matches the IDs of any
`
`current connections being maintained by the client-side proxy. See id. If the connection ID is
`
`not found in the current connection table in the client-side proxy, the client-side proxy attempts
`
`to establish a new C-HTTP connection with the host corresponding to the hostname included in
`
`the URL. See id.
`
`31.
`
`To establish a new C-HTTP connection with a host, the client-side proxy attempts
`
`to resolve the hostname included in the URL by asking the C-HTTP name server whether it can
`
`communicate with the host associated with the hostname. See Ex. 1004, p. 65, § 2.3(2). Upon
`
`receipt of such a query, the C-HTTP name server first authenticates the client-side proxy to
`
`determine if the query is legitimate. Id. When the query is legitimate, the C-HTTP name server
`
`further determines “whether the requested server-side proxy is registered in the closed network
`
`and is permitted to accept the connection from the client-side proxy.” Id. If the connection is
`
`permitted, the C-HTTP name server sends a response to the query that includes “the IP address
`
`and public key of the server-side proxy and both request and response Nonce values.” Id. These
`
`public key and Nonce values are forms of provisioning information for the C-HTTP connection,
`
`as they provide information that enables communication over the C-HTTP connection. If, on the
`
`other hand, the connection is not permitted, the C-HTTP name server returns an error message,
`
`in response to which the client-side proxy performs a look-up to a conventional DNS server. See
`
`id.
`
`32.
`
`Diagram 3 illustrates: (1) a request sent from the user agent to the client-side
`
`proxy for a URL including a host name; (2) a query from the client-side proxy to the C-HTTP
`
`name server for a C-HTTP connection with the server-side proxy associated with the host name
`
`Page 15 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`included in the URL (when a C—HTTP connection does not already exist); and (3) a response
`
`from the C—HTTP name server that either includes the IP address associated with the host name
`
`01' an error message.
`
`C—HTTP Secure
`Name Service
`
`User Agent
`
`\
`
`One or More
`Origin Servers
`
`\
`
`
`DNS
`
`\ (If error received)
`\
`
`Standard/Public
`
`Diagram 3
`
`33.
`
`Kiuchi describes that each C-HTIP name server is particular to a closed C—HTTP
`
`network. See Ex. 1004, p. 65, § 2.2. Moreover, Kiuchi explicitly distinguishes the C—HTTP
`
`name server from a standard DNS. See Ex. 1004, p. 64, § 2.1 (“[t]he DNS name service is not
`
`used for hostname resolution”). Kiuchi describes that, for each proxy installed on a firewall, “an
`
`IP address (for a server-side proxy, a port number should also be registered) and hostname
`
`(which does not have to be the same as its DNS name)” are registered with the C—HTTP name
`
`server. Ex. 1004, p. 65, § 2.2 (emphasis added). It is apparent that a standard DNS server would
`
`be unable to resolve the hostname of a server-side proxy when the hostname is different from the
`
`DNS name. See id. Therefore, the C-HTTP name server described by Kiuchi is a service that
`
`can resolve secure network addresses for a hostname for which a conventional domain name
`
`service cannot resolve addresses.
`
`Page 16 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`34.
`
`As described above, before providing the client-side proxy with the IP address of
`
`the server-side proxy, the C-HTTP name server “confirms that the query is legitimate” and
`
`determines “[i]f the connection is permitted.” Ex. 1004, p. 65, § 2.3. Moreover, as illustrated in
`
`Diagram 4 (below), before the server—side proxy will accept a client—side proxy’s request for
`
`connection (see request to server-side proxy at 4), the server-side proxy “asks the C-HTTP name
`
`server whether the client—side proxy is an appropriate member of the closed network” (see
`
`request to name server at 5) and “examines whether the client—side proxy is pennitted to access
`
`to the server-side proxy”. Ex. 1004, pp. 65-66, § 2.3. Communication of permission by the
`
`name server to the server—side proxy (see reply message at 6) is necessary and preliminary to
`
`communication of a response from the server-side proxy to the client-side proxy that enables a
`
`C-HTTP connection to be established there between (see reply message at 7).
`
`C-HTTP Secure
`
`Name Service One or More
`
`Origin Servers
`
`User Agent
`
`Standard/Public
`
`DNS
`
`Diagram 4
`
`35.
`
`Accordingly, the IP address of the server-side proxy (which corresponds to the
`
`hostname in the URL received by the client-side proxy) is a network address that requires
`
`Page 17 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`authorization for access. Moreover, because the C-HTTP connection is a form of virtual private
`
`network communication link between the proxies, the server-side proxy is accessible as part of a
`
`virtual private network.
`
`36.
`
`The hostname of the server-side proxy “does not have to be the same as a DNS
`
`name.” Ex. 1004, p. 65, § 2.2. Indeed, as described above, it is apparent that a standard DNS
`
`server would be unable to resolve such a hostname, and the IP address of the server-side proxy is
`
`network address that requires authorization for access and is associated with a computer capable
`
`of virtual private network communications. Therefore, the hostname of the server-side proxy
`
`may be a non-standard domain name (e.g., “University.of.Tokyo.Branch.Hospital”) that
`
`corresponds to a secure computer network address and cannot be resolved by a conventional
`
`domain name service (DNS). See Ex. 1004, p. 73.
`
`37.
`
`In summary, the client-side proxy receives a hostname, such as
`
`“server.in.current.connection,” when an end-user selects a URL included in an HTML document,
`
`which is illustrated as (1) in Diagram 5. The client-side proxy sends a query message to the C-
`
`HTTP server, requesting from the C-HTTP server the IP address of the server-side proxy
`
`corresponding to the hostname, which illustrated as (2) in Diagram 5. In response to the query
`
`message, the client-side proxy receives from the C-HTTP server a response message containing
`
`the IP address of the server-side proxy, which is illustrated as (3) in Diagram 5.
`
`Page 18 of 27
`
`

`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7,987,274
`
`One or More
`Origin Servers
`
`Name Service
`User Agent
`
`
`C-HTTP Secure
`
`Standard/Public
`DNS
`
`Diagram 5
`
`38.
`
`The response that contains the IP address of the server-side proxy is encrypted.
`
`See Ex. 1004, p. 65, § 2.3. Because the IP address is contained within the response, the C-HITP
`
`name server of Kiuchi has encrypted the IP address when it encrypts the response message. In
`
`order to use the received IP address, the client-side proxy would therefore necessarily have to
`
`decrypt the response from the C-H'I'I'P name server that contains the IP address. See Ex. 1004,
`
`p. 65, § 2.3(2)-(3). In summary, Kiuchi describes that the secure network address is encrypted
`
`and that the client-side proxy decrypts the encrypted secure network address.
`
`39.
`
`Once the client-side proxy receives the IP address of the server-side proxy, the
`
`client-side proxy attempts to establish a C-HTTP connection with the server-side proxy. Ex.
`
`1004, p. 65, § 2.3(3). The steps described by Kiuchi for establishing the C-HTTP connection are
`
`illustrated in Diagram 6. In particular, Kiuchi describes that the client-side proxy sends a
`
`“[r]equest for connection to the server-side proxy” (4), the server-side proxy performs a
`
`“[l]ookup of client-side proxy information” (5 and 6), and the server-side proxy sends
`
`Page 19 of 27
`
`

`
`confirmation of the connection to the client-side proxy (7), if the server-side proxy is able to
`
`properly authenticate the client-side proxy. See Ex. 1004, pp. 65-66, § 2.3, steps 3-5.
`
`Attorney Docket No.: 38868-0003IP2
`U.S. Patent No. 7.987.274
`
`C—H1'rP Secur