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
`
`
`
`
`
`
`
`
`
`
`APPLE INC.
`Petitioner
`
`v.
`
`VIRNETX INC.
`Patent Owner
`
`
`
`
`
`
`
`Case IPR2015-00870
`Patent 8,560,705
`
`
`
`
`
`
`
`
`
`
`Declaration of Fabian Monrose, Ph.D.
`
`
`
`VIRNETX EXHIBIT 2018
`Apple v. VirnetX
`Trial IPR2015-00870
`
`Page 1 of 41
`
`

`
`Case No. IPR2015-00870
`
`Table of Contents
`
`Introduction ...................................................................................................... 1
`
`Resources Consulted ........................................................................................ 2
`
`
`
`
`I.
`
`II.
`
`III. Background and Qualifications ....................................................................... 2
`
`IV. Level of Ordinary Skill .................................................................................... 7
`
`V.
`
`Claim Terms .................................................................................................... 8
`
`A.
`
`Secure Communication Link (Claims 1, 4, 6, 8, 10-12, 16, 20,
`21, 24-27) .............................................................................................. 8
`
`1.
`
`2.
`
`3.
`
`“Authentication” and “Address Hopping” Alone Do Not
`Result in a “Secure Communication Link” ................................. 9
`
`A “Secure Communication Link” Must Be Direct ...................11
`
`A “Secure Communication Link” Requires Encryption ...........12
`
`B.
`
`“Virtual Private Network Link” (Claims 6 and 21) ............................13
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`A “VPN Link” Requires a Virtual Private Network .................14
`
`“Authentication” and “Address Hopping” Alone Do Not
`Result in a “Virtual Private Network Link”..............................15
`
`A “Virtual Private Network Link” Must Be Direct ..................15
`
`A “Virtual Private Network Link” Requires a Network ...........16
`
`A “Virtual Private Network Link” Requires Encryption ..........17
`
`C.
`
`Secure Domain Name (Claims 7 and 22) ............................................18
`
`D. Other Terms .........................................................................................20
`
`VI. Beser and RFC 2401 ......................................................................................22
`
`A.
`
`B.
`
`Beser’s Disclosure ...............................................................................22
`
`Claims 1 and 16 ...................................................................................25
`
`i
`
`Page 2 of 41
`
`

`
`Case No. IPR2015-00870
`
`1.
`
`“Interception of a Request, Generated By the Client
`Device, to Look Up an Internet Protocol (IP) Address of
`the Target Device Based on a Domain Name Associated
`With the Target Device” ...........................................................25
`
`a)
`
`b)
`
`The Alleged Request in Beser Is Not a “Request . .
`. to Look Up an Internet Protocol (IP) Address” ............26
`
`The Alleged Request in Beser Is Not
`“Intercept[ed]” ................................................................28
`
`2.
`
`Beser and RFC 2401 .................................................................30
`
`C. Dependent Claims ...............................................................................35
`
`1.
`
`2.
`
`3.
`
`4.
`
`Claims 6 and 21.........................................................................35
`
`Claims 7 and 22.........................................................................36
`
`Claims 13 and 28.......................................................................37
`
`Claims 2-5, 8-12, 14, 15, 17-20, 23, 25-27, 29, and 30 ............38
`
`VII. Beser, RFC 2401, and Brand .........................................................................38
`
`VIII. Conclusion .....................................................................................................38
`
`
`
`ii
`
`Page 3 of 41
`
`

`
`
`
`I.
`
`Case No. IPR2015-00870
`
`I, FABIAN MONROSE, declare as follows:
`
`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.
`
`8,560,705 (“the ’0705 patent”). I understand the ’0705 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 ’0705 patent is a continuation of U.S. application no. 13/049,552 filed March
`
`16, 2011 (“the ’552 application”), which is a continuation of U.S. application no.
`
`11/840,560 filed August 17, 2007 (now U.S. Patent No. 7,921,211, “the ’211
`
`patent”), which is a continuation of U.S. application no. 10/714,849 filed
`
`November 18, 2003 (now U.S. Patent No. 7,418,504, “the ’504 patent), which is a
`
`continuation of U.S. application no. 09/558,210 filed April 26, 2000 (“the ’210
`
`application,” abandoned). And I understand the ’210 application is a continuation-
`
`in-part of U.S. application no. 09/504,783 filed February 15, 2000 (now U.S.
`
`Patent 6,502,135, “the ’135 patent”), and 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.
`
`1
`
`Page 4 of 41
`
`

`
`Case No. IPR2015-00870
`
`II. Resources Consulted
`I have reviewed the ’0705 patent, including claims 1-30. I have also
`2.
`
`reviewed the Petition for Inter Partes Review (Paper No. 1) filed with the U.S.
`
`Patent and Trademark Office (“Office”) by Apple Inc. on March 17, 2015 (Paper
`
`No. 1, the “Petition”). I have also reviewed the Patent Trial and Appeal Board’s
`
`(“Board”) decision to institute inter partes review (Paper No. 8, the “Decision”) of
`
`October 1, 2015.
`
`3.
`
`I understand that in this proceeding the Board instituted review of the
`
`’0705 patent on two grounds: (1) obviousness of claims 1-23 and 25-30 over
`
`Beser and RFC 2401; and (2) obviousness of claim 24 over Beser, RFC 2401, and
`
`Brand. 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
`
`2
`
`Page 5 of 41
`
`

`
`Case No. IPR2015-00870
`
`(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
`
`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
`
`3
`
`Page 6 of 41
`
`

`
`Case No. IPR2015-00870
`
`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
`
`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.
`
`4
`
`Page 7 of 41
`
`

`
`Case No. IPR2015-00870
`
`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
`
`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
`
`5
`
`Page 8 of 41
`
`

`
`Case No. IPR2015-00870
`
`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
`
`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,
`
`6
`
`Page 9 of 41
`
`

`
`Case No. IPR2015-00870
`
`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.
`
`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 ’0705 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
`
`7
`
`Page 10 of 41
`
`

`
`Case No. IPR2015-00870
`
`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. Roberto Tamassia, 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 ’0705
`
`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 ’0705 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. To the extent Patent
`
`Owner has not proposed a construction for a term, I understand that term to have
`
`its plain and ordinary meaning from the perspective of one of ordinary skill in the
`
`art in light of the specification. I have applied this understanding in my analysis.
`
`A.
`
`Secure Communication Link (Claims 1, 4, 6, 8, 10-12, 16, 20, 21,
`24-27)
`
`15.
`
`I understand that the parties and the Board have put forth the following
`
`constructions for purposes of this proceeding:
`
`8
`
`Page 11 of 41
`
`

