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. and APPLE INC.,
`Petitioner
`
`v.
`
`VIRNETX INC.
`Patent Owner
`
`
`
`
`
`
`
`
`Case IPR2015-010461
`Patent 6,502,135
`
`
`
`
`
`
`
`
`Declaration of Fabian Monrose, Ph.D.
`
`
`
`
`
`
`1 Apple Inc., who filed a petition in IPR2016-00062, has been joined as a Petitioner
`in the instant proceeding.
`
`
`
`1
`
`VIRNETX EXHIBIT 2043
`Mangrove v. VirnetX
`Trial IPR2015-01046
`
`Page 1 of 53
`
`

`
`Case No. IPR2015-01046
`
`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.
`
`“Virtual Private Network (VPN)” (Claims 1, 4, 7, 10, and 12) ..........11
`
`“Domain Name Service (DNS) Request” (Claims 1, 3, 4, 8, 10,
`12) ........................................................................................................15
`
`“Client Computer” (Claims 1, 3, 4, 7, 10, 12) ....................................16
`
`“Domain Name” (Claims 1, 3, 10) ......................................................19
`
`“DNS Proxy Server” (Claims 8, 10) ...................................................19
`
`“Automatically Initiating the VPN” (Claims 1, 4, 5) ..........................20
`
`VI. Kiuchi.............................................................................................................20
`
`A. Kiuchi’s Disclosure .............................................................................20
`
`B.
`
`Claim 1 ................................................................................................23
`
`1.
`
`2.
`
`3.
`
`4.
`
`Kiuchi Does Not Disclose the Recited DNS Features ..............23
`
`Kiuchi Does Not Disclose to “Request an IP Address
`Corresponding to a Domain Name Associated with the
`Target Computer” .....................................................................25
`
`Kiuchi’s Client-Side Proxy and Server-Side Proxy Do
`Not Disclose the Claimed Client and Target Computers..........25
`
`Kiuchi Does Not Disclose the Claimed VPN ...........................28
`
`C.
`
`Claim 10 ..............................................................................................31
`
`1.
`
`Kiuchi Does Not Disclose the Recited DNS Features ..............31
`
`2
`
`Page 2 of 53
`
`

`
`Case No. IPR2015-01046
`
`2.
`
`3.
`
`Kiuchi Does Not Disclose a DNS Proxy Server that
`Generates a Request to Create a VPN ......................................31
`
`Kiuchi Does Not Disclose a DNS Proxy Server that
`Returns an IP Address ...............................................................32
`
`D. Dependent Claims ...............................................................................33
`
`1.
`
`2.
`
`Claim 4 ......................................................................................33
`
`Claims 3, 7, 8, and 12 ...............................................................34
`
`VII. Kiuchi and RFC 1034 ....................................................................................34
`
`VIII. Conclusion .....................................................................................................34
`
`
`
`
`
`3
`
`Page 3 of 53
`
`

`
`Case No. IPR2015-01046
`
`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.
`
`6,502,135 (“the ’135 patent”). I understand the ’135 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 ’135 patent 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 ’135 patent, including claims 1-18. I have also
`2.
`
`reviewed the decisions to institute inter partes review (“IPR”) in IPR2015-01046
`
`(Paper No. 11, the “Decision”), and in IPR2016-00062 (Paper No. 28, the “00062
`
`Decision”); and the petitions for IPR filed by The Mangrove Partners Master Fund,
`
`Ltd. in IPR2015-01046 (the “Petition”), and by Apple Inc. in IPR2016-00062 (the
`
`“Apple Petition”).
`
`3.
`
`I understand that in this proceeding the Board instituted review of the
`
`’135 patent on two grounds: (1) anticipation of claims 1, 3, 4, 7, 8, 10, and 12 over
`
`4
`
`Page 4 of 53
`
`

`
`Case No. IPR2015-01046
`
`Kiuchi; and (2) obviousness of claim 8 over Kiuchi and RFC 1034. 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
`
`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
`
`5
`
`Page 5 of 53
`
`

`
`Case No. IPR2015-01046
`
`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
`
`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
`
`6
`
`Page 6 of 53
`
`

