Filed on behalf of: VirnetX Inc.
`By:
`
`Joseph E. Palys
`Paul Hastings LLP
`875 15th Street NW
`Washington, DC 20005
`Telephone: (202) 551-1996
`Facsimile: (202) 551-0496
`E-mail: josephpalys@paulhastings.com
`
`
`
`Naveen Modi
`Paul Hastings LLP
`875 15th Street NW
`Washington, DC 20005
`Telephone: (202) 551-1990
`Facsimile: (202) 551-0490
`E-mail: naveenmodi@paulhastings.com
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`
`
`
`
`THE MANGROVE PARTNERS MASTER FUND, LTD., APPLE INC., and
`BLACK SWAMP IP, LLC,
`Petitioner
`
`v.
`
`VIRNETX INC.
`Patent Owner
`
`
`
`
`
`
`
`
`Case IPR2015-010471
`Patent 7,490,151
`
`
`
`
`
`
`
`
`Declaration of Fabian Monrose, Ph.D.
`
`
`
`
`1 Apple Inc. and Black Swamp IP, LLC, who filed petitions in IPR2016-00063 and
`IPR2016-00167, respectively, have been joined as a Petitioner in the instant
`proceeding.
`
`
`
`1
`
`VIRNETX EXHIBIT 2038
`Mangrove v. VirnetX
`Trial IPR2015-01047
`
`Page 1 of 51
`
`

`
`Case No. IPR2015-01047
`
`Table of Contents
`
`I.
`
`II.
`
`Introduction ...................................................................................................... 4
`
`Resources Consulted ........................................................................................ 4
`
`III. Background and Qualifications ....................................................................... 5
`
`IV. Level of Ordinary Skill ..................................................................................10
`
`V.
`
`Claim Terms ..................................................................................................11
`
`A.
`
`B.
`
`C.
`
`D.
`
`E.
`
`F.
`
`G.
`
`“DNS Request” (Claims 1, 7, and 13) .................................................11
`
`“Determining” (Claims 1, 7, 13) .........................................................12
`
`“Secure Server” (Claims 1, 2, 6-8, 12-14) ..........................................13
`
`“Client” (Claims 1, 2, 6-8, 12-14) .......................................................14
`
`“Between [A] and [B]” (Claims 1, 2, 6-8, 12-14) ...............................17
`
`Domain Name ......................................................................................17
`
`“Automatically Initiating/Creating an Encrypted/Secure
`Channel” (Claims 1, 6, 7, 12, 13) ........................................................18
`
`VI. Kiuchi.............................................................................................................18
`
`A. Kiuchi’s Disclosure .............................................................................18
`
`B.
`
`Claim 1 ................................................................................................21
`
`1.
`
`2.
`
`3.
`
`Kiuchi Does Not Disclose the Recited DNS Features ..............21
`
`Kiuchi Does Not Disclose “Determining Whether the
`Intercepted DNS Request Corresponds to a Secure
`Server”.......................................................................................23
`
`Kiuchi Does Not Disclose “Automatically Initiating an
`Encrypted Channel Between the Client and the Secure
`Server”.......................................................................................24
`
`2
`
`Page 2 of 51
`
`

`
`Case No. IPR2015-01047
`
`4.
`
`Kiuchi Does Not Disclose a “Domain Name Server
`(DNS) Proxy Module” that Performs the Recited Claim
`Steps “for Each Intercepted DNS Request” ..............................28
`
`C.
`
`Claims 7 and 13 ...................................................................................29
`
`D. Dependent Claims 2, 6, 8, 12, and 14 .................................................30
`
`VII. Kiuchi and RFC 1034 and/or Rescorla ..........................................................32
`
`VIII. Conclusion .....................................................................................................33
`
`
`
`
`
`3
`
`Page 3 of 51
`
`