`
`Patent Owner’s Proposed
`Construction
`A direct communication link
`that provides data security
`through encryption
`
`
`
`Case No. IPR2015-00870
`
`Decision’s
`Construction
`No construction
`proposed
`
`Petitioner’s Proposed
`Construction
`A transmission path that
`restricts access to data,
`addresses, or other
`information on the path,
`generally using obfuscation
`methods to hide information
`on the path, including, but
`not limited to, one or more
`of authentication,
`encryption, or address
`hopping
`
`16. One of ordinary skill in the art would have understood that a “secure
`
`communication link” in view of the specification is a “direct communication link
`
`that provides data security through encryption.”
`
`1.
`
`“Authentication” and “Address Hopping” Alone Do Not
`Result in a “Secure Communication Link”
`
`17. Of the obfuscation methods listed in the Petitioner’s proposed
`
`construction—authentication, encryption, and address hopping—only encryption
`
`restricts access to “data, addresses, or other information on the path,” as required
`
`by the first portion of Petitioner’s construction. (Pet. at 11-12). Authentication
`
`and address hopping alone do not “hide information on the path,” as Petitioner’s
`
`construction requires. (Id.)
`
`18. One of ordinary skill in the art would have understood that
`
`authentication merely “[e]nsur[es] that a message originated from the expected
`
`9
`
`Page 12 of 41
`
`

