`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`In re
`
`Inter Partes Review of
`
`US. Patent No.: 6,502,135
`Inventors: Munger et a].
`Issue Date: Dec. 31, 2002
`
`Trial Number: IPR20 1 3—003 75
`
`Title: Agile Network Protocol for Secure Communications With Assured System
`Availability
`
`Attorney Docket No. 3959/5 001
`
`
`Attn: Mail Stop PATENT BOARD
`Patent Trial and Appeal Board
`United States Patent and Trademark Office
`
`PO Box 1450
`
`Alexandria, Virginia 22313—1450
`
`Declaration of Russell Housley Regarding US. Patent No. 6,502,135
`
`1, Russell Housley, do hereby declare and state, that all statements made
`
`herein of my own knowledge are true and that all statements made on information
`
`and belief are believed to be true; and filrther that these statements were made with
`
`the knowledge that willful false statements and the like so made are punishable by
`
`fine or imprisonment, or both, under Section 1001 of Title 18 of the United States
`
`Code.
`
`Dated:
`
`
`
`22 fume“ 20:5 %4
`
`xxx
`
`New Bay Capital, LLC-EX.1009
`
`New Bay Capital, LLC-EX.1009
`
`
`
`I, Russell Housley, declare as follows:
`
`
`
`I.
`
`
`
`INTRODUCTION
`
`A. Engagement
`
`1.
`
`I have been retained by counsel for New Bay Capital, LLC as an
`
`expert witness in the above-captioned proceeding. I submit this declaration in
`
`support of the Petition for Inter Partes Review (hereinafter “the Petition”) of claims
`
`1, 3, 7 and 8 of United States Patent No. 6,502,135 (hereinafter “the ‘135 Patent” –
`
`Exhibit 1001), filed in the United States Patent and Trademark Office on behalf of
`
`New Bay Capital, LLC.
`
`
`
`B. Background and Qualifications
`
`2.
`
`I am the founder and owner of Vigil Security, LLC, which I founded
`
`in 2002 to help customers design and implement diligently watchful security
`
`solutions. I provide consulting on security protocols, security architectures, and
`
`Public Key Infrastructure (PKI). Over the last ten years, I have performed security
`
`and vulnerability analyses of various communications architectures and security
`
`policies based on known threats and proposed certification criteria.
`
`3.
`
`Since March 2013, I have served as the chair of the Internet Activities
`
`Board (IAB), which is a voting member of the IAB as well as a non-voting
`
`
`
`2
`
`New Bay Capital, LLC-EX.1009
`
`
`
`member of the Internet Engineering Steering Group (IESG), a voting member of
`
`the IETF Administrative Oversight Committee (IAOC), and a Trustee for the IETF
`
`Trust. Since May 2013, I have served as a member of the Internet Research
`
`Steering Group (IRSG).
`
`4.
`
`From March 2007 to March 2013, I served as the chair of the Internet
`
`Engineering Task Force (IETF). I managed the open and transparent technical
`
`standards process for the Internet.
`
`5.
`
`From March 2003 to March 2007, I served as the IETF Security Area
`
`Director, making me a member of the IESG. As such, I provided leadership to
`
`many working groups that were developing security standards for the Internet,
`
`including the Public Key Infrastructure using X.509 (PKIX), IP Security (IPsec),
`
`Transport Layer Security (TLS), Secure MIME (S/MIME), Domain Keys
`
`Identified Mail (DKIM), Long-Term Archive and Notary Services (LTANS), and
`
`Multicast Security (MSEC) working groups.
`
`6.
`
`Prior to accepting the Area Director position, I chaired the IETF
`
`Secure MIME (S/MIME) Working Group, and I contributed to several cornerstone
`
`Internet PKI standards (including RFC 5280). In November 2004, I was recognized
`
`by the IEEE 802.11 working group for my contributions to IEEE 802.11i-2004,
`
`which fixes the severe security shortcoming of the Wired Equivalent Privacy
`
`(WEP). I provided major contributions to several security protocols, including the
`
`
`
`3
`
`New Bay Capital, LLC-EX.1009
`
`
`
`Cryptographic Message Syntax (CMS), SDNS Security Protocol 4 (SP4), SDNS
`
`Message Security Protocol (MSP), IEEE 802.10b Secure Data Exchange (SDE)
`
`Protocol, and IEEE 802.10c Key Management Protocol.
`
`7.
`
`I have worked in the computer and network security field since 1982.
`
`Before starting Vigil Security, I worked at the Air Force Data Services Center
`
`(AFDSC), Xerox Special Information Systems (XSIS), SPYRUS, and RSA
`
`Laboratories. My security research and standards interests include security
`
`protocols, certificate management, cryptographic key distribution, and high
`
`assurance design and development practices. I have been active in many security
`
`standards organizations, and my recent focus has been on the Internet Engineering
`
`Task Force (IETF).
`
`8.
`
`I have served as the Chair of CertiPath Policy Management Authority,
`
`where I assisted with the transition from SHA-1 to SHA-256. I also provided
`
`technical and policy advice to the WiMAX Forum Policy Authority for the PKI
`
`that is used to authenticate WiMAX Devices and the separate PKI that is used to
`
`authenticate the AAA servers within a WiMAX network.
`
`9.
`
`I am a Consultant to the U.S. Government. I helped with Crypto
`
`Modernization activities, especially in the areas of secure firmware loading, trust
`
`anchor management, public key infrastructure, and key management infrastructure.
`
`
`
`4
`
`New Bay Capital, LLC-EX.1009
`
`
`
`10.
`
`I am a member of the Advisory Board for the Georgetown Center for
`
`Secure Communications (GCSC) at Georgetown University, the Security and
`
`Software Engineering Research Center (S2ERC) at Georgetown University, and
`
`the Center for Information Assurance at the University of Dallas, Graduate School
`
`of Management. I am a technical advisor to Penango.
`
`11.
`
`I received a Bachelor of Science in computer science from Virginia
`
`Tech in 1982, and I received a Master of Science degree in computer science from
`
`George Mason University in 1992.
`
`12.
`
`I am the co-author of two books: Implementing Email and Security
`
`Tokens: Current Standards, Tools, and Practices, published by John Wiley & Sons
`
`in 2008, and Planning for PKI – Best Practices Guide for Deploying Public Key
`
`Infrastructure, published by John Wiley & Sons in 2001.
`
`13.
`
`I am the inventor of five U.S. Patents:
`
`i US Patent 6,003,135: Modular security device
`
`i US Patent 6,088,802: Peripheral device with integrated security
`functionality
`
`i US Patent 6,904,523: Method and system for enforcing access to a
`computing resource using a licensing attribute certificate
`
`i US Patent 6,981,149: Secure, easy and/or irreversible customization of
`cryptographic device
`
`i US Patent 7,356,692: Method and system for enforcing access to a
`computing resource using a licensing attribute certificate.
`
`
`
`5
`
`New Bay Capital, LLC-EX.1009
`
`
`
`14. A copy of my curriculum vitae, which describes in further detail my
`
`qualifications, responsibilities, employment history, and publications is attached to
`
`this declaration as Appendix A.
`
`
`
`C. Compensation and Prior Testimony
`
`15.
`
`I am being compensated at my normal consulting rate for my work
`
`and testimony in this matter. I also am being reimbursed for reasonable and
`
`customary expenses associated with my work and testimony in this matter. My
`
`compensation is not contingent on the outcome of this matter or the specifics of my
`
`testimony and in no way affects the substance of my statements in this Declaration.
`
`16.
`
`17.
`
`I have no financial interest in Petitioner or in the ‘135 Patent.
`
`I have never testified in Federal District Court, but I testified in the
`
`U.S. International Trade Commission on January 13, 2012. Also, I was deposed
`
`on May 31, 2005 for a civil action in the U.S. DistrictCourt for the Eastern District
`
`of Virginia, Alexandria Division.
`
`
`
`D. Information Considered and Right to Supplement
`
`18. My opinions are based on my years of education, research and
`
`experience, as well as my investigation and study of relevant materials. In forming
`
`
`
`6
`
`New Bay Capital, LLC-EX.1009
`
`
`
`my opinions, I have reviewed and understand the materials referred to herein or
`
`listed in Appendix B.
`
`
`
`E. Availability for Cross-Examination
`
`19.
`
`In signing this Declaration, I recognize that the Declaration will be
`
`filed as evidence in a contested case before the Patent Trial and Appeal Board of
`
`the United States Patent and Trademark Office. I also recognize that I may be
`
`subject to cross-examination in the case and that cross-examination will take place
`
`within the United States. If cross-examination is required of me, I will appear for
`
`cross-examination within the United States during the time allotted for cross-
`
`examination.
`
`
`
`II. LEGAL STANDARDS AND ANALYSIS
`
`20.
`
`I have reviewed and understand the specification and claims of the
`
`‘135 Patent.
`
`21.
`
`I believe a person of ordinary skill in the art in the field of the ‘135
`
`Patent would be someone who, prior to February 2000, was familiar with TCP/IP
`
`networking principles and Internet Engineering Task Force (IETF) activities in the
`
`areas of DNS, IP Security, and Virtual Private Networks. The person of ordinary
`
`
`
`7
`
`New Bay Capital, LLC-EX.1009
`
`
`
`skill is deemed to have a general knowledge of all relevant prior art including
`
`patents and published patent applications, books, academic papers, and other
`
`publications. The person of ordinary skill in the art may have at least a Bachelor’s
`
`degree in engineering or computer science. The person of ordinary skill in the art
`
`may have worked in academia, for a technology company, or for a government.
`
`
`
`III.
`
`THE ‘135 PATENT
`
`22. For purposes of claims 1, 3, 7 and 8, the ‘135 Patent relates to
`
`automatic creation of a virtual private network (VPN) in response to a domain-
`
`name server look-up function (Ex.1001 at 37:19-21).
`
`23.
`
`In the ‘135 Patent, a DNS request is generated from a client computer
`
`to request an IP address corresponding to a domain name that is associated with a
`
`web site hosted by a server. A determination is made whether the DNS request is
`
`requesting access to a secure web site, e.g., based on a domain name extension, or
`
`by reference to an internal table of such sites. (Ex.1001 at 37:63-38:28). When the
`
`DNS request corresponds to a secure web site, a VPN is automatically initiated
`
`between the client computer and the target computer. (Ex.1001 at 37:64-
`
`38:2). When the DNS request does not correspond to a secure web site/server, a
`
`
`
`8
`
`New Bay Capital, LLC-EX.1009
`
`
`
`look-up function is performed that returns the IP address of the non-secure web
`
`site. (Ex.1001 at 38:6-11).
`
`24. The ‘135 Patent discloses various exemplary embodiments for
`
`implementing such automatic creation of a VPN. With respect to receiving the
`
`DNS request and determining if the request corresponds to a secure web site (e.g.,
`
`the user is authorized to access the secure web site), a DNS server may perform
`
`these steps. (Ex.1001 at 37:64-38:2). In another example, a DNS proxy may
`
`receive the DNS requests and perform the determining. (Ex.1001 at 38:23-25). In
`
`some embodiments, theDNS proxy may reside on a different machine than the
`
`DNS server (Ex.1001 at 38:63-65), and in other embodiments, the DNS proxy and
`
`DNS server may be combined in a single machine. (Ex.1001 at 38:61-63).
`
`25. With respect to creating the encrypted channel (e.g., the VPN), the
`
`DNS server may set up the VPN between the client computer and the
`
`server. (Ex.1001 at 37:63-38:2). Alternatively, a DNS proxy may send a request
`
`to a gatekeeper to create the VPN between the client computer and the
`
`server. (Ex.1001 at 39:42-52). The gatekeeper facilitates the allocation and
`
`exchange of information needed to communicate securely and may send a resolved
`
`address back to the client computer via the DNS proxy. (Ex.1001 at 38:55-57,
`
`39:42-52). In any of these examples, the VPN is established without user
`
`involvement.
`
`
`
`9
`
`New Bay Capital, LLC-EX.1009
`
`
`
`26. As with the DNS proxy and DNS server, the gatekeeper and DNS
`
`server may reside on different machines or be combined on a single
`
`machine. (Ex.1001 at 38:53-55). By extension, any of the DNS proxy, DNS
`
`server, and gatekeeper may be on the same or different machines.
`
`27. With respect to the look-up function, the DNS proxy may send a DNS
`
`request to a DNS server, which performs the look-up to return an IP
`
`address. (Ex.1001 at 38:43-47). In some embodiments, the gatekeeper instructs
`
`the DNS proxy to send the DNS request to the DNS server. (Ex.1001 at 39:61-
`
`40:3).
`
`
`
`IV.
`
`KIUCHI
`
`28. Based on personal experience, I can establish that the article entitled
`
`“C-HTTP – The Development of a Secure, Closed HTTP-based Network on the
`
`Internet,” written by Takahiro Kiuchi and Shigekoto Kaihara (hereinafter “the
`
`Kiuchi paper” or simply “Kiuchi”), was presented to the public at the Symposium
`
`on Network and Distributed Systems Security (SNDSS) in 1996, and the paper was
`
`published in the symposium proceedings, distributed to the participants and made
`
`available to the public. At the time, I was then the Chief Scientist at SPYRUS and
`
`
`
`10
`
`New Bay Capital, LLC-EX.1009
`
`
`
`I gave a presentation as part of a panel discussion in session 4 at the SNDSS
`
`conference. The C-HTTP paper was presented in session 3 of the conference.
`
`29. Similar to the ‘135 Patent, Kiuchi was concerned with establishing
`
`secure network links between different hosts on the Internet. (Ex.1002 at 64). In
`
`particular, the service was contemplated for use by medical institutions for
`
`protecting patient information and other private information of the institutions,
`
`although Kiuchi makes clear that the closed virtual network can be used in other
`
`areas (Ex.1002 at 69, paragraph 5). To facilitate my explanation of Kiuchi, I
`
`present the following figure (Figure 1), which shows the relevant components of
`
`Kiuchi’s system (which Kiuchi calls the “C-HTTP” system):
`
`
`
`
`
`11
`
`New Bay Capital, LLC-EX.1009
`
`
`
`30. Kiuchi creates a closed network over the Internet that allows a user
`
`agent computer to access private web pages (HTML documents) stored on an
`
`origin server (i.e., a “secure target web site”) in the closed network. The user agent
`
`and origin server are members of the closed network constructed over the Internet
`
`using a client-side proxy that performs proxy functions for the user agent and a
`
`server-side proxy that performs proxy functions for the origin server. The client-
`
`side proxy and server-side proxy are installed in firewall devices situated between
`
`the user agent and the origin server, which are unaware of these proxies. (see Ex.
`
`1002 at 64, sec. 2.1).
`
`31. The user agent and the origin server are conventional HTTP/1.0
`
`compatible devices, e.g., “[c]ommunications between two kinds of proxies and
`
`HTTP/1.0 compatible servers/user agents within the firewalls are performed based
`
`on HT'TP/1.0.” (Ex.1002 at 64, sec. 2.1, emphasis added). It is well-known that
`
`HTTP is the communication protocol used to connect to servers on the World
`
`Wide Web. (Ex.1023 at 436). Kiuchi shows an example in which a web page
`
`(HTML document) is sent from origin server to client-side proxy (see Ex.1002 at
`
`66, Figure (a)). The client-side proxy sends a rewritten version of the HTML
`
`document with modified links (URLs or resource names) to the user agent (see
`
`Ex.1002 at 66, Figure (b)). An end-user is able to select and request a modified
`
`link in order to generate an HTTP GET request for the requested web page (see
`
`
`
`12
`
`New Bay Capital, LLC-EX.1009
`
`
`
`Ex.1002 at 65, sec. 2.3(a); Ex.1002 at 66, Figure (c)(1)). Thus, it is clear that
`
`Kiuchi is providing access to private web pages at a secure target web site (i.e., the
`
`origin server).
`
`32. The client-side proxy and server-side proxy work in conjunction with
`
`a C-HTTP name server over the Internet. (Ex.1002 at 64). For permitted secure
`
`communications, the C-HTTP name server is the server that responds to name
`
`service requests by looking up domain names and returning their IP address and
`
`related VPN resources, i.e., public key and Nonce values (Ex.1002 at 65, sec.
`
`2.3(2)). Each proxy is registered with the C-HTTP name server, including a
`
`hostname, IP address, and public key for the proxy. (Ex.1002 at 65, sec. 2.2). The
`
`hostname (domain name) of the server-side proxy is used to access web pages at an
`
`origin server being proxied by the server-side proxy. For non-secure connections,
`
`a conventional DNS name service is used to return IP addresses. Id. Thus, domain
`
`name services are provided by the C-HTTP name server for secure communication
`
`requests and by a conventional DNS for non-secure communication requests.
`
`33. The client-side proxy receives, from the user agent, an HTTP request
`
`specifying a web page (HTML document) stored at the origin server and associated
`
`with a given URL. The URL in the HTTP request has the format
`
`“http://<hostname>/<web page>[connection ID]” (see the sample URL at Ex.1002
`
`at 65, sec. 2.3(1), where “server.in.current.connection” is the hostname (i.e.,
`
`
`
`13
`
`New Bay Capital, LLC-EX.1009
`
`
`
`“domain name”) of the server-side proxy, “sample.html” is a web page stored on
`
`the origin server being proxied by the server-side proxy, and “6zdDfldfcZLj8V!i"
`
`is an optional connection ID).
`
`34. Thus, the functions performed by Kiuchi’s client-side proxy and C-
`
`HTTP name server can be represented as depicted schematically in the following
`
`figure (Figure 2):
`
`
`
`35.
`
`In order to create a VPN, the client-side proxy first determines
`
`whether the HTTP request is directed to a secure target web site in the closed
`
`
`
`14
`
`New Bay Capital, LLC-EX.1009
`
`
`
`network. Specifically, the client-side proxy “asks the C-HTTP name server
`
`whether it can communicate with the host specified in [the] URL” (Ex.1002 at 65,
`
`sec. 2.3(2)), specifically by “[taking] off the connection ID and [forwarding] the
`
`stripped, the original resource name to the server in its request” to the name server.
`
`(Ex.1002 at 65, sec. 2.3(1)). Thus, the client-side proxy extracts the domain name
`
`from the HTTP request and sends the requested domain name to the C-HTTP name
`
`server to request the IP address of the host.
`
`36. Upon receiving the request from the client-side proxy, the name
`
`server “examines whether the requested server-side proxy is registered in the
`
`closed network.” (Ex.1002 at 65, sec. 2.3(2)). The name server returns an IP
`
`address only if the requested server-side proxy is registered in the closed network,
`
`and a secure connection with the server-side proxy is permitted. (Ex.1002 at 65,
`
`sec. 2.3(2)). Along with the IP address, the C-HTTP name server also returns the
`
`public key of the server-side proxy and Nonce values. Id. A Nonce value is a
`
`value used once for security/encryption. The C-HTTP name server generates and
`
`provides the Nonce values, which are later used to establish a secure connection
`
`between the client-side proxy and the server-side proxy. (see Ex. 1002 at 65, sec.
`
`2.2). A Nonce value is used to prevent a replay attack. Id.
`
`37. The client-side proxy uses the public key and Nonce values to create a
`
`secure communication connection (i.e., VPN) with the server-side proxy (Ex.1002
`
`
`
`15
`
`New Bay Capital, LLC-EX.1009
`
`
`
`at 65, sec. 2.3(3)). Specifically, 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, section 2.3(3)). Thus, the VPN is automatically initiated in at least
`
`two ways, first by the C-HTTP name server, which sends the public key and Nonce
`
`values to the client-side proxy to cause creation of the VPN (which is analogous to
`
`the DNS proxy in the ‘135 Patent sending a message to the gatekeeper computer to
`
`request that a VPN be created – see Ex. 1001 at 38:30-33), then by the client-side
`
`proxy, which sends the request for connection to the server-side proxy.
`
`38. When the server-side proxy receives the client-side proxy’s IP
`
`address, the hostname and public key, it authenticates the values and generates a
`
`connection ID as well as a second key for response encryption (Ex.1002 at 65-6,
`
`sec. 2.3(4)). When these are accepted and checked by the client-side proxy, the
`
`secure communication connection is established (Ex.1002 at 66, sec. 2.3(5)).
`
`Security between the proxies is made possible by the public key and Nonce values
`
`provided by the C-HTTP name server.
`
`39. Once the secure communication connection is established, when the
`
`user agent sends an HTTP request to access a secure web page on the origin server
`
`(e.g., the HTTP request shown in Ex.1002 at 66, Figure (c)(1)), the client-side
`
`
`
`16
`
`New Bay Capital, LLC-EX.1009
`
`
`
`proxy forwards the request (e.g., the HTTP request shown in Ex.1002 at 66, Figure
`
`(c)(2)) to the server-side proxy in encrypted form using a C-HTTP format.
`
`(Ex.1002 at 66, sec. 2.3(6). The server-side proxy communicates with the origin
`
`server using HTTP/1.0. Because the hostname in Kiuchi is used to refer to both
`
`the server-side proxy and the secure target web site (i.e., origin server) of the
`
`requested web page, “[f]rom the view of the user agent or 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. It is possible
`
`to map any of the virtual directories on the server-side proxy to any of the
`
`directories in one or more origin servers inside the firewall.” (Ex.1002 at 66, sec.
`
`2.3(7)). Thus, while the origin server is the “secure target web site” being accessed,
`
`the server-side proxy is the “target computer” through which access to the secure
`
`target web site is provided and to which the VPN is created.
`
`40.
`
`If a secure connection with the requested host is not permitted, the
`
`name server instead returns an error status to the client-side proxy. (Ex.1002 at 65,
`
`sec. 2.3(2)). Specifically, in response to determining that the requested server-side
`
`proxy is not registered in the closed network (which indicates that the DNS request
`
`is not requesting access to a secure target web site), the C-HTTP name server
`
`returns to the client-side proxy “a status code which indicates an error.” (Ex.1002
`
`at 65, sec. 2.3(2)). In turn, “[i]f the client-side proxy receives an error status, then
`
`
`
`17
`
`New Bay Capital, LLC-EX.1009
`
`
`
`it performs DNS lookup, behaving like an ordinary HTTP/1.0 proxy.” (Ex.1002 at
`
`65, sec. 2.3(2)). It is well-known that such a DNS lookup involves sending a
`
`request to a DNS server and receiving an IP address back from the DNS server.
`
`(Ex.1010 at 70 et seq.). In this way, the domain name is resolved and the IP
`
`address is returned to the client-side proxy, specifically by the client-side proxy
`
`sending a lookup request to the conventional DNS server which resolves the
`
`domain name and returns the IP address to the client-side proxy. Once the IP
`
`address is obtained, a typical non-secure communication may take place.
`
`41. Kiuchi discloses at least two ways in which a gatekeeper computer is
`
`used for automatically initiating the VPN between the client-side proxy and the
`
`server-side proxy, one in which gatekeeper computer functions are implemented in
`
`the C-HTTP name server, and the other in which gatekeeper computer functions
`
`are implemented in the server-side proxy.
`
`42. With regard to the former, the ‘135 Patent makes clear that the
`
`gatekeeper can be implemented as a function within the DNS server (see Ex.1001
`
`at 38:53-55). As discussed above, the C-HTTP name server automatically initiates
`
`the VPN by sending the C-HTTP name service response to the client-side proxy.
`
`In this context, the C-HTTP name server also performs the functions of a
`
`gatekeeper computer because it allocates VPN resources, e.g., it generates and
`
`provides the request and response Nonce values and returns the public key of the
`
`
`
`18
`
`New Bay Capital, LLC-EX.1009
`
`
`
`server-side proxy and the request and response Nonce values to the client-side
`
`proxy. (Ex.1002 at 65, sec. 2.2).
`
`43. With regard to the latter, as discussed above, Kiuchi’s client-side
`
`proxy automatically initiates the VPN by sending a request for connection to the
`
`server-side proxy. In this context, the server-side proxy also performs functions of
`
`a gatekeeper computer because it receives a request for connection from the client-
`
`side proxy (which is analogous to the gatekeeper computer in the ‘135 Patent
`
`receiving a message from the DNS proxy requesting that a VPN be created –
`
`Ex.1001 at 38:30-33) and allocates VPN resources such as a Connection ID and a
`
`second symmetric data exchange key that are used in establishing a secure
`
`connection between the client-side proxy and the server-side proxy. (see Ex.1002
`
`at 66, sec. 2.3(4)-(5)). In order to create the VPN, the server-side proxy (i.e., the
`
`gatekeeper) has to accept the request for connection from the client-side proxy,
`
`authenticate the client-side proxy, check the integrity of the Nonce values, and
`
`generate a connection ID and other parameters for the VPN (Ex.1002 at 65(4)-
`
`66(5)). Under the broadest reasonable interpretation, the gatekeeper computer can
`
`be a function in the target computer.
`
`44. A person of ordinary skill in the art would have understood that
`
`devices such as the client-side proxy device, the server-side proxy device, and the
`
`C-HTTP name server device are data processing devices and that functions
`
`
`
`19
`
`New Bay Capital, LLC-EX.1009
`
`
`
`performed in such devices are necessarily stored in computer program code in
`
`memory, as is the case for any such processing device. A person of ordinary art
`
`also would have understood that several elements claimed in the ‘135 Patent – e.g.,
`
`client computer, DNS proxy server, target computer, and gatekeeper computer –
`
`encompass implementation of such elements in software modules. Such software
`
`modules can reside on separate machines or be combined in ways where various
`
`functions reside on the same machine. This is the nature of software, where
`
`developers generally have great leeway in how to divide functions into software
`
`modules and where to place the software modules. Kiuchi also teaches to an
`
`ordinarily skilled artisan that the functions of a “DNS proxy server” can be
`
`included in the same machine as the client computer (i.e., the client-side proxy
`
`machine) or in a DNS server such as the C-HTTP name server, and that the
`
`functions of a “gatekeeper computer” can be included in the server-side proxy or
`
`the C-HTTP server.
`
`45. Moreover, it would have been a matter of design choice to a person of
`
`ordinary skill in the art to consolidate domain name resolution functions in
`
`Kiuchi’s C-HTTP name server. Kiuchi clearly recognizes and discloses that a
`
`conventional DNS lookup is needed when access is not being requested to a secure
`
`target web site, i.e., when the requested server-side proxy is not registered in the
`
`closed network. (Ex.1002 at 65, sec. 2.3(2)). This is identical to the ‘135 Patent,
`
`
`
`20
`
`New Bay Capital, LLC-EX.1009
`
`
`
`where a DNS lookup is performed when access is not being requested to a secure
`
`target web site. (ex.1001 at 38:43-47).
`
`46. 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 target web site.
`
`Rather than returning an error status to the client-side proxy when the DNS request
`
`is not requesting access to a secure target web site, it would have been trivial and
`
`obvious as a mere design choice for the C-HTTP name server to pass the domain
`
`name received in the C-HTTP name service request to the conventional DNS
`
`server, as depicted in the following figure (Figure 3):
`
`
`
`21
`
`New Bay Capital, LLC-EX.1009
`
`
`
`
`
`47. Such a configuration, which places a DNS proxy server function in a
`
`modified C-HTTP name server, is merely a rearrangement of existing functions
`
`within the C-HTTP system and could be implemented with or without modifying
`
`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
`
`keyandNoncevaluesarenotprovided)wouldindicatetotheclient-sideproxythat
`
`
`
`22
`
`New Bay Capital, LLC-EX.1009
`
`
`
`the DNS request is not requesting access to a secure target web site and hence that
`
`no VPN is needed. The motivation for modifying Kiuchi in this way would have
`
`been to streamline the operation of the system, e.g., instead of having the C-HTTP
`
`name server send an error status to the client-proxy which would in turn initiate a
`
`conventional DNS inquiry, the modification eliminates the error status message
`
`from the process by having the C-HTTP name server directly initiate the request to
`
`the conventional DNS server.
`
`48.
`
`I have gone through the claims in view of Kiuchi as discussed in
`
`paragraphs 29-47 above and have set forth the correspondence between them,
`
`element by element, as set forth in the claim chart attached as Appendix C.
`
`49. Additionally, Kiuchi’s client-side proxy performs a “resolver”
`
`function that receives a domain name resolution request from an internal client
`
`(i.e., the domain name extracted from the received HTTP request) and returns an
`
`IP address for the domain name. The client and resolver functions performed by
`
`Kiuchi’s client-side proxy can be represented as depicted schematically in the
`
`following figure (Figure 4):
`
`
`
`23
`
`New Bay Capital, LLC-EX.1009
`
`
`
`
`
`50. Prior to February 2000, it was well-known for a client function of a
`
`client computer (e.g., an application such as a web browser) to request domain
`
`name resolution from a resolver function in the client computer. For example,
`
`client applications running on Windows and Unix operating systems made function
`
`calls to the operating system (specifically, the “gethostbyname” function) in order
`
`to obtain an IP address for a given hostname (see Ex.1004 – “From an
`
`application’s point of view, access to the DNS is through a resolver …. The
`
`[gethostbyname(3) library function] takes a hostname and returns an IP
`
`address…The resolver contacts one or more name servers to do the mapping”).
`
`Ex.1005 at 112 describes error return codes from gethostbyname() and
`
`
`
`24
`
`New Bay Capital, LLC-EX.1009
`
`
`
`gethostbyaddr() library functions “when using the resolver.” Ex.1006 describes
`
`the gethostbyname eCos system library function. Ex.1007 at 2:63-3:8 states that
`
`"When a user program, such as the browser, requests information ... a resolution
`
`request is passed in the form of a query to the resolver." Ex.1008 at 9:49-54 states
`
`that "Access to the DNS is through a resolver and software library functions. The
`
`function in this case takes a domain name or host name and returns an IP address."
`
`51. Thus, in Kiuchi, an internal resolution request 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. This internal resolution
`
`request is a domain name service request because it is a communication that
`
`contains a domain name and requests an IP address for the domain name.
`
`52. 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 ‘135
`
`Patent. The DNS proxy server of the ‘135 Patent receives a DNS request,
`
`determines whether access to a secure web site has been requeste