`
`Case No. IPR2015-01047
`
`I, FABIAN MONROSE, declare as follows:
`
`I.
`
`Introduction
`I have been retained by VirnetX Inc. (“VirnetX”) for this inter partes
`
`1.
`
`review proceeding. I understand that this proceeding involves U.S. Patent No.
`
`7,490,151 (“the ’151 patent”). I understand the ’151 patent is assigned to VirnetX
`
`and that it is part of a family of patents that stems from U.S. provisional
`
`application nos. 60/106,261 (“the ’261 application”), filed on October 30, 1998,
`
`and 60/137,704 (“the ’704 application”), filed on June 7, 1999. I understand that
`
`the ’151 patent is a division of U.S. application no. 09/504,783, filed February 15,
`
`2000 (now U.S. Patent No. 6,502,135), which is a continuation-in-part of U.S.
`
`application no. 09/429,643 filed October 29, 1999 (now U.S. Patent No.
`
`7,010,604), which claims priority to the ’261 and ’704 applications.
`
`II. Resources Consulted
`I have reviewed the ’151 patent, including claims 1-16. I have also
`2.
`
`reviewed the decisions to institute inter partes review (“IPR”) in IPR2015-01047
`
`(Paper No. 11, the “Decision”), in IPR2016-00063 (Paper No. 29, the “00063
`
`Decision”), and in IPR2016-00167 (Paper No. 12 in IPR2016-00167, the “00167
`
`Decision”); and the petitions for IPR filed by The Mangrove Partners Master Fund,
`
`Ltd. in IPR2015-01047 (the “Petition”), by Apple Inc. in IPR2016-00063 (the
`
`4
`
`Page 4 of 51
`
`

`
`Case No. IPR2015-01047
`
`“Apple Petition”), and by Black Swamp IP, LLC in IPR2016-00167 (the “Black
`
`Swamp Petition”).
`
`3.
`
`I understand that in this proceeding the Board instituted review of the
`
`’151 patent on four grounds: (1) anticipation of claims 1, 2, 6-8, and 12-14 over
`
`Kiuchi; (2) obviousness of claims 1, 2, 6-8, and 12-14 over Kiuchi and RFC 1034;
`
`(3) obviousness of claims 1, 2, 6-8, and 12-14 over Kiuchi and Rescorla; and (4)
`
`obviousness of claims 1, 2, 6-8, and 12-14 over Kiuchi, RFC 1034, and Rescorla. I
`
`have reviewed the exhibits and other documentation supporting the Petition that
`
`are relevant to the Decision and the instituted grounds, and any other material that I
`
`reference in this declaration.
`
`III. Background and Qualifications
`I have a great deal of experience and familiarity with computer and
`4.
`
`network security, and have been working in this field since 1993 when I entered
`
`the Ph.D. program at New York University.
`
`5.
`
`I am currently a Professor of Computer Science at the University of
`
`North Carolina at Chapel Hill. I also hold an appointment as the Director of
`
`Computer and Information Security at the Renaissance Computing Institute
`
`(RENCI). RENCI develops and deploys advanced technologies to facilitate
`
`research discoveries and practical innovations. To that end, RENCI partners with
`
`researchers, policy makers, and technology leaders to solve the challenging
`
`5
`
`Page 5 of 51
`
`

`
`Case No. IPR2015-01047
`
`problems that affect North Carolina and our nation as a whole. In my capacity as
`
`Director of Computer and Information Security, I
`
`lead
`
`the design and
`
`implementation of new platforms for enabling access to, and analysis of, large and
`
`sensitive biomedical data sets while ensuring security, privacy, and compliance
`
`with regulatory requirements. At RENCI, we are designing new architectures for
`
`securing access to data (e.g., using virtual private networks and data leakage
`
`prevention technologies) hosted among many different institutions. Additionally, I
`
`serve on RENCI’s Security, Privacy, Ethics, and Regulatory Oversight Committee
`
`(SPOC), which oversees the security and regulatory compliance of technologies,
`
`designed under the newly-formed Data Science Research Program and the Secure
`
`Medical Research Workspace.
`
`6.
`
`I received my B.Sc. in Computer Science from Barry University in
`
`May 1993. I received my MSc. and Ph.D. in Computer Science from the Courant
`
`Institute of Mathematical Sciences at New York University in 1996 and 1999,
`
`respectively. Upon graduating from the Ph.D. program, I joined the Systems
`
`Security Group at Bell Labs, Lucent Technologies. There, my work focused on the
`
`analysis of
`
`Internet Security
`
`technologies
`
`(e.g.,
`
`IPsec and client-side
`
`authentication) and applying
`
`these
`
`technologies
`
`to Lucent’s portfolio of
`
`commercial products. In 2002, I joined the Johns Hopkins University as Assistant
`
`Professor in the Computer Science department. I also served as a founding
`
`6
`
`Page 6 of 51
`
`

`
`Case No. IPR2015-01047
`
`member of the Johns Hopkins University Information Security Institute (JHUISI).
`
`At JHUISI, I served a key role in building a center of excellence in Cyber Security,
`
`leading efforts in research, education, and outreach.
`
`7.
`
`In July of 2008, I joined the Computer Science department at the
`
`University of North Carolina (UNC) Chapel Hill as Associate Professor, and was
`
`promoted to Full Professor four years later. In my current position at UNC Chapel
`
`Hill, I work with a large group of students and research scientists on topics related
`
`to cyber security. My former students now work as engineers at several large
`
`companies, as researchers in labs, or as university professors themselves. Today,
`
`my research focuses on applied areas of computer and communications security,
`
`with a focus on traffic analysis of encrypted communications (e.g., Voice over IP);
`
`Domain Name System (DNS) monitoring for performance and network abuse;
`
`network security architectures for traffic engineering; biometrics and client-to-
`
`client authentication techniques; computer forensics and data provenance; runtime
`
`attacks and defenses for hardening operating system security; and large-scale
`
`empirical analyses of computer security incidents. I also regularly teach courses in
`
`computer and information security.
`
`8.
`
`I have published over 80 papers in prominent computer and
`
`communications security publications. My research has received numerous
`
`awards, including the Best Student Paper Award (IEEE Symposium on Security &
`
`7
`
`Page 7 of 51
`
`

`
`Case No. IPR2015-01047
`
`Privacy, July, 2013), the Outstanding Research in Privacy Enhancing Technologies
`
`Award (July, 2012), the AT&T Best Applied Security Paper Award (NYU-Poly
`
`CSAW, Nov., 2011), and the Best Paper Award (IEEE Symposium on Security &
`
`Privacy, May, 2011), among others. My research has also received corporate
`
`sponsorship, including two Google Faculty Research Awards (2009, 2011) for my
`
`work on network security and computer forensics, as well as an award from
`
`Verisign Inc. (2012) for my work on DNS.
`
`9.
`
`I am the sole inventor or a co-inventor on three issued US patents and
`
`four pending patent applications, nearly all of which relate to network and systems
`
`security. Over the past 12 years, I have been the lead investigator or a
`
`co-investigator on grants totaling nearly nine million US dollars from the National
`
`Science Foundation (NSF), the Department of Homeland Security (DHS), the
`
`Department of Defense (DoD), and industry. In 2014, I was invited to serve on the
`
`Information Science and Technology (ISAT) study group for the Defense
`
`Advanced Research Projects Agency (DARPA). During my
`
`three year
`
`appointment, I will assist DARPA by providing continuing and independent
`
`assessment of the state of advanced information science and technology as it
`
`relates to the U.S. Department of Defense.
`
`10.
`
`I have chaired several international conferences and workshops,
`
`including for example, the USENIX Security Symposium, which is the premier
`
`8
`
`Page 8 of 51
`
`

`
`Case No. IPR2015-01047
`
`systems-security conference for academics and practitioners alike. Additionally, I
`
`have also served as Program Chair for the USENIX Workshop on Hot Topics in
`
`Security, the Program Chair for the USENIX Workshop on Large-scale Exploits &
`
`Emergent Threats, the local arrangements Chair for the Financial Cryptography
`
`and Data Security Conference, the General Chair of the Symposium on Research in
`
`Attacks and Defenses, and the Co-Chair and Chair for the Symposium on Research
`
`in Attacks and Defenses in 2015 and 2016, respectively. As a leader in the field, I
`
`have also served on numerous technical program committees including the
`
`Symposium on Electronic Crime Research (2016), Research in Attacks, Intrusions,
`
`and Defenses Symposium (2012, 2013), USENIX Security Symposium (2013,
`
`2005-2009), Financial Cryptography and Data Security (2011, 2012), Digital
`
`Forensics Research Conference (2011, 2012), ACM Conference on Computer and
`
`Communications Security (2009-2011, 2013), IEEE Symposium on Security and
`
`Privacy (2007, 2008), ISOC Network & Distributed System Security (2006—
`
`2009), International Conference on Distributed Computing Systems (2005, 2009,
`
`2010), and USENIX Workshop on Large-scale Exploits and Emergent Threats
`
`(2010-2012).
`
`11. From 2006 to 2009, I served as an Associate Editor for IEEE
`
`Transactions on Information and Systems Security (the leading technical journal
`
`9
`
`Page 9 of 51
`
`

`
`Case No. IPR2015-01047
`
`on cyber security), and currently serve on the Steering Committee for the USENIX
`
`Security Symposium.
`
`12. My curriculum vitae, which is appended, details my background and
`
`technical qualifications. Although I am being compensated at my standard rate of
`
`$450/hour for my work in this matter, the compensation in no way affects the
`
`statements in this declaration.
`
`IV. Level of Ordinary Skill
`I am familiar with the level of ordinary skill in the art with respect to
`13.
`
`the inventions of the ’151 patent as of what I understand is the patent’s early-2000
`
`priority date. Specifically, based on my review of the technology, the educational
`
`level of active workers in the field, and drawing on my own experience, I
`
`believe a person of ordinary skill in art at that time would have had a master’s
`
`degree in computer science or computer engineering, as well as two years of
`
`experience in computer networking with some accompanying exposure to network
`
`security. My view is consistent with VirnetX’s view that a person of ordinary skill
`
`in the art requires a master’s degree in computer science or computer engineering
`
`and approximately two years of experience in computer networking and computer
`
`security. I have been asked to respond to certain opinions offered by Dr. Roch
`
`Guerin, consider how one of ordinary skill would have understood certain claim
`
`terms, and consider how one of ordinary skill in the art would have understood the
`
`10
`
`Page 10 of 51
`
`

`
`Case No. IPR2015-01047
`
`references mentioned above in relation to the claims of the ’151 patent. My
`
`findings are set forth below.
`
`V. Claim Terms
`I understand that in an inter partes review proceeding, the claims of a
`14.
`
`patent are construed under the broadest reasonable interpretation in light of the
`
`specification. I also understand that the parties have proposed constructions for
`
`certain terms of the ’151 patent. Unless otherwise noted, I have used Patent
`
`Owner’s proposed constructions in my analysis. In my opinion, Patent Owner’s
`
`proposed constructions are consistent with the specification.
`
`A.
`15.
`
`“DNS Request” (Claims 1, 7, and 13)
`
`I understand that the parties and the Board have put forth the following
`
`constructions for purposes of this proceeding:
`
`VirnetX’s and Black
`Swamp’s Proposed
`Construction
`A request for a resource
`corresponding to a
`domain name
`
`
`Mangrove’s and Apple’s
`Proposed Construction
`
`A request for a resource
`corresponding to a
`network address
`
`Decision’s Construction
`
`No construction proposed
`
`16. One of ordinary skill in the art would have understood that a “DNS
`
`request,” in view of the specification, is “a request for a resource corresponding to
`
`a domain name.”
`
`17. The patent specification discloses that a “DNS request” may request an
`
`IP address or other non-IP address resources, such as public keys for encryption.
`
`11
`
`Page 11 of 51
`
`

`
`Case No. IPR2015-01047
`
`(See Ex. 1001 37:21-32, citing Ex. 2027, RFC 2535, D. Eastlake, “Domain Name
`
`System Security Extensions.”) In particular, the RFC cited by the specification
`
`explains that a computer or resolver may make “[a]n explicit request for KEY
`
`RR’s [public key resource records] . . . .” (Ex. 2027 at 17.) The ’151 patent
`
`specification further explains that a DNS request involves the sending of a domain
`
`name. (See Ex. 1001 at 37:33-38, 37:43-47, 37:60-64; see also id. at 37:4-6,
`
`37:14-19.)
`
`B.
`18.
`
`“Determining” (Claims 1, 7, 13)
`
`I understand that the parties and the Board have put forth the following
`
`constructions for purposes of this proceeding:
`
`VirnetX and Black
`Swamp’s Proposed
`Construction
`Plain and ordinary
`meaning
`
`
`
`Decision’s Construction
`
`No construction proposed
`
`Mangrove’s and Apple’s
`Proposed Construction
`
`To come to a decision
`concerning as the result
`of investigation or
`reasoning, or to cause or
`elicit a determination of
`
`19. One of ordinary skill in the art would have understood that
`
`“determining,” in view of the specification, should be given its plain and ordinary
`
`meaning. I understand that Petitioners Mangrove and Apple cite to definition 1.c
`
`(“to come to a decision concerning as the result of investigation or reasoning”) and
`
`definition 6 (“to cause or elicit determination of’”) in Webster’s Third New
`
`International Dictionary (Pet. at 10, 12, 13), but the dictionary itself states that
`
`12
`
`Page 12 of 51
`
`

`
`Case No. IPR2015-01047
`
`definition 6 relates to embryology. (Ex. 1008 at 5 (“6 embryol: to cause or elicit
`
`determination of”).) A dictionary definition relating to embryology is irrelevant to
`
`the ’151 patent.
`
`C.
`20.
`
`“Secure Server” (Claims 1, 2, 6-8, 12-14)
`
`I understand that the parties and the Board have put forth the following
`
`constructions for purposes of this proceeding:
`
`Patent Owner’s Proposed
`Construction
`A server that requires
`authorization for access
`and that can
`communicate in an
`encrypted channel
`
`Decision’s Construction
`
`No construction proposed
`
`Petitioners’ Proposed
`Construction
`A server that
`communicates over a
`transmission path that
`restricts access to data or
`other information on the
`path
`
`
`
`21. One of ordinary skill in the art would have understood that a “secure
`
`server,” in view of the specification, is “a server that requires authorization for
`
`access and that can communicate in an encrypted channel.”
`
`22. The ’151 patent claims and specification support this construction. For
`
`example, claim 1 recites “automatically initiating an encrypted channel between
`
`the client and the secure server.” Since the encrypted channel extends to the secure
`
`server, the secure server can communicate in the encrypted channel. Moreover, the
`
`secure server is described in the “Scenario #1” and “Scenario #2” embodiments in
`
`the specification (and is referred to there as a “target computer”). (Ex. 1001 at
`
`39:10-27.) In these embodiments, a client computer requests access to the secure
`
`13
`
`Page 13 of 51
`
`

`
`Case No. IPR2015-01047
`
`server and, if the client has authorization to access the secure server, a gatekeeper
`
`computer establishes a VPN between the client computer and the secure server.
`
`(Id. at 39:10-19.) But if the client computer does not have authorization to access
`
`the target computer, the DNS proxy returns a “host unknown” message instead.
`
`(Id. at 39:20-27.) Thus, the specification also supports that the claimed “secure
`
`server” is a server that requires authorization for access and that can communicate
`
`in an encrypted channel.
`
`D.
`23.
`
`“Client” (Claims 1, 2, 6-8, 12-14)
`
`I understand that the parties and the Board have put forth the following
`
`constructions for purposes of this proceeding:
`
`Patent Owner’s Proposed
`Construction
`User’s computer
`
`Petitioners’ Proposed
`Construction
`A device, computer,
`system, or program from
`which a data request to a
`server is generated
`
`Decision’s Construction
`
`No construction proposed
`
`
`
`24. One of ordinary skill in the art would have understood that a “client,”
`
`in view of the specification, is a “user’s computer.”
`
`25. The claims of the ’151 patent support this understanding. For
`
`example, independent claims 1 and 13 of the ’151 patent are directed to methods
`
`and systems for “automatically” initiating/creating an encrypted/secure channel
`
`between the client and the secure server. Because the channel initiation/creation is
`
`14
`
`Page 14 of 51
`
`

`
`Case No. IPR2015-01047
`
`between the “client” and the secure server, and is “automatic,” the “client” must be
`
`a “user’s computer.”
`
`26.
`
`In addition, the specification of the ’151 patent explains that a VPN is
`
`initiated between the user’s computer 2601 and the target: “If [the DNS request
`
`from the user’s computer 2601 is requesting access to a secure site and the user is
`
`authorized], DNS proxy 2610 transmits a message to gatekeeper 2603 requesting
`
`that a virtual private network be created between user computer 2601 and secure
`
`target site 2604.” (See, e.g., Ex. 1001 at 37:66-38:2, emphasis added.) This
`
`parallels the claim language, which recites initiating/creating the encrypted/secure
`
`channel between a client and a secure server. The ’151 patent also explains that
`
`“[a] user’s computer 2501 includes a client application.” (See id. at 37:1-3; see
`
`also id. at 37:51-52 (“A user’s computer 2601 includes a conventional client (e.g.,
`
`a web browser) . . . .”).) Thus, the ’151 patent equates the user’s computer 2601
`
`with the “client” in the claims. Similarly, in other embodiments, the ’151 patent
`
`discloses that a determination is made as to whether “client 3103 is a validly
`
`registered user” (id. at 44:43-44), and “client computer 801” is depicted as a user’s
`
`computer, namely a laptop device (id. at 15:61-62; Fig. 8).
`
`27. The ordinary meaning is further confirmed by a dictionary, which
`
`defines “client machine” as “[a] user’s workstation that is attached to a network.”
`
`(Ex. 2028 at 3.) The relevant definitions for the other client-related terms also
`
`15
`
`Page 15 of 51
`
`

`
`unanimously require a user, either expressly or implicitly, by identifying a “client”
`
`as a “workstation,” “personal computer,” “user’s machine,” or “user’s PC” in those
`
`Case No. IPR2015-01047
`
`definitions:
`
`Term
`
`Client
`
`Dictionary
`
`A workstation or personal computer in a
`
`client/server environment
`
`Client application
`
`An application running in a workstation
`
`or personal computer on a network
`
`Client based
`
`Refers to hardware or software that runs
`
`in the user’s machine (client)
`
`Client program
`
`Software that runs in the user’s PC or
`
`workstation
`
`Client/server
`
`An architecture in which the user’s PC
`
`(the client) is the requesting machine
`
`and
`
`the
`
`server
`
`is
`
`the
`
`supplying
`
`machine[.]
`
`
`
`28. According to the same dictionary, “workstation” “is just a generic term
`
`for a user’s computer.” (Id. at 9.) Likewise, “personal computer” or “PC” is “a
`
`computer that serves one user in the office or home.” (Id. at 5.) Accordingly, each
`
`16
`
`Page 16 of 51
`
`

`
`Case No. IPR2015-01047
`
`of the client-related definitions incorporates the view that a client is a user’s
`
`computer.
`
`E.
`29.
`
`“Between [A] and [B]” (Claims 1, 2, 6-8, 12-14)
`
`I understand that the parties and the Board have put forth the following
`
`constructions for purposes of this proceeding:
`
`Patent Owner’s Proposed
`Construction
`Extending from [A] to
`[B]
`
`
`Petitioners’ Proposed
`Construction
`In the space that separates No construction proposed
`
`Decision’s Construction
`
`30. One of ordinary skill in the art would have understood that “between
`
`[A] and [B],” in view of the specification, means “extending from [A] to [B].” For
`
`example, claim 1 recites “automatically initiating an encrypted channel between
`
`the client and the secure server.” (Ex. 1001 at 46:66-67 (emphasis added).) The
`
`specification explains that the claimed data security extends from an originating
`
`terminal to a destination terminal. (See, e.g., id. at 1:30-46.)
`
`F. Domain Name
`31. To the extent “domain name” is a separate claim term, one of ordinary
`
`skill in the art would have understood that a “domain name,” in view of the
`
`specification, to be “a name corresponding to a network address.” This
`
`understanding is consistent with the specification, which explains that Internet
`
`Protocol or “IP” is but one type of network. (See, e.g., Ex. 1001 at 4:11, 5:5-6,
`
`9:13-14, 14:23-29, 19:20-22; see also id. at 14:27-31, 19:20-22.)
`
`17
`
`Page 17 of 51
`
`

`
`Case No. IPR2015-01047
`
`G.
`
`“Automatically Initiating/Creating an Encrypted/Secure
`Channel” (Claims 1, 6, 7, 12, 13)
`
`32. One of ordinary skill in the art would have understood that
`
`“automatically initiating/creating an encrypted/secure channel,” in view of the
`
`specification,
`
`is “initiating/creating
`
`the encrypted/secure channel without
`
`involvement of a user.” This understanding is supported by the ’151 patent
`
`specification, which describes various embodiments for “automatically set[ting]
`
`up” a virtual private network between the target node and the user. (See, e.g. Ex.
`
`1001 at 37:33-39:46; see also id. at 37:60-38:2, 38:59-66.)
`
`VI. Kiuchi
`A. Kiuchi’s Disclosure
`33. Kiuchi explains that “[i]n the medical community, there is a strong
`
`need for closed networks among hospitals and related institutions . . . .” (Ex. 1002
`
`at 7, § 1.) When an end user at a client in one hospital requests patient information
`
`located at an origin server of another hospital, “[s]ecure transfer . . . is obviously
`
`essential.” (Id. at 7, § 1.) Kiuchi discloses a closed HTTP-based network (C-
`
`HTTP) “to assure institutional level security.” (Id. at 7, Abstract.)
`
`34. C-HTTP communication is a multi-step process and requires three
`
`components between the client, also referred to as a user agent, and the origin
`
`server where the patient information resides: (1) a client-side proxy, (2) a server-
`
`side proxy, and (3) a C-HTTP name server. (Id. at 7-9.) “C-HTTP-based
`
`18
`
`Page 18 of 51
`
`