`
`Case No. IPR2015-00870
`
`sender and has not been altered on route.” (Ex. 2008 at 3, Glossary for the Linux
`
`FreeS/WAN Project.) Authentication alone does not prevent an eavesdropper from
`
`accessing data
`
`transmitted over an unsecure communication
`
`link.
`
` The
`
`specification is consistent with this understanding. For instance, the specification
`
`describes at least one scenario where an authenticated transmission occurs “in the
`
`clear”—i.e., over an unsecured communication link:
`
`SDNS [secure domain name service] 3313 can be accessed
`through secure portal 3310 “in the clear”, that is, without using
`an administrative VPN communication link. In this situation,
`secure portal 3310 preferably authenticates the query using any
`well-known technique, such as a cryptographic technique,
`before allowing the query to proceed to SDNS [3313].
`
`(Ex. 1050 at 51:52-57.) Authentication is not sufficient by itself to “hide
`
`information on the path,” as required by Petitioner’s proposed construction.
`
`19. One of ordinary skill in the art would also have understood that address
`
`hopping alone also does not hide information, as there is nothing inherent in
`
`moving from address to address that hides information on the path or precludes an
`
`eavesdropper from reading the details of a communication. Consistent with this
`
`understanding, the ’0705 patent discloses embodiments that use encryption in
`
`conjunction with address hopping to protect, for example, the next address in a
`
`routing scheme from being viewed by eavesdroppers. (See, e.g., Ex. 1050 at 3:36-
`
`10
`
`Page 13 of 41
`
`

`
`Case No. IPR2015-00870
`
`50, stating in part that “[e]ach TARP packet’s true destination is concealed behind
`
`a layer of encryption generated using a link key.”) It is the encryption that hides
`
`information on the path while moving from address to address. (See, e.g., Ex.
`
`1050 at 3:16-4:40.) Address hopping is not sufficient by itself to “hide information
`
`on the path,” as required by Petitioner’s proposed construction.
`
`20.
`
`I understand that Petitioner asserted that I agreed during my cross-
`
`examination in another case that address hopping hides information on the path.
`
`(Pet. at 11, citing Ex. 1055 at 113:16-114:12.) Petitioner’s understanding is
`
`misplaced. I do not agree that address hopping does this. Indeed, as I explained
`
`during that examination, address hopping simply makes it such that “[y]ou may not
`
`be able to determine in isolation who is speaking to whom.” (Ex. 1055 at 114:1-6.)
`
`That is, address hopping may make it more difficult to determine the originating
`
`and terminating devices, but it alone does not “hide” the addresses. Nor does
`
`authentication.
`
`A “Secure Communication Link” Must Be Direct
`
`2.
`21. The understanding that a secure communication link is a direct link is
`
`consistent with the specification.
`
`22. For instance, in one embodiment, the ’0705 patent describes the link
`
`between an originating TARP terminal and a destination TARP terminal as direct.
`
`(See, e.g., Ex. 1050, 9:41-50, Fig. 2; see also id. at 33:51-57 (describing a variation
`
`11
`
`Page 14 of 41
`
`

`
`Case No. IPR2015-00870
`
`of the TARP embodiments as including a direct communication link); 38:11-14
`
`(describing the embodiment of Figure 24 in which a first computer and second
`
`computer are connected directly).) The ’0705 patent similarly describes direct
`
`communications in later embodiments as well. (See, e.g., id. at 40:13-16, 41:5-8
`
`(describing a virtual private network as being direct between a user’s computer and
`
`target), 42:12-16, 43:5-9 (describing a load balancing example in which a virtual
`
`private network is direct between a first host and a second host), 49:8-10, 49:16-31
`
`(describing a secure communication link that is direct between a first computer and
`
`a second computer), Figs. 24, 26, 28, 29, 33.)
`
`23.
`
`In each of these embodiments, the ’0705 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, 33.)
`
`24.
`
`I thus agree that a secure communication link is a direct link.
`
`A “Secure Communication Link” Requires Encryption
`
`3.
`25. One of ordinary skill in the art would have understood that in the
`
`context of the specification of the ’0705 patent, a secure communication link
`
`requires encryption. For instance, the patent specification teaches that “data
`
`security is usually tackled using some form of data encryption,” and it repeatedly
`
`discusses using encryption. (Ex. 1050 at 1:57-58; see also id. at 3:17-19 (“TARP”
`
`12
`
`Page 15 of 41
`
`

`
`Case No. IPR2015-00870
`
`embodiments described as using a “unique two-layer encryption format”), 3:36-37
`
`(“[e]ach TARP packet’s true destination address is concealed behind a layer of
`
`encryption”), 4:7-9 (“[t]he message payload is hidden behind an inner layer of
`
`encryption”), 9:60-61, 11:10-17, 34:15-16.)
`
`26.
`
`I understand that Petitioner contends that I agreed during cross-
`
`examination for another case that the specification of a related patent has
`
`“opposing views” as to the meaning of secure communication. (Pet. at 11, citing
`
`Ex. 1055 at 113:16-114:12, 74:12-14.) I disagree with Petitioner’s representation.
`
`First, neither of the sections to which Petitioner cites discusses any “opposing
`
`views” of secure communication. (See Ex. 1055 at 113:16-114:12, 74:12-14.)
`
`Further, where I did use the phrase, it was in response to a question as to whether
`
`the specification includes an explicit definition for “secure communication link.”
`
`(Id. at 66:11-17.) In reply, I stated that I believe the parties had “opposing views”
`
`on the term. (Id.) I disagree that the specification of that related patent and the
`
`’0705 patent has opposing views as to the meaning of secure communication.
`
`B.
`27.
`
`“Virtual Private Network Link” (Claims 6 and 21)
`
`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 path between two
`devices in a virtual
`
`Petitioner’s Proposed
`Construction
`A transmission path
`between two devices that
`
`Decision’s Construction
`
`No construction proposed
`
`13
`
`Page 16 of 41
`
`

