IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`In re Patent of: Munger et al.
`U.S. Patent No.: 7,490,151
`Issue Date: Feb. 10, 2009
`Appl. Serial No.: 10/259,494
`Filing Date: Sep. 30, 2002
`Title: ESTABLISHMENT OF A SECURE COMMUNICATION LINK
`BASED ON A DOMAIN NAME SERVICE (DNS) REQUEST
`
`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,490,151, 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 The
`
`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
`
`
`
`In re Patent of: Munger et al.
`U.S. Patent No.: 7,490,151
`Issue Date: Feb. 10, 2009
`Appl. Serial No.: 10/259,494
`Filing Date: Sep. 30, 2002
`Title: ESTABLISHMENT OF A SECURE COMMUNICATION LINK
`BASED ON A DOMAIN NAME SERVICE (DNS) REQUEST
`
`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,490,151, 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 The
`
`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] 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 sixteen
`
`years. As such, but prior to becoming the chair of the Computer Science
`
`2
`
`
`
`& 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 more than fifty journal publications, including
`
`“On the Feasibility and Efficacy of Protection Routing in IP Networks,”
`
`which was honored with 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,490,151
`
`(“the ‘151 patent”). In addition, I have considered the various documents
`
`referenced in my declaration as well as additional background materials. I
`
`have also reviewed certain sections of the prosecution history of the ‘151
`
`patent, the prosecution histories of reexamination control numbers
`
`95/001,697 and 95/001,714; and the claim construction orders from
`
`3
`
`
`
`VirnetX Inc. v. Microsoft Corp., Docket No. 6:07-CV-80 (E.D. Tex.) and
`
`VirnetX Inc. v. Cisco Systems, Inc. et al., Docket No. 6:10-cv-417 (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 ‘151
`
`patent as of its effective filing date, and I have done so during my review
`
`of these materials. I believe one of ordinary skill as of February 15, 2000
`
`(the priority date of the ‘151 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.
`
`10.
`
`This declaration is organized as follows:
`
`4
`
`
`
`I. Brief Overview of the ‘151 Patent
`
`II. Terminology
`
`III. Kiuchi and Combinations Based on Kiuchi
`
`IV. Publication and Authenticity of Requests For Comment (RFCs)
`
`and Internet-Drafts
`
`V. Conclusion
`
`I. BRIEF OVERVIEW OF THE ‘151 PATENT
`11.
`The ‘151 patent is directed in part to the “establishment of a
`
`secure communication link based on a domain name service (DNS)
`
`request.” Ex. 1001, Title. The ‘151 patent includes 16 claims, of which
`
`claims 1, 7, and 13 are independent.
`
`12. A section of the ‘151 patent’s specification, titled “B. Use of a
`
`DNS Proxy to Transparently Create Virtual Private Networks,” describes
`
`“the automatic creation of a virtual private network (VPN) in response to
`
`a domain name server look-up function,” with reference to FIGS. 25-27.
`
`Ex. 1001 at 36:58-60. In the example embodiment, the ‘151 patent
`
`describes that a “specialized DNS server traps DNS requests and, if the
`
`request is from a special type of user (e.g., one for which secure
`
`communication services are defined), the server does not return the true
`
`IP address of the target node, but instead automatically sets up a virtual
`
`5
`
`
`
`private network between the target node and the user.” Ex. 1001 at 37:33-
`
`38.
`
`13.
`
`In the case of standard “DNS requests that are determined to
`
`not require secure services (e.g., an unregistered user), the DNS server
`
`transparently ‘passes through’ the request to provide a normal look-up
`
`function.” Ex. 1001 at 37:43-46. On the other hand, if access to a secure
`
`site has been requested, the system described in the ‘151 patent
`
`“determines whether the user has sufficient security privileges to access
`
`the site,” and, if so, transmits a message requesting that a virtual private
`
`network be created between the client and the secure target site. See Ex.
`
`1001 at 37:60-38:2. The ‘151 patent describes that the various functions
`
`of the DNS proxy, DNS server, and gatekeeper can be performed on the
`
`same or different machines. See Ex. 1001 at 37:54-56, 38:22-24, 38:30-
`
`32.
`
`II. TERMINOLOGY
`14.
`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 from the perspective of a person of skill in
`
`the art at the time, but that such interpretation should not be inconsistent
`
`6
`
`
`
`with the patent’s specification. I have been informed that this may yield
`
`interpretations that are broader than the interpretation applied during a
`
`District Court proceeding.
`
`15.
`
`I have been informed that it would be useful to provide some
`
`guidance in this proceeding with respect to certain terms, and I have been
`
`asked to consider the term below and its corresponding interpretation. As
`
`part of that, I considered this 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 under the broadest reasonable interpretation standard.
`
`16.
`
`I understand that in a prior proceeding regarding the ‘151 patent
`
`(“IPR2014-00610”) the Patent Trial and Appeal Board (“PTAB”) stated
`
`that the broadest reasonable interpretation of the term “client” as used in
`
`the claims is “a device, computer, system, or program from which a data
`
`request to a server is generated.” Ex. 1011, pp. 7-8. In my opinion, the
`
`PTAB’s interpretation above is consistent with the opinions I previously
`
`offered in IPR2014-00610, the specification of the ‘151 patent and the
`
`ordinary meaning of this term to one of ordinary skill in the art. First,
`
`such an interpretation is consistent with the ‘151 patent’s specification.
`
`Indeed, the ‘151 application describes both “client computers” and
`
`7
`
`
`
`“client applications.” See Ex. 1001 at 15:61-62, 37:1-3. Moreover, the
`
`proposed interpretation is consistent with the understanding one of
`
`ordinary skill in the art would ascribe to this term when looking for the
`
`broadest reasonable interpretation. See Ex. 1012, pp. 1, 5 (M. Chatel,
`
`Classical versus Transparent IP Proxies, RFC 1919 (Mar. 1996)); see
`
`also Ex. 1013, p. 10 (R. Fielding et al., Hypertext Transfer Protocol --
`
`HTTP/1.1, RFC 2068 (Jan. 1997)).
`
`III. KIUCHI AND COMBINATIONS INVOLVING KIUCHI
`A. KIUCHI
`17.
`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. 1002, 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. 1002, 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.
`
`8
`
`
`
`18. 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 an origin server associated with the
`
`server-side proxy. See Ex. 1002, p. 64, § 2.1. In particular, the client-side
`
`proxy performs various steps on behalf of the user agent to facilitate
`
`communications with an origin server and provides responses to a user
`
`agent’s resource requests. The C-HTTP connection established by the
`
`client-side proxy of Kiuchi relies on HTTP 1.0 exchanges, as would any
`
`regular HTTP communication, and, therefore, the client-side proxy acts
`
`as a client computer in forwarding data requests to the server-side proxy
`
`9
`
`
`
`and as a server in forwarding responses to data requests from the user
`
`agent. See Ex. 1002, p. 67, § 4.2; see also Ex. 1014, p. 5 (T. Berners-Lee
`
`et al., Hypertext Transfer Protocol -- HTTP/1.0, RFC 1945 (May 1996))
`
`(describing proxy as an “intermediary program which acts as both a
`
`server and a client for the purpose of making requests on behalf of other
`
`clients”).
`
`19. Kiuchi describes a number of discrete steps for establishing this
`
`secure C-HTTP connection, and, thus, creating an HTTP-based virtual
`
`network. See Ex. 1002, 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. Each numbered step will be
`
`described in detail with reference to subsequent diagrams created for
`
`explaining Kiuchi in this Declaration.
`
`10
`
`
`
`20. According to Kiuchi, the HTTP-compatible user agent may be
`
`used to display HTML documents to an end-user. See Ex. 1002, 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.current.connection/sample.html=@=6zdDfldfcZLj8V!i.
`
`Id. In this example URL, “server.in.current.connection” is the hostname,
`
`“sample.html” is the name of the resource being requested, and
`
`“6zdDfldfcZLj8V!i” is a connection ID used by the client-side proxy. As
`
`shown in this example, the “hostname” described by Kiuchi is domain
`
`name. When the end user selects the hyperlink in the displayed HTML
`
`11
`
`
`
`document, the user agent sends a request for the URL to the client-side
`
`proxy. See id.
`
`21. 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 (or,
`
`presumably, if a connection ID is not present), the client-side proxy
`
`attempts to resolve the hostname through a query to the C-HTTP name
`
`server, and, if the C-HTTP name server returns an IP address, establishes
`
`a new C-HTTP connection with the host corresponding to the hostname
`
`included in the URL. See id.
`
`22. As part of establishing 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 and, if so, to resolve the
`
`hostname included in the URL such that the corresponding IP address is
`
`returned to the client-side proxy. See Ex. 1002, p. 65, § 2.3(2). In some
`
`instances, the hostname corresponds to an origin server associated with a
`
`server-side proxy and is associated with an IP address for the server-side
`
`12
`
`
`
`proxy. See Ex. 1002, p. 65, § 2.3. In other instances, the hostname instead
`
`corresponds to a server on the Internet outside the C-HTTP network. See
`
`Ex. 1002, p. 65, § 2.3
`
`23. Upon receipt of the request, the C-HTTP name server first
`
`authenticates the client-side proxy to determine if the query is legitimate.
`
`Id. When the request 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 a 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.
`
`If, on the other hand, the server-side proxy 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 standard/public DNS server. See id. The
`
`standard/public DNS server then returns an IP address of the host
`
`corresponding to the hostname, which the client-side proxy uses to
`
`connect to the host on behalf of the user agent. See Ex. 1002, p. 65, § 2.3
`
`24.
`
`To summarize, Diagram 3 illustrates: (1) a request sent from the
`
`user agent to the client-side proxy for a URL including a hostname; (2) a
`
`request from the client-side proxy to the C-HTTP name server for
`
`13
`
`
`
`information necessary to establish a C-HTTP connection with the server-
`
`side proxy associated with the host name included in the URL (when a C-
`
`HTTP connection does not already exist), the necessary information
`
`including the IP address of a server-side proxy corresponding to the
`
`hostname; and (3) a response from the C-HTTP name server that either
`
`includes the IP address associated with the server-side proxy or an error
`
`message. If the C-HTTP server returns an error message, then the client-
`
`side proxy performs a DNS lookup using the standard/public DNS, as
`
`illustrated by the dashed line.
`
`14
`
`
`
`25. Kiuchi describes the C-HTTP name server as performing name
`
`resolution for the C-HTTP private network. See Ex. 1002, p. 64, § 2.1. To
`
`that end, Kiuchi describes: “When a given institution wants to participate
`
`in a closed network, it must 1) install a client-side and/or server-side
`
`proxy on its firewall, 2) register 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) for a firewall gateway, 3) give the
`
`proxy’s public key to the C-HTTP name server, and 4) obtain the C-
`
`HTTP name server’s public key.” Ex. 1002, p. 65, § 2.2. Notably, the IP
`
`address registered with the C-HTTP name server is the IP address of the
`
`server-side proxy, not the origin server. See id. Therefore, the C-HTTP
`
`name server never provides the true IP address of the origin server to the
`
`client-side proxy. Rather, Kiuchi discloses that “[f]rom the view of the
`
`user agent [and] client-side proxy, all resources appear to be located in a
`
`server-side proxy on the firewall. In reality, however, the server-side
`
`proxy forwards requests to the origin server.” Ex. 1002, p. 66. Therefore,
`
`the true IP address of the origin server (i.e., a secure server) is never sent
`
`to either the user agent or the client-side proxy.
`
`26.
`
`In the event the C-HTTP name server returns the IP address of
`
`the server-side proxy along with the server-side proxy’s public key and
`
`15
`
`
`
`the nonce values, the client-side proxy determines that the hostname
`
`corresponds to a secure server in the C-HTTP network and attempts to
`
`establish a C-HTTP connection with a server-side proxy using the IP
`
`address received from the C-HTTP name server. See Ex. 1002, p. 65, §
`
`2.3. The steps for doing so are illustrated in Diagram 4.
`
`27.
`
`In particular, Kiuchi describes that the client-side proxy, in
`
`response to receiving the IP address of the server-side proxy and other
`
`information 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” with the C-HTTP name server (5 and 6), and the server-side
`
`proxy sends 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. 1002, pp. 65-66, § 2.3.
`
`16
`
`
`
`28.
`
`In more detail, the client-side proxy, in response to receiving
`
`the IP address and associated information from the C-HTTP server, sends
`
`a request for connection to the server-side proxy, as illustrated by (4) in
`
`Diagram 4. See Ex. 1002, p. 65, § 2.3. The client-side proxy encrypts the
`
`request for connection using the server-side proxy’s public key and
`
`includes in the request “the client-side proxy's IP address, hostname,
`
`request Nonce value and symmetric data exchange key for request
`
`encryption.” See Ex. 1002, p. 65, § 2.3. After receiving the request, the
`
`server-side proxy “asks the C-HTTP name server whether the client-side
`
`proxy is an appropriate member of the closed network,” as illustrated by
`
`(5) in Diagram 4, and, in response, the C-HTTP name server “examines
`
`17
`
`
`
`whether the client-side proxy is permitted to access the server-side
`
`proxy.” Ex. 1002, pp. 65-66, § 2.3. If the C-HTTP server determines that
`
`“access is permitted, the C-HTTP name server sends [to the server-side
`
`proxy] the IP address and public key of the client-side proxy and both
`
`request and response Nonce values,” as illustrated by (6) in Diagram 4.
`
`Ex. 1002, p. 66, § 2.3.
`
`29. After “the C-HTTP name server provides both client-side and
`
`server-side proxies with each peer’s public key,” the proxies establish a
`
`C-HTTP connection. Ex. 1002, p. 65, § 2.2, p. 66, § 2.3(5). The C-HTTP
`
`connection “provides [a] secure HTTP communication mechanisms” in
`
`which communications over the C-HTTP connection are encrypted. Ex.
`
`1002, pp. 64-66, abstract; p. 66, FIG. c, pp. 72-73; Appendix 2
`
`(highlighting encrypted portions of C-HTTP communications with a ‘*’).
`
`Communications between the user agent and the client-side proxy as well
`
`as those between the original server and the server-side proxy are behind
`
`the firewall of their respective site, and therefore protected (Ex. 1002, p.
`
`64 Sec. 2.1 ll. 2-3). This, together with the security afforded by the
`
`encrypted C-HTTP connection over the public communication path
`
`between the client-side proxy and the server-side proxy, ensures that
`
`communications between the user agent and the origin server are over a
`
`18
`
`
`
`secure channel. Both the server-side proxy and origin server are secure
`
`servers, because a user agent and its associated client-side proxy must be
`
`authorized to communicate with the server-side proxy and origin server,
`
`and the C-HTTP connection that is created for such communications is a
`
`secure, encrypted channel.
`
`30.
`
`The operations of the client-side proxy to determine whether a
`
`request from the user agent is to a secure server within the C-HTTP
`
`network and the establishment of the C-HTTP connection are transparent
`
`to the user agent. See Ex. 1002, p. 68, § 4.2. In particular, Kiuchi
`
`describes that the user agent and origin server operate solely based on
`
`standard HTTP/1.0 (as if the C-HTTP system did not exist), and, thus,
`
`“C-HTTP is transparent to both of them.” See id. Accordingly, the
`
`efforts of the client-side proxy to establish a secure connection with the
`
`corresponding server-side proxy are “automatic” from the perspective of
`
`the user agent, since the user agent simply issues a standard HTTP/1.0
`
`request for content on the origin server and awaits a response.
`
`31. Having established the C-HTTP connection, the client-side
`
`proxy uses the C-HTTP connection to communicate access requests from
`
`the user agent to the server-side proxy. See Ex.1002, p. 66, § 2.3, step 6.
`
`The C-HTTP connection is an encrypted channel between the user agent
`
`19
`
`
`
`and
`
`the origin server. In particular, Kiuchi describes
`
`that all
`
`communications over the Internet between the client-side proxy and
`
`server-side proxy (i.e., the public communication path between the user
`
`agent and the origin server) are encrypted. See Ex. 1002, pp. 65-66, §§
`
`2.3(3), (5), (6).
`
`B. COMBINATION OF KIUCHI AND RESCORLA
`32. As described above, Kiuchi describes a C-HTTP connection
`
`between the client-side proxy and the server-side proxy. Kiuchi also
`
`describes that this connection “provides [a] secure HTTP communication
`
`mechanisms” in which communications over the C-HTTP connection are
`
`encrypted. Ex. 1002, p. 64-66, Abstract. In addition to the C-HTTP
`
`connection, one of skill in the art, based on Kiuchi and an Internet-Draft
`
`by E. Rescorla and A. Schiffman entitled “The Secure Hypertext Transfer
`
`Protocol” published in Febuary 1996 (hereinafter “Rescorla”) which, as
`
`discussed below in ¶ 51, was part of the development of RFC 2660,
`
`would have been motivated to employ end-to-end encryption between the
`
`user agent and the origin server, and would have found doing so to be a
`
`straightforward design choice. In fact, Kiuchi contemplates this very
`
`implementation.
`
`20
`
`
`
`33.
`
`In particular, Kiuchi itself teaches that, “[a]lthough the current
`
`C-HTTP implementation assumes the use of HTTP/1.0 compatible user
`
`agents and servers, it is possible to develop C-HTTP proxies which can
`
`communicate with other secure HTTP compatible user agents and
`
`servers.” Ex. 1002, p. 69, § 4.4. To permit this, Kiuchi describes that C-
`
`HTTP “can co-exist with” other secure HTTP proposals. See id. Kiuchi
`
`further states that this would be beneficial because it assures both
`
`institutional and personal level security: “[i]f C-HTTP is used with these
`
`protocols, which assure end-to-end or
`
`individual security, both
`
`institutional and personal level security protection can be provided.” Id.
`
`As an example of a secure HTTP protocol that can be used at a user agent
`
`and at an origin server, Kiuchi explicitly refers to an early Internet Draft
`
`that was also part of the development of RFC 2660. See Ex. 1002, p. 70,
`
`n 12.
`
`34. Rescorla discloses the use of encryption between clients and
`
`servers: “Secure HTTP (S-HTTP) provides secure communication
`
`mechanisms between an HTTP client-server pair in order to enable
`
`spontaneous commercial transactions for a wide range of applications.”
`
`Ex. 1004 at § 1. “S-HTTP provides full flexibility of cryptographic
`
`algorithms, modes and parameters.” Ex. 1004 at § 1.1. The combination
`
`21
`
`
`
`of Kiuchi and Rescorla would result in encrypted communications
`
`between the user agent and origin server using S-HTTP messages instead
`
`of standard HTTP/1.0 messages. In this way, the use of S-HTTP could
`
`simply replace HTTP 1.0 within the C-HTTP security scheme described
`
`by Kiuchi. As described by Kiuchi, “[t]his means that even if individual
`
`security management is not sufficient, data security can be guaranteed. In
`
`this case, administrators of proxies on the firewall cannot know the
`
`contents of any information exchanged.” Ex. 1002, p. 69, § 4.4. In other
`
`words, Kiuchi itself provides the motivation for combining the C-HTTP
`
`system described by Kiuchi with the S-HTTP protocol described in
`
`Rescorla.
`
`35.
`
`In the combination of Kiuchi and Rescorla, upon receipt of an
`
`S-HTTP compliant request from the user agent for information stored on
`
`an origin server, the client-side proxy would automatically establish a C-
`
`HTTP connection with the server-side proxy, as described above, and the
`
`exchange of the S-HTTP messages would ensure end-to-end encryption
`
`between the user agent and origin server. If, on the other hand, the user
`
`agent is requesting information from a non-secure server outside the C-
`
`HTTP network that does not implement S-HTTP, the user agent would
`
`communicate using standard HTTP. See Ex. 1004 at § 1.1 (“S-HTTP
`
`22
`
`
`
`supports interoperation among a variety of implementations, and is
`
`compatible with HTTP. S-HTTP aware clients can communicate with S-
`
`HTTP oblivious servers and vice-versa, although such transactions
`
`obviously would not use S-HTTP security features.”)
`
`36.
`
`Therefore, based on the motivation provided in Kiuchi, it would
`
`have been an obvious design choice to one of ordinary skill in the art to
`
`incorporate the cryptography provided by Secure HTTP, as taught by
`
`Rescorla, into Kiuchi’s user agent and origin server, in order to provide
`
`end-to-end encryption and personal-level security. Therefore, Kiuchi
`
`(which discloses an encrypted/secure C-HTTP connection from the
`
`client-side proxy to the server-side proxy) in view of Rescorla (which
`
`discloses encrypted/secure end-to-end communications between the user
`
`agent and origin server) discloses an encrypted/secure channel that starts
`
`at the user agent (acting as a client) and ends at the origin server (a secure
`
`server).
`
`C. COMBINATION OF KIUCHI AND RFC 1034
`37. As described above, Kiuchi explains that, if a request by a user
`
`agent does not correspond to a domain name of another member of the C-
`
`HTTP network, the client-side proxy performs a conventional DNS
`
`lookup request. See Ex. 1002, p. 65, § 2.3(2). In this instance, the
`
`23
`
`
`
`function of DNS proxy is distributed among the client-side proxy and the
`
`C-HTTP name server. Alternatively, a person of ordinary skill in the art
`
`would have recognized that this conventional DNS lookup step could
`
`also be implemented by making a simple adaptation of the C-HTTP name
`
`server shown in Kiuchi, and that person would know how to do that
`
`based on the guidance in RFC 1034 (Ex. 1005).
`
`38.
`
`Specifically, the C-HTTP name server, which already performs
`
`a DNS look-up for secure pages, could be modified to also perform a
`
`DNS look-up for non-secure pages. It would have been an obvious and
`
`straightforward design choice to consolidate all domain name resolution
`
`functions in the C-HTTP name server, as this would simplify and
`
`streamline the functions performed by the Kiuchi system. RFC 1034
`
`notes that, “[i]n any system that has a distributed database, a particular
`
`name server may be presented with a query that can only be answered by
`
`some other server.” Ex. 1005, p. 4. Thus, RFC 1034 outlines two general
`
`approaches for dealing with such queries: a “recursive” approach and an
`
`“iterative” approach. In the “iterative” approach rather than itself
`
`resolving the query, the server lets the client pursue the query. Ex. 1005,
`
`p. 4. This iterative approach is akin to the one described by Kiuchi as
`
`being used by the C-HTTP name server, which returns an error to the
`
`24
`
`
`
`client-side proxy when it cannot resolve the requested domain name and
`
`the client-side proxy turns to a conventional DNS server. See Ex. 1002, p.
`
`65, § 2.3(2). On the other hand, in the “recursive” approach taught by
`
`RFC 1034, “the first server pursues the query for the client at another
`
`server.” Ex. 1005, p. 4. The recursive mode is the “simplest mode for the
`
`client.” Ex. 1005, p. 21. On pages 21 and 22, RFC 1034 outlines the
`
`structure of a recursive name service.
`
`39.
`
`There is no practical or functional consequence for a user,
`
`based on where the name resolution step is performed. For example, the
`
`C-HTTP name server already determines whether the DNS request
`
`received from the client-side proxy is requesting access to a secure target
`
`web site within the C-HTTP system. See Ex. 1002 p. 65, § 2.3(2). Rather
`
`than returning an error status to the client-side proxy when the DNS
`
`request is not requesting access to a secure target web site, it would have
`
`been trivial to have the C-HTTP name server recursively pass the domain
`
`name received in the C-HTTP name service request to a conventional
`
`DNS server for name resolution, as described in RFC 1034. See Ex.
`
`1005, pp. 21-22.
`
`40.
`
`Such a modification of Kiuchi’s client-side proxy and C-HTTP
`
`name server would have been a straightforward design choice based on
`
`25
`
`
`
`the guidance in RFC 1034. On pages 21 and 22, RFC 1034 outlines the
`
`manner in which a name server may implement a recursive resolution
`
`process. Applied to the client-side proxy and C-HTTP name server, the
`
`C-HTTP name server could be configured to first determine whether a
`
`host name for which resolution is sought by the client-side proxy is
`
`registered as part of the C-HTTP closed network. If it is, the C-HTTP
`
`name server will return the IP address, encryption key, and nonce values
`
`as described by Kiuchi. However, if the host name being resolved is not
`
`part of the C-HTTP closed network, the C-HTTP name server would
`
`make a query for the hostname to a standard/public DNS server on the
`
`client-side proxy’s behalf. If the C-HTTP name server is able to resolve
`
`the hostname through this standard DNS query, it would return the IP
`
`address to the client-side proxy. Otherwise, the C-HTTP name server
`
`would return an error.
`
`41.
`
`The client-side proxy would be modified to recognize the
`
`difference between a response from
`
`the C-HTTP name server
`
`corresponding to a secure destination within the C-HTTP network and a
`
`standard destination resolved through the conventional DNS. 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
`
`26
`
`
`
`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) could indicate to the
`
`client-side proxy that the DNS request is not requesting access to a secure
`
`target web site and hence that no VPN is needed.
`
`42.
`
`These types of modifications to the client-side proxy and C-
`
`HTTP name server were well within the ability of a person of ordinary
`
`skill in the art by 2000.
`
`43. One of ordinary skill in the art would have been motivated to
`
`modify Kiuchi
`
`in this way because doing so would streamline the
`
`operation of the system. For example, instead of having the C-HTTP
`
`name server send an error status to the client-proxy which would in turn
`
`initiate a standard/public 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 standard/public DNS server.
`
`Therefore, the implementation of a recursive C-HTTP name server would
`
`recognize the benefits identified by RFC 1034. See Ex. 1005, p. 21.
`
`D. D. COMBINATION OF KIUCHI, RESCORLA AND RFC
`1034
`The obvious modifications to Kiuchi in light of Rescorla
`
`44.
`
`discussed in
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