`
`Case No. IPR2015-01047
`
`communication is performed only between two types of C-HTTP proxies and
`
`between a C-HTTP proxy and C-HTTP name server.” (Id. at 11, § 4.2(2).) Unlike
`
`other protocols that “assure ‘end-to-end’ security protection” in which security
`
`protection is dependent on the end user, C-HTTP communication involves “proxy-
`
`proxy security” and there is no direct communication between user agents and
`
`origin servers. (Id. at 10-11.)
`
`35. As disclosed in Kiuchi, an end user at a user agent may select or
`
`request
`
`a
`
`“resource name[] with
`
`a
`
`connection
`
`ID,
`
`for
`
`example,
`
`‘http://server.in.current.connection/sample.html=@=6zdDfldfcZLj8V!i’”
`
`that
`
`identifies resources at an origin server. (Id. at 8, § 2.3(1).) The “resource name” in
`
`Kiuchi corresponds
`
`to “http://server.in.current.connection/sample.html” and
`
`identifies both the origin server at which the requested resources are located, also
`
`referred to as the “host” in Kiuchi, and the resources requested. (Id. at 8, § 2.3(1).)
`
`The connection ID corresponds to “6zdDfldfcZLj8V!i.” (Id. at 8, § 2.3(1).)
`
`36. Kiuchi summarizes C-HTTP-based communications in nine steps.
`
`(See Ex. 1002 at 8-10.) In step (1), the client-side proxy receives the resource
`
`name and connection ID from the client. (Id. at 8, § 2.3(1).) If “the connection ID
`
`is not found in the current connection table in the client-side proxy, the current
`
`connection is disconnected.” (Id. at 8, § 2.3(1).) “[A] new connection is
`
`established if the host is in the closed network.” (Id. at 8, § 2.3(1).)
`
`19
`
`Page 19 of 51
`
`