`
`private network
`
`
`
`Case No. IPR2015-00870
`
`restricts access to data,
`addresses, or other
`information on the path,
`generally using obfuscation
`methods to hide
`information on the path,
`including, but not limited
`to, one or more of
`authentication, encryption,
`or address hopping
`
`28.
`
`I understand that Petitioner construes “virtual private network link” to
`
`have essentially the same construction as “secure communication link.” (See Pet.
`
`at 11, and id. at 14.) Petitioner’s construction of “virtual private network link”
`
`suffers from many of the same deficiencies as I discuss above with respect to
`
`“secure communication link.” As discussed below, one of ordinary skill in the art
`
`would have understood that a “virtual private network link” (or “VPN link”) in
`
`view of the specification is “a path between two devices in a virtual private
`
`network,” where a virtual private network is a network of computers which
`
`privately and directly communicate with each other by encrypting traffic on
`
`insecure paths between the devices where the communication is both secure and
`
`anonymous.
`
`A “VPN Link” Requires a Virtual Private Network
`
`1.
`29. One of ordinary skill in the art would have understood that as
`
`explained in the ’0705 patent, a VPN link does not exist outside of a virtual private
`
`network. First, the claim term “VPN link” expressly requires a “VPN.” The
`
`14
`
`Page 17 of 41
`
`

`
`Case No. IPR2015-00870
`
`specification is also consistent. For example, the patent explains that when a
`
`secure domain name service (SDNS) receives a query for a secure network
`
`address, it “accesses VPN gatekeeper 3314 for establishing a VPN communication
`
`link between software module 3309 [at the querying computer 3301] and secure
`
`server 3320.” (Ex. 1050 at 51:38-40.) Then, “VPN gatekeeper 3314 provisions
`
`computer 3301 and secure web server computer 3320 . . . thereby creating the
`
`VPN” between the devices. (Ex. 1050 at 51:41-44.) Secure server 3320 “can only
`
`be accessed through a VPN communication link.” (Ex. 1050 at 51:40-41.) And
`
`“[f]urther communication between computers 3301 and 3320 occurs via the VPN”
`
`through the VPN link. (Ex. 1050 at 52:4-6.)
`
`2.
`
`“Authentication” and “Address Hopping” Alone Do Not
`Result in a “Virtual Private Network Link”
`
`30. As I discuss above with respect to “secure communication link,” only
`
`encryption actually “restricts access to data, addresses, or other information on the
`
`path,” as required by Petitioner’s construction. (See my discussion above
`
`regarding secure communication link.) Address hopping and authentication alone
`
`do not hide information on the path.
`
`A “Virtual Private Network Link” Must Be Direct
`
`3.
`In my opinion, one of skill would have understood that a “virtual
`
`31.
`
`private network communication link” in the context of the ’0705 patent describes a
`
`“direct” link, as discussed above in Section V.B.2.
`
`15
`
`Page 18 of 41
`
`