`
`Case No. IPR2015-01046
`
`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 &
`
`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
`
`7
`
`Page 7 of 53
`
`

`
`Case No. IPR2015-01046
`
`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
`
`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
`
`8
`
`Page 8 of 53
`
`

`
`Case No. IPR2015-01046
`
`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
`
`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.
`
`9
`
`Page 9 of 53
`
`

`
`Case No. IPR2015-01046
`
`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 ’135 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
`
`references mentioned above in relation to the claims of the ’135 patent. My
`
`findings are set forth below.
`
`10
`
`Page 10 of 53
`
`

`
`Case No. IPR2015-01046
`
`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 ’135 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.
`
`“Virtual Private Network (VPN)” (Claims 1, 4, 7, 10, and 12)
`
`I understand that the parties and the Board have put forth the following
`
`constructions for purposes of this proceeding:
`
`Petitioners’ Proposed
`Construction
`A secure network that
`includes portions of a
`public network
`
`Decision’s Construction
`
`No construction proposed
`
`Patent Owner’s Proposed
`Construction
`A network of computers
`which privately and
`directly communicate
`with each other by
`encrypting traffic over
`insecure communication
`paths between the
`computers
`
`
`16. One of ordinary skill in the art would have understood that a “virtual
`
`private network (VPN),” in view of the specification, is “a network of computers
`
`which privately and directly communicate with each other by encrypting traffic
`
`over insecure communication paths between the computers.”
`
`11
`
`Page 11 of 53
`
`

`
`Case No. IPR2015-01046
`
`17. Encryption: The specification repeatedly and consistently explains
`
`that a virtual private network requires encryption. For instance, the ’135 patent
`
`specification teaches that “data security is usually tackled using some form of data
`
`encryption,” and it repeatedly discusses using encryption. (Ex. 1001 at 1:37-38;
`
`see also id. at 2:66-3:2 (Tunneled Agile Routing Protocol (TARP) embodiments
`
`described as using a “unique two-layer encryption format”), 3:18-19 (“[e]ach
`
`TARP packet’s true destination address is concealed behind a layer of encryption”
`
`(first layer)), 3:57-59 (“[t]he message payload is hidden behind an inner layer of
`
`encryption” (second layer), 7:59-60, 9:11-19, 32:29-31.) Petitioners agree that the
`
`specification discloses techniques for implementing a VPN using encryption. (Pet.
`
`at 8; Ex. 1001 at 2:66-3:67) (describing “the Tunneled Agile Routing Protocol
`
`(TARP) [that] uses a unique two-layer encryption format”).) The specification
`
`also discloses that its later discussed embodiments can use the earlier-discussed
`
`principles of encryption, identifying “different embodiments or modes that can be
`
`employed using the aforementioned principles.” (Id. at 22:61-62; see also id. at
`
`32:29-31.)
`
`18. The specification also refers to the “FreeS/WAN” project as a
`
`conventional scheme of creating a “VPN.” (Ex. 1001 at 37:50-62.) Petitioners
`
`assert that Patent Owner’s reference to RFC 2535 (the “FreeS/WAN” protocol)
`
`does not define a VPN. (Pet. at 9.) However, the FreeS/WAN glossary of terms in
`
`12
`
`Page 12 of 53
`
`