`
`Case No. IPR2015-01047
`
`37. To establish a new connection, in step (2) the “client-side proxy asks
`
`the C-HTTP name server whether it can communicate with the host specified in a
`
`given URL.” (Id. at 8, § 2.3(2).) The host server, as specified in the URL, is the
`
`origin server. (Id. at 8, § 2.3(1)-(2).) If the C-HTTP name server confirms that the
`
`query is legitimate and that a server-side proxy is permitted to accept the
`
`connection from the client-side proxy, the C-HTTP name server returns the IP
`
`address of the server-side proxy. (Id. at 8, § 2.3(2).)
`
`38.
`
`In step (3), the “client-side proxy sends a request for connection to the
`
`server-side proxy.” (Id. at 8, § 2.3(3).) “When a server-side proxy accepts a
`
`request for connection from a client-side proxy, it asks the C-HTTP name server
`
`whether the client-side proxy is an appropriate member of the closed network.”
`
`(Id. at 8-9, § 2.3(4).) If it is, in step (4), the name server returns the IP address of
`
`the client-side proxy. (Id. at 9, § 2.3(4).)
`
`39. Once the server-side proxy obtains the client-side proxy’s IP address, it
`
`generates a connection ID and sends it with other information to the client-side
`
`proxy. (Id. at 9, § 2.3(5).) “When the client-side proxy accepts and checks [the
`
`information from the server-side proxy], the connection is established” in step (5).
`
`(Id. at 9, § 2.3(5).)
`
`40. After the C-HTTP connection is established, the “client-side proxy
`
`forwards HTTP/1.0 requests from the user agent in encrypted form using C-HTTP
`
`20
`
`Page 20 of 51
`
`