`
`Case No. IPR2015-00870
`
`A “Virtual Private Network Link” Requires a Network
`
`4.
`32. As I noted above, one of ordinary skill in the art would have
`
`understood that the term “VPN link” must exist in a virtual private “network.”
`
`Accordingly, such a link must be between devices in a network. The specification
`
`is consistent with this understanding. For example, in describing a VPN, the ’0705
`
`patent refers to the “FreeS/WAN” project, which has a glossary of terms. (Ex.
`
`1050 at 39:42 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. 2008 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.” (Id.)
`
`33. The specification describes a VPN as including multiple “nodes.”
`
`(See, e.g., Ex. 1050 at 17:1-5, referring to “each node in the network” and “vastly
`
`increasing the number of distinctly addressable nodes,” 22:11, “nodes on the
`
`network”; see also id. 19:27-29, 24:26, 24:61-67 (disclosing an 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”.) The
`
`specification explains that the network allows “[e]ach node . . . to communicate
`
`with other nodes in the network.” (Ex. 1050 at 17:5-7.) So a device within a VPN
`
`16
`
`Page 19 of 41
`
`

`
`Case No. IPR2015-00870
`
`is able to communicate with the other devices within that same VPN. In addition,
`
`the specification distinguishes point-to-point queries from those carried on a VPN
`
`communication link, stating that they occur “without using an administrative VPN
`
`communication link.” (See, e.g., Ex. 1050 at 51:52-54, 51:57-60.)
`
`A “Virtual Private Network Link” Requires Encryption
`
`5.
`In my opinion, one of skill would have understood that a “virtual
`
`34.
`
`private network communication link” in the context of the ’0705 patent requires
`
`encryption, as discussed above in Section V.B.3.
`
`35. For instance, the specification’s “TARP” embodiments describe a
`
`“unique two-layer encryption format” where “[e]ach TARP packet’s true
`
`destination address is concealed behind a layer of encryption” (first layer) and
`
`“[t]he message payload is hidden behind an inner layer of encryption” (second
`
`layer). (Ex. 1050 at 3:17-19, 3:36-37, 4:7-9.) In addition, as described above, the
`
`FreeS/WAN glossary of terms in the ’0705 patent’s prosecution history explains
`
`that 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. 2008 at 24, Glossary for the Linux FreeS/WAN
`
`Project.) Consistent with the specification’s disclosures, a 2001 computing
`
`dictionary discloses that “VPNs enjoy the security of a private network via access
`
`17
`
`Page 20 of 41
`
`

`
`Case No. IPR2015-00870
`
`control and encryption . . . .” (Ex. 2007 at 8, McGraw-Hill Computer Desktop
`
`Encyclopedia (9th ed. 2001).)
`
`C.
`36.
`
`Secure Domain Name (Claims 7 and 22)
`
`I understand that the parties and the Board have put forth the following
`
`constructions for purposes of this proceeding:
`
`Petitioner’s Proposed
`Construction
`A name that corresponds to
`a secure computer network
`address
`
`Decision’s
`Construction
`No construction
`proposed
`
`Patent Owner’s Proposed
`Construction
`A non-standard domain
`name that corresponds to a
`secure computer network
`address and cannot be
`resolved by a conventional
`domain name service (DNS)
`
`
`37. Patent Owner’s construction is consistent with the specification’s
`
`disclosure of a secure domain name. For example, the specification discloses that
`
`a “secure domain name” corresponds to “a nonstandard domain name.” (Ex. 1050
`
`at 7:29-31, 50:31-40.) The specification provides examples of “a nonstandard
`
`domain name”: .scom, .snet, .sorg, .sedu, .smil, and .sgov. (Id. at 7:39-42.) The
`
`specification also explains that a “secure domain name” “corresponds to a secure
`
`computer network address.” (See id. at 51:15-19, stating that “SDNS 3313
`
`contains a cross-reference database of secure domain names and corresponding
`
`secure network addresses.”) Because a “secure domain name” is “a non-standard
`
`domain name,” the specification explains that “a query to a standard domain name
`
`18
`
`Page 21 of 41
`
`

`
`Case No. IPR2015-00870
`
`service (DNS) will return a message indicating that the universal resource locator
`
`(URL) is unknown.” (Id. at 50:41-44; Figs. 33, 34.) To obtain the URL for a
`
`“secure domain name,” “a secure domain name service (SDNS)” must be queried.
`
`(Id. at 50:44-46; Figs. 33, 34.) One of ordinary skill in the art would have thus
`
`understood that a secure domain name is a non-standard domain name that
`
`corresponds to a secure computer network address and cannot be resolved by a
`
`conventional domain name service (DNS).
`
`38.
`
`I understand that this is consistent with statements made by Patent
`
`Owner in a now-completed inter partes reexamination of a related patent. I
`
`understand that Patent Owner stated that the related patent “takes pains to explain
`
`that a secure domain name is different from a domain name that just happens to be
`
`associated with a secure computer or just happens to be associated with an address
`
`requiring authorization.” (Ex. 2016 at 5.) I understand that Patent Owner fu