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 IPR2014-00481
`Patent 7,188,180
`
`
`
`
`
`
`
`
`
`
`
`
`Declaration of Fabian Monrose, Ph.D.
`
`
`
`1
`
`Page 1 of 53
`
`VIRNETX EXHIBIT 2010
`Apple v. VirnetX
`Trial IPR2015-00868
`
`

`
`Case No. IPR2014-00481
`
`Table of Contents
`
`I.
`
`II.
`
`Introduction ...................................................................................................... 4
`
`Resources Consulted ........................................................................................ 4
`
`III. Background and Qualifications ....................................................................... 5
`
`IV. Level of Ordinary Skill .................................................................................. 10
`
`V.
`
`Claim Terms .................................................................................................. 10
`
`A.
`
`“VPN Communication Link” (Claims 1, 17, and 33) ......................... 10
`
`1.
`
`2.
`
`A VPN Communication Link is a Link in a VPN .................... 11
`
`A VPN Requires a Network of Computers ............................... 13
`
`B.
`
`“Secure Computer Network Address” (Claims 1, 12, 17, 28,
`and 33) ................................................................................................. 14
`
`C.
`
`“Client Computer” (Claims 13, 15, 29, and 31) .................................. 15
`
`D. Other Terms ......................................................................................... 17
`
`VI. Provino........................................................................................................... 18
`
`A.
`
`B.
`
`Provino’s Disclosure ........................................................................... 18
`
`Claims 1, 17, and 33 ............................................................................ 20
`
`1.
`
`2.
`
`“Receiving a Secure Domain Name” ........................................ 20
`
`“Sending a Query Message From to a Secure Domain
`Name Service, the Query Message Requesting From the
`Secure Domain Name Service a Secure Computer
`Network Address Corresponding to a Secure Domain
`Name” ....................................................................................... 22
`
`a)
`
`b)
`
`The ’180 Patent Specification......................................... 23
`
`“Secure Domain Name Service” Under Apple’s
`Construction .................................................................... 26
`
`2
`
`Page 2 of 53
`
`

`
`Case No. IPR2014-00481
`
`3.
`
`“Sending an Access Request Message to the Secure
`Computer Network Address Using a Virtual Private
`Network Communication Link” ............................................... 28
`
`C. Dependent Claims ............................................................................... 30
`
`1.
`
`2.
`
`Dependent Claims 10 and 26 – The VPN Includes the
`Internet ...................................................................................... 30
`
`Dependent Claims 12 and 28 – The Access Request
`Message Contains a Request for Information Stored at
`the Secure Computer Network Address .................................... 30
`
`VII. Provino in View of Guillen ........................................................................... 32
`
`VIII. Conclusion ..................................................................................................... 35
`
`
`
`
`
`3
`
`Page 3 of 53
`
`

`
`Case No. IPR2014-00481
`
`I, FABIAN MONROSE, declare as follows:
`
`I.
`
`Introduction
`
`1.
`
`I have been retained by VirnetX Inc. (“VirnetX”) for this inter partes
`
`review proceeding. I understand that this proceeding involves U.S. Patent No.
`
`7,188,180 (“the ’180 patent”). I understand the ’180 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 ’180 patent is a divisional of U.S. application no. 09/558,209 filed April 26,
`
`2000 (“the ’209 application,” abandoned). And I understand the ’209 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 (now U.S. Patent No.
`
`7,010,604) filed October 29, 1999, which claims priority to the ’261 and ’704
`
`applications.
`
`II. Resources Consulted
`
`2.
`
`I have reviewed the ’180 patent, including claims 1-41. I have also
`
`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 7, 2014 (Paper
`
`No. 1, the “Petition”). I have also reviewed the Patent Trial and Appeal Board’s
`
`4
`
`Page 4 of 53
`
`

`
`Case No. IPR2014-00481
`
`(“Board”) decision to institute inter partes review (Paper No. 11, the “Decision”)
`
`of September 3, 2014.
`
`3.
`
`I understand that in this proceeding the Board instituted review of the
`
`’180 patent on two grounds: (1) anticipation of claims 1, 10, 12–15, 17, 26, 28–31,
`
`and 37 by Provino; and (2) obviousness of claims 4, 6, 20, 22, 35, and 37 over
`
`Provino in view of Guillen. I have reviewed the exhibits and other documentation
`
`supporting the Petition that are relevant to the Decision and the instituted grounds.
`
`III. Background and Qualifications
`
`4.
`
`I have a great deal of experience and familiarity with computer and
`
`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
`
`5
`
`Page 5 of 53
`
`

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

`
`Case No. IPR2014-00481
`
`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 75 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 &
`
`7
`
`Page 7 of 53
`
`

`
`Case No. IPR2014-00481
`
`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
`
`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 &
`
`8
`
`Page 8 of 53
`
`

`
`Case No. IPR2014-00481
`
`Emergent Threats, the local arrangements Chair for the Financial Cryptography
`
`and Data Security Conference, and the General Chair of the Symposium on
`
`Research in Attacks and Defenses. As a leader in the field, I have also served on
`
`numerous technical program committees including the 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. IPR2014-00481
`
`IV. Level of Ordinary Skill
`
`13.
`
`I am familiar with the level of ordinary skill in the art with respect to
`
`the inventions of the ’180 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 ’180 patent. My
`
`findings are set forth below.
`
`V. Claim Terms
`
`A.
`
`14.
`
`“VPN Communication Link” (Claims 1, 17, and 33)
`
`I understand that the parties and the Board have put forth the following
`
`constructions:
`
`10
`
`Page 10 of 53
`
`

`
`VirnetX’s Proposed
`Construction
`A communication path
`between computers in a
`virtual private network
`
`Petitioner’s Proposed
`Construction
`Any communication link
`between two end points in
`a virtual private network
`
`Case No. IPR2014-00481
`
`Board’s Construction
`
`A transmission path
`between two devices 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
`
`
`
`1.
`
`A VPN Communication Link is a Link in a VPN
`
`15.
`
`I understand that the Decision states that a “VPN communication link”
`
`may be satisfied by “a link that merely connects to a virtual private network.”
`
`(Decision at 6.) I disagree with this interpretation. The ’180 patent discloses that a
`
`VPN communication link does not exist outside of a virtual private network.
`
`Dependent claims 4-10, 20-26, and 35-40 recite characteristics of “the virtual
`
`private network” underlying the independent claims’ “virtual private network
`
`communication link.” This is consistent with my understanding that a VPN
`
`communication link requires a virtual private network. 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.”
`
`11
`
`Page 11 of 53
`
`

`
`Case No. IPR2014-00481
`
`(Ex. 1001 at 52:27-29.) Then, “VPN gatekeeper 3314 provisions computer 3301
`
`and secure web server computer 3320 . . . thereby creating the VPN” between the
`
`devices. (Ex. 1001 at 52:30-33, emphasis added.) Notably, the secure server 3320
`
`“can only be accessed through a VPN communication link.” (Ex. 1001 at 52:29-
`
`30.)
`
`16. The VPN communication link is initiated to send an access request
`
`message between the querying computer 3301 and secure server 3320. (See Ex.
`
`1001 at 52:55-57.) “Further communication between computers 3301 and 3320
`
`occurs via the VPN” through the VPN communication link. (Ex. 1001 at 52:60-
`
`62.)
`
`17. One of ordinary skill in the art would understand that the VPN
`
`communication link and the virtual private network arise contemporaneously and
`
`exist between the same devices. Figure 33, depicted below, reflects this. As
`
`shown, VPN communication link 3321 traverses the unsecured public network,
`
`Internet 3302 to connect computer 3301 with secure server 3320. Thus, in my
`
`opinion, the VPN communication link is more than a simple connection to a VPN.
`
`12
`
`Page 12 of 53
`
`

`
`Case No. IPR2014-00481
`
`
`
`2.
`
`A VPN Requires a Network of Computers
`
`18.
`
`I understand that the Decision concludes that a virtual private network
`
`communication link may be satisfied by a “path between two devices.” (Decision
`
`at 7.) In my opinion, the Decision’s construction eliminates the “network” from a
`
`virtual private network and a virtual private network communication link.
`
`19. One of ordinary skill in the art would understand the plain meaning of
`
`a VPN communication link to mean that the link must exist in a VPN and therefore
`
`must be between computers in a network. In describing a VPN, the ’180 patent
`
`refers to the “FreeS/WAN” project, which has a glossary of terms. (Ex. 1001 at
`
`40:14 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
`
`13
`
`Page 13 of 53
`
`

`
`Case No. IPR2014-00481
`
`though some of its communication uses insecure connections. All traffic on those
`
`connections is encrypted.” (Ex. 2009 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.”
`
`20. The specification further describes a VPN as including multiple
`
`“nodes.” (See, e.g., Ex. 1001 at 17:14-18, referring to “each node in the network”
`
`and “vastly increasing the number of distinctly addressable nodes,” 21:61, “nodes
`
`on the network”; see also id. 19:44-46, 24:48.) More specifically, the network
`
`allows “each node . . . to communicate with other nodes in the network.” (Ex.
`
`1001 at 17:18-20.) So a device within a VPN 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. 1001 at 52:41-43, 47-49.)
`
`B.
`
`21.
`
`“Secure Computer Network Address” (Claims 1, 12, 17, 28, and
`33)
`
`I understand that the parties and the Board have put forth the following
`
`constructions:
`
`14
`
`Page 14 of 53
`
`

`
`Case No. IPR2014-00481
`
`Board’s Construction
`
`An address that requires
`authorization for access
`
`VirnetX’s Proposed
`Construction
`A network address that
`requires authorization for
`access and is associated
`with a computer capable
`of virtual private network
`communications
`
`Petitioner’s Proposed
`Construction
`A network address that
`requires authorization for
`access and is associated
`with a computer
`configured to be accessed
`through a virtual private
`network
`
`
`22.
`
`In my opinion, the parties’ proposed constructions requiring a
`
`relationship between the associated computer and the virtual private network is
`
`supported by the claim language, which recites “sending an access request message
`
`to the secure computer network address using a virtual private network
`
`communication link.” For the sending to occur as claimed, the computer must be
`
`capable of virtual private network communications. The ’180 patent specification
`
`further supports this, describing that “secure server 3320 . . . can only be accessed
`
`through a VPN communication link.” (Ex. 1001 at 52:27-30.) Thus, in my
`
`opinion, the computer must be capable of virtual private network communications.
`
`C.
`
`23.
`
`“Client Computer” (Claims 13, 15, 29, and 31)
`
`I understand that the parties and the Board have put forth the following
`
`constructions:
`
`VirnetX’s Proposed
`Construction
`User’s computer
`
`
`
`
`Petitioner’s Proposed
`Construction
`No construction proposed No construction
`
`Board’s Construction
`
`15
`
`Page 15 of 53
`
`

`
`Case No. IPR2014-00481
`
`24.
`
` In the context of the ’180 patent, the client computer is repeatedly and
`
`consistently discussed in connection with the user. The specification explains that
`
`the VPN communication link 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 40:53-56.) The specification further explains that a software
`
`module 3309 for accessing the secure computer network address using the VPN is
`
`installed on a computer 3301, (See Ex. 1001 at 50:60-64, 52:55-57), and elsewhere
`
`describes that the computer 3301 is manned by a user and equipped with a web
`
`browser 3306 and user input devices such as a keyboard, display, and/or mouse,
`
`(see id. at 49:66-50:13, 50:34-48, 50:64-51:14; FIG. 34.) In another embodiment,
`
`the specification explains that a “user’s computer 2501” includes this “client
`
`application.” (See id. at 39:53-55, 40:36-38.) Thus, in my opinion, one of
`
`ordinary skill in the art would understand that the ’180 patent equates the user’s
`
`computer 2601 with the “client computer” in the claims.
`
`16
`
`Page 16 of 53
`
`

`
`Case No. IPR2014-00481
`
`D. Other Terms
`
`25.
`
`I understand that the parties and Board have provided the following
`
`constructions. I agree that the claim language encompasses the features described
`
`in each of VirnetX’s constructions.
`
`“Access Request Message” (Claims 1, 12, 13, 17, 28, 29, and 33)
`VirnetX’s Proposed
`Petitioner’s Proposed
`Board’s Construction
`Construction
`Construction
`No construction necessary No construction proposed A signal in a packet or
`other message format that
`signifies that the first
`network device seeks
`communication,
`information, or services,
`with or from another
`device associated with the
`secure network address
`“Secure Domain Name” (Claims 1, 17, and 33)
`VirnetX’s Proposed
`Petitioner’s Proposed
`Board’s Construction
`Construction
`Construction
`A non-standard domain
`A non-standard domain
`name that corresponds to
`name that corresponds to
`a secure computer
`a secure computer
`network address and
`network address and
`cannot be resolved by a
`cannot be resolved by a
`conventional domain
`conventional domain
`name service (DNS)
`name service (DNS)
` “Secure Domain Name (Service)” (Claims 1, 17, and 30)
`VirnetX’s Proposed
`Petitioner’s Proposed
`Board’s Construction
`Construction
`Construction
`A lookup service that
`A service that can resolve
`recognizes that a query
`secure computer network
`message is requesting a
`addresses for a secure
`secure computer address,
`domain name for which a
`and returns a secure
`conventional domain
`computer network address
`name service cannot
`for a requested secure
`resolve addresses
`
`A service that provides a
`secure computer network
`address for a requested
`secure domain name
`
`A name that corresponds
`to a secure computer
`network address
`
`17
`
`Page 17 of 53
`
`

`
`Case No. IPR2014-00481
`
`domain name
`
`VI. Provino
`
`A.
`
`Provino’s Disclosure
`
`26. Provino describes a system for connecting an external device to a
`
`device on a virtual private network. (Ex. 1003, Abstract.) Referring to Figure 1 of
`
`Provino, reproduced below, when an operator at device 12(m) wishes to connect to
`
`device 13 on the Internet, the operator inputs a human-readable address of device
`
`13, causing device 12(m) to send a message to nameserver 17 requesting the
`
`corresponding Internet address of the device 13. (Ex. 1003 at 8:14-40, 11:5-11.) If
`
`the nameserver 17 has or can obtain the Internet address of device 13, it will
`
`provide that address to device 12(m). (Ex. 1003 at 8:48-51.) If nameserver 17 is
`
`unable to obtain an Internet address of device 13, it will return a message to device
`
`12(m) stating this fact. (Ex. 1003 at 11:11-14.)
`
`18
`
`Page 18 of 53
`
`

`
`Case No. IPR2014-00481
`
`
`
`27. When nameserver 17 receives a request for the address of server 31(s)
`
`on virtual private network 15, however, it may return the address of firewall 30 on
`
`virtual private network 15 because it does not have the address of server 31(s).
`
`(Ex. 1003 at 9:52-56, 10:45-55.) Therefore, to connect to server 31(s) on virtual
`
`private network 15, device 12(m) initiates establishment of a secure tunnel with
`
`firewall 30. (Ex. 1003 at 10:45-58, 12:1-4, 12:16-35.) After the secure tunnel is
`
`established, firewall 30 provides device 12(m) with the identification of second
`
`nameserver 32 inside virtual private network 15. (Ex. 1003 at 12:37-40.)
`
`28. The device 12(m) uses the secure tunnel to send nameserver 32
`
`through firewall 30 a request for the Internet address of server 31(s) corresponding
`
`to the human-readable address of the server 31(s). (Ex. 1003 at 11:14-17, 13:54-
`
`19
`
`Page 19 of 53
`
`

`
`Case No. IPR2014-00481
`
`14:33.) “[I]f the nameserver 32 does not have an association between the human-
`
`readable Internet address and an integer Internet address [for server 31(s)], the
`
`nameserver 32 can provide a response message packet so indicating.” (Ex. 1003 at
`
`11:50-53.) If device 12(m) receives the Internet address of server 31(s), “the
`
`device can use that address in generating message packets for transmission to
`
`server 31(s) . . . .” (Ex. 1003 at 11:16-25.)
`
`B. Claims 1, 17, and 33
`
`1. “Receiving a Secure Domain Name”
`
`29.
`
`I understand that independent claims 1, 17, and 33 recite “receiving a
`
`secure domain name.” The Decision suggests that Provino discloses receiving a
`
`domain name by an operator or program providing a human-readable Internet
`
`address to device 12(m), and that it is a “secure” domain name because
`
`“nameserver 32 verifies the domain name as secure . . . .” (Decision at 14, citing
`
`Ex. 1003 at 11:5-23, 13:31-40.) The Petition, on the other hand, contends that
`
`Provino’s human-readable Internet address is a “secure” domain name not because
`
`nameserver 32 verifies it, but because it is supposedly “a non-standard domain
`
`name . . . and cannot be resolved by conventional DNS,” nameserver 17. (Pet. at
`
`19.) I disagree with the Decision and with Apple.
`
`30. Provino’s nameserver 32 does not “verify” that the human-readable
`
`Internet address is a secure domain name. As explained by the Provino passages
`
`20
`
`Page 20 of 53
`
`

`
`Case No. IPR2014-00481
`
`cited in the Decision, nameserver 32’s only function is the conventional DNS
`
`function of resolving a name into an address, if possible. Specifically, nameserver
`
`32 “determines whether it has an integer Internet address associated with the
`
`human-readable Internet address provided in the request message packet,” and, if
`
`so, “generates a response message packet including the integer Internet address.”
`
`(Ex. 1003, 14:39-46.) If not, nameserver 32 “provides a response message packet
`
`so indicating.” (Ex. 1003, 11:50-53.) Provino does not disclose that nameserver 32
`
`additionally “verifies the domain name as secure,” as suggested by the Decision.
`
`31.
`
`In my opinion, even under VirnetX’s and Petitioner’s construction of
`
`“secure domain name,” Provino does not teach “receiving a secure domain name”
`
`because the human-readable Internet address of Provino is not a “non-standard”
`
`domain name. By “human-readable Internet address,” Provino simply refers to
`
`how conventional DNS “relieve[s] a user of the necessity of remembering and
`
`entering specific integer Internet addresses, . . . [by] provid[ing a] second
`
`addressing mechanism which is more easily utilized by human operators of the
`
`respective devices.” (Ex. 1003 at 1:49-52.) Provino is not concerned with
`
`“standard” versus “non-standard” domain names in its system—Provino is silent
`
`on this topic entirely. By contrast, the ’180 patent discuses exemplary “standard”
`
`domain names ending in “.com” and exemplary “non-standard” domain names
`
`21
`
`Page 21 of 53
`
`

`
`Case No. IPR2014-00481
`
`ending in “.scom.” (Ex. 1001 at 51:16-27.) Provino gives no indication that its
`
`human-readable names are anything other than standard ones.
`
`32.
`
`I understand Apple asserts that Provino’s human-readable integer
`
`Internet address is “non-standard” because Provino teaches that “the human-
`
`readable network addresses may be ‘any form of secondary or informal network
`
`address arrangements.’” (Pet. at 19, citing Ex. 1003 at 16:12-17.) In my opinion,
`
`Apple takes the quoted Provino statement out of context. It is part of a brief
`
`discussion at the end of the patent mentioning that Provino’s system can be used in
`
`other types of networks even though Provino only describes it in the context of the
`
`Internet. (Ex. 1003 at 16:8-16.) But Provino does not actually describe any such
`
`embodiments, much less teach that they use non-standard domain names in any
`
`way. Nor does Provino describe the role non-standard domain names might play
`
`within Provino’s overall framework.
`
`2. “Sending a Query Message From to a Secure Domain Name
`Service, the Query Message Requesting From the Secure
`Domain Name Service a Secure Computer Network Address
`Corresponding to a Secure Domain Name”
`
`33.
`
`In my opinion, Provino does not disclose “sending a query message to
`
`a secure domain name service, the query message requesting from the secure
`
`domain name service a secure computer network address corresponding to the
`
`domain name,” as recited in claim 1. I understand that claims 17 and 33 recite
`
`similar features. I understand that the Board has said that Provino discloses the
`
`22
`
`Page 22 of 53
`
`

`
`Case No. IPR2014-00481
`
`query message “sending” feature because “Provino’s secure nameserver 32”
`
`receives a “query from first network device 12(m).” (Decision at 15; see also Pet.
`
`at 26-27.) However, in my opinion, Provino’s “nameserver 32” is not the claimed
`
`“secure domain name service” in light of the ’180 patent’s disclosure and
`
`Petitioner’s claim construction.
`
`a)
`
`The ’180 Patent Specification
`
`34.
`
`In my opinion, one of ordinary skill in the art would understand that
`
`the specification of the ’180 patent limits the claimed “secure domain name
`
`service” to DNSs that perform more than conventional functions. In contrast,
`
`Provino’s nameserver 32 performs only conventional functions. The ’180 patent
`
`specification begins disclaiming conventional DNS functions (such as merely
`
`returning a requested address or a public key) by describing these actions as
`
`“conventional” in the prior art:
`
`Conventional Domain Name Servers (DNSs) provide a
`
`look-up function that returns the IP address of a
`
`requested computer or host.
`
`. . .
`
`One conventional scheme that provides secure virtual
`
`private networks over the Internet provides the DNS
`
`server with the public keys of the machines that the DNS
`
`server has the addresses for. This allows hosts to retrieve
`
`automatically the public keys of a host that the host is to
`
`23
`
`Page 23 of 53
`
`

`
`Case No. IPR2014-00481
`
`communicate with . . . . One implementation of this
`
`standard is presently being developed as part of the
`
`FreeS/WAN project (RFC 2535).
`
`(Ex. 1001, 39:53-40:14, emphasis added.) The specification explains that DNSs
`
`that perform no more than these conventional functions have many shortcomings,
`
`and further explains novel DNS-system embodiments that go beyond these
`
`conventional functions by supporting establishing secure communications. (Ex.
`
`1001 at 40:15-17, 52:12-29.)
`
`35. Time and again, the ’180 patent specification disparages systems with
`
`functions limited to conventional IP-address and public-key features. For example,
`
`the ’180 patent specification explains:
`
`In the convent