`
`Case No. IPR2015-01047
`
`format,” in step (6). (Id. at 9, § 2.3(6).) These HTTP/1.0 requests identify
`
`resources at the origin server. (Id. at 8-9, § 2.3(1), Fig. (c).) Accordingly, in step
`
`(7), the server-side proxy forwards the requests to the origin server after converting
`
`them to HTTP/1.0 requests. (Id. at 9, § 2.3(7).) In step (8), the origin server sends
`
`an HTTP/1.0 response, which “is encrypted in C-HTTP format by the server-side
`
`proxy, and is forwarded to the client-side proxy. Then, in the client-side proxy, the
`
`C-HTTP response is decrypted and the HTTP/1.0 response extracted” and sent to
`
`the client. (Id. at 9, § 2.3(8).) In step (9), “[a] client-side proxy can send a request
`
`for closing the connection.” (Id. at 10, § 2.3(9).)
`
`B. Claim 1
`1. Kiuchi Does Not Disclose the Recited DNS Features
`I understand claim 1 recites a “domain name server (DNS) proxy
`
`41.
`
`module” and “DNS requests sent by a client.” (Ex. 1001 at claim 1.) I understand
`
`that Petitioners appear to advance two alternative theories, pointing to: (1) a
`
`request sent by the user agent to the client-side proxy, and (2) a C-HTTP request to
`
`be sent by the client-side proxy to the C-HTTP name server. (Pet. at 27.) In my
`
`opinion, neither request discloses the claimed DNS features.
`
`42.
`
`In my opinion, Kiuchi repeatedly differentiates its C-HTTP features
`
`from DNS. For example, Kiuchi explains that the C-HTTP name service is used
`
`“instead of DNS,” the “DNS name service is not used for hostname resolution,”
`
`21
`
`Page 21 of 51
`
`