`
`Case No. IPR2015-01046
`
`the ’135 patent’s prosecution history does define VPN, and the definition requires
`
`encryption. It explains a VPN is “a network which can safely be used as if it were
`
`private, even though some of its communication uses insecure connections. All
`
`traffic on those connections is encrypted.” (Ex. 2027 at 24, Glossary for the Linux
`
`FreeS/WAN Project.) I understand that a contemporaneous dictionary similarly
`
`explains that “VPNs enjoy the security of a private network via access control and
`
`encryption . . . .” (Ex. 2028 at 8, McGraw-Hill Computer Desktop Encyclopedia
`
`(9th ed. 2001) (emphasis added).)
`
`19. Direct Communication: The ’135 patent specification describes a
`
`virtual private network that is “direct” between a client computer and target
`
`computer and
`
`the prosecution history of
`
`the ’135 patent supports
`
`this
`
`understanding.
`
`20. For instance, the ’135 patent describes a virtual private network as
`
`being direct between a user’s computer and target. (See, e.g., Ex. 1001 at 38:30-
`
`33, 39:22-25; see also id. at 40:30-35, 41:23-27 (describing a load balancing
`
`example in which a virtual private network is direct between a first host and a
`
`second host), Figs. 24, 26, 28, 29, 33.) Similarly, in an embodiment describing the
`
`aforementioned TARP, the ’135 patent describes the link between an originating
`
`TARP terminal and a destination TARP terminal as direct. (See, e.g., Ex. 1001,
`
`7:40-49, Fig. 2; see also id. at 31:62 - 32:3 (describing a variation of the TARP
`
`13
`
`Page 13 of 53
`
`

`
`Case No. IPR2015-01046
`
`embodiments as including a direct communication link); 36:25-28 (describing the
`
`embodiment of Figure 24 in which a first computer and second computer are
`
`connected directly).)
`
`21.
`
`In describing this direct communication, the ’135 patent specification
`
`discloses that the link traverses a network (or networks) through which it is simply
`
`passed or routed via various network devices such as Internet Service Providers,
`
`firewalls, and routers. (See, e.g., id. at Figs. 2, 24, 28, 29.)
`
`22. Network: Consistent with the plain meaning of a VPN, a VPN requires
`
`a network. In describing a VPN, the ’135 patent refers to the “FreeS/WAN”
`
`project, which has a glossary of terms. (Ex. 1001 at 37:57 and bibliographic data
`
`showing references cited.) The FreeS/WAN glossary defines a VPN as “a network
`
`which can safely be used as if it were private, even though some of its
`
`communication uses insecure connections. All traffic on those connections is
`
`encrypted.” (Ex. 2027 at 24, Glossary for the Linux FreeS/WAN Project.)
`
`According to this glossary, a VPN includes at least the requirement of a “network
`
`of computers.”
`
`23. The specification further describes a VPN as including multiple
`
`“nodes.” (See, e.g., Ex. 1001 at 15:12-16, referring to “each node in the network”
`
`and “vastly increasing the number of distinctly addressable nodes,” 19:58, “nodes
`
`on the network”; see also id. 17:43-45, 22:44-52, 23:14-20 (disclosing an
`
`14
`
`Page 14 of 53
`
`

`
`Case No. IPR2015-01046
`
`arrangement in which six nodes are “split up into two private virtual networks such
`
`that nodes on one VPN can communicate with only the other two nodes of its own
`
`VPN”.) More specifically, the network allows “[e]ach node . . . to communicate
`
`with other nodes in the network.” (Ex. 1001 at 15:16-19.) So a device within a
`
`VPN is able to communicate with the other devices within that same VPN.
`
`B.
`24.
`
`“Domain Name Service (DNS) Request” (Claims 1, 3, 4, 8, 10, 12)
`
`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 request for a resource
`corresponding to a
`domain name
`
`
`Petitioners’ Proposed
`Construction
`A request for a resource
`corresponding to a
`network address
`
`Decision’s Construction
`
`No construction proposed
`
`25. One of ordinary skill in the art would have understood that a “domain
`
`name service (DNS) request,” in view of the specification, is “a request for a
`
`resource corresponding to a domain name.”
`
`26. 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.
`
`(See Ex. 1001 at 37:50-62, citing Ex. 1016, 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. 1016 at 17.) The ’135
`
`15
`
`Page 15 of 53
`
`

`
`Case No. IPR2015-01046
`
`patent specification further explains that a DNS request involves the sending of a
`
`domain name. (See Ex. 1001 at 37:63-38:2, 38:6-10, 38:23-27; see also id. at
`
`37:33-35, 37:43-47.)
`
`C.
`27.
`
`“Client Computer” (Claims 1, 3, 4, 7, 10, 12)
`
`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 computer from which a
`data request to a server is
`generated
`
`Decision’s Construction
`
`No construction proposed
`
`
`
`28. One of ordinary skill in the art would have understood that a “client
`
`computer,” in view of the specification, is “user’s computer.” The specification of
`
`the ’135 patent supports this understanding by explaining 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 38:30-33, emphasis added.) This parallels
`
`the claims language, which recites creating a VPN between a client computer and a
`
`target computer (see, e.g., claim 1). The ’135 patent also explains that “[a] user’s
`
`computer 2501 includes a client application.” (See id. at 37:30-32; see also id. at
`
`16
`
`Page 16 of 53
`
`

`
`Case No. IPR2015-01046
`
`38:15-16 (“A user’s computer 2601 includes a conventional client (e.g., a web
`
`browser) . . . .”).) Thus, the ’135 patent equates the user’s computer 2601 with the
`
`“client computer” in the claims. Similarly, in other embodiments, the ’135 patent
`
`discloses that a determination is made as to whether “client 3103 is a validly
`
`registered user” (id. at 45:8-9), and “client computer 801” is depicted as a user’s
`
`computer, namely a laptop device (id. at 16:16-17; Fig. 8).
`
`29. The ’135 specification provides further guidance as to the “client
`
`computer” being a user’s computer by explaining that its inventions allow for
`
`secure communications between a user’s computer and a target computer. For
`
`instance, in the “Background of the Invention,” the specification explains the
`
`importance of securing communications between an originating terminal 100 at
`
`which a user is located and a destination terminal 110 that hosts a web site. (Id. at
`
`1:15-31.) The “Summary of the Invention” likewise explains that an originating
`
`terminal in a TARP VPN embodiment is a notebook computer used by an
`
`executive and that a destination terminal is a server. (See id. at 4:59-5:12.) The
`
`“Detailed Description of the Invention” also explains that a VPN is created
`
`between a user’s computer at which a web browser is located and a secure target
`
`site. (See id. at 38:13-33.) Consistent with the specification’s disclosure of secure
`
`communications between a user’s computer and a target computer, the claims
`
`17
`
`Page 17 of 53
`
`

`
`Case No. IPR2015-01046
`
`recite “initiating the VPN between the client computer and the target computer.”
`
`(See, e.g., id. at claim 1.)
`
`30. 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
`
`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
`
`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
`
`18
`
`Page 18 of 53
`
`

`
`Case No. IPR2015-01046
`
`machine[.]
`
`
`
`31. 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
`
`of the client-related definitions incorporates the view that a client computer is a
`
`user’s computer.
`
`“Domain Name” (Claims 1, 3, 10)
`
`D.
`32. One of ordinary skill in the art would have understood that a “domain
`
`name,” in view of the specification, is “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:3, 4:65-66, 9:22-23; see also id. at 14:44-48, 19:42-44.)
`
`“DNS Proxy Server” (Claims 8, 10)
`
`E.
`33. One of ordinary skill in the art would have understood that a “DNS
`
`proxy server,” in view of the specification, is “a computer or program that
`
`responds to a domain name inquiry in place of a DNS.” This understanding is
`
`consistent with embodiments disclosed in the specification. (See, e.g., Ex. 1001 at
`
`38:23-47.)
`
`19
`
`Page 19 of 53
`
`

`
`Case No. IPR2015-01046
`
`“Automatically Initiating the VPN” (Claims 1, 4, 5)
`
`F.
`34. One of ordinary skill in the art would have understood that a
`
`“automatically initiating the VPN,” in view of the specification, is “initiating the
`
`VPN without involvement of a user.” This understanding is supported by the ’135
`
`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:63-40:13; see also id. at 38:28-33, 39:22-29.)
`
`VI. Kiuchi
`A. Kiuchi’s Disclosure
`35. 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.)
`
`36. 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
`
`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
`
`20
`
`Page 20 of 53
`
`

`
`Case No. IPR2015-01046
`
`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.)
`
`37. 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).)
`
`38. 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).)
`
`39. 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
`
`21
`
`Page 21 of 53
`
`

`
`Case No. IPR2015-01046
`
`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).)
`
`40.
`
`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).)
`
`41. 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).)
`
`42. 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
`
`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
`
`22
`
`Page 22 of 53
`
`

`
`Case No. IPR2015-01046
`
`(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.