`
`Case No. IPR2015-01047
`
`and a “DNS lookup” is only performed after a permission request to the C-HTTP
`
`name server fails. (Ex. 1002 at 7; see also id. at 11 (explaining that a different
`
`naming scheme is used in a C-HTTP based system and that the system only
`
`functions with C-HTTP proxies and name servers).) In other words, Kiuchi makes
`
`clear that the disclosed DNS lookup is generated only if an error condition occurs
`
`in which C-HTTP connectivity fails. (Id. at 8 (“If [a C-HTTP connection] is not
`
`permitted, [the C-HTTP name server] sends a status code which indicates an error.
`
`If a client-side proxy receives an error status, then it performs DNS lookup,
`
`behaving like an ordinary HTTP/1.0 proxy.”).) Kiuchi does not disclose that the
`
`request sent by the user agent to the client-side proxy, nor the request sent by the
`
`client-side proxy to the C-HTTP name server, is a DNS request.
`
`43. Moreover, Kiuchi does not disclose the same functionality as
`
`conventional DNS. For example, as discussed below, unlike conventional DNSs,
`
`which “provide a look-up function that returns the IP address of a requested
`
`computer or host” (Ex. 1001 at 36:61-63), Kiuchi’s C-HTTP name server does not
`
`return the IP address of the URL in the request, which identifies Kiuchi’s origin
`
`server, but instead returns a server-side proxy’s IP address. For example, in
`
`Kiuchi,
`
`the
`
`URL,
`
`e.g.,
`
`“http://server.in.current.connection!sample.html=@=6zdDfldfcZLj8V!i,”
`
`represents a “resource name,” and when the URL is clicked, “the client-side proxy
`
`22
`
`Page 22 of 51
`
`

`
`Case No. IPR2015-01047
`
`takes off the connection ID (i.e., “6zdDfldfcZLj8V”) and forwards, the stripped,
`
`original resource name to the server . . . .” (Ex. 1002 at 8-9.) The C-HTTP name
`
`server returns the IP address of the server-side