IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`In re Inter Partes Reexamination of
`
`US. Patent No. 7,921,211
`
`Larson et al.
`
`Issued: April 5, 2011
`
`For:
`
`AGILE NETWORK PROTOCOL FOR
`
`SECURE COMMUNICATIONS
`
`USING SECURE DOMAIN NAMES
`
`Control No.: 95/001,789
`
`Group Art Unit:
`
`3992
`
`Examiner: Roland Foster
`
`Confirmation No.: 6053
`
`\—/\¢/Nc/\¢/Q/%/%/\—/'
`
`DECLARATION OF MICHAEL ALLYN FRATTO UNDER 37 C.F.R. § 1.132
`
`1, MICHAEL ALLYN FRATTO, declare that the following statements are true to the best
`of my knowledge, information, and belief, formed afier reasonable inquiry under the
`circumstances.
`
`I.
`
`Background and Expertise
`
`I have been retained by Apple Inc. (“Apple”) to provide my opinions on topics
`1.
`raised in the above-referenced reexamination proceeding (the ’789 reexamination).
`I am a citizen
`of the United States, and reside in Syracuse, New York. My c.v. is attached as Exhibit A.
`I am
`being compensated for my time at a rate of $250.00 per hour.
`
`I am presently Editor of the Network Computing magazine and website. In that
`2.
`position, I review and evaluate networking products, including network security products, and
`report on industry developments in the field of networking and network security.
`I also write
`articles about network infrastructure, data center, and network access control items which are
`published on the Network Computing website.
`I also presently serve as an adjunct faculty
`member of School of Information Studies at Syracuse University.
`
`I understand that the ’789 reexamination involves U.S. Patent No. 7,921,211 (the
`3.
`“211 patent”), and that VimetX Inc. owns the 211 patent (“Patent Owner”).
`1 have reviewed the
`211 patent as well as the materials listed in Exhibit B.
`
`I understand that the Requestor explained that the earliest date that any of the
`4.
`claims of the 211 patent were entitled to benefit was February 15, 2000.
`I did not see any
`argument in the Response from the Patent Owner disputing this. Accordingly, I have used this
`date to make my assessments of what was known to a person of ordinary skill in the art.
`
`I am personally familiar with what a person of ordinary skill in the art would have
`5.
`known in February of 2000 about the field of the 21 1 patent.
`I believe a person of ordinary skill
`in the art would have had a master’s degree in computer science or computer engineering and
`approximately two years of experience in computer networking and computer network security.
`
`Since before 1999, I have had an extensive background and experience in network
`6.
`security systems, software and related technologies. In my position on the staff of Network
`Computing, I conducted and wrote comparative product reviews of networking and security
`
`Page 1 of 19
`
`VIRNETX EXHIBIT 2021
`
`Apple v. VirnetX
`IPR2016-00331
`
`Page 1 of 19
`
`
`
`VIRNETX EXHIBIT 2021
`Apple v. VirnetX
`IPR2016-00331
`
`

`
`Reexamination Control No. 95/001,789
`
`Declaration of Michael Allyn Fratto
`
`I also interviewed IT administrators and executives about networking and security
`products.
`issues to understand their needs and the ability of products to address those needs.
`
`By February of 2000, I had personally evaluated, tested and reviewed hundreds of
`7.
`products and technologies related to networking. During the course of a typical review, I would
`first define the set of problems the product was attempting to solve. This required me to
`understand the technologies and standards related to that problem set, and to create a set of
`comparative measures by which to assess the product, its performance and its functionality.
`When I performed a review, I would set up a test network with the product, verify its operation,
`conduct the tests, and ensure the results were accurate. During the period 1997 to 2000, my
`particular focus was on remote networking products including modems, ISDN, and virtual private
`networking products, development of secure and insecure networking standards, and network and
`host-based firewall products.
`
`II.
`
`Solana and Reed Are Printed Publications That Were Available Well Before
`
`February of 2000
`
`I understand that the Patent Owner is challenging that the Solana and Reed papers
`8.
`were publicly distributed.
`I have been told that in order to qualify as a printed publication within
`the meaning of §l02, a reference “must have been sufficiently accessible to the public interested
`in the art” prior to the filing date of the patent.
`
`From my personal experiences, I am aware that research topics developed by
`9.
`academic researchers are often presented at industry conferences. To present a topic at a
`conference, a researcher typically has to submit a written paper summarizing the topic and his or
`her research for review by the conference representatives, often well before the conference was
`held. The conference organizers select only some of these papers for presentation at the
`conference. The papers selected for presentation are usually distributed before, but no later than
`during the conference, which allows attendees to read them and discuss their findings with the
`presenting researcher. The presented papers are typically then published as a compendium, made
`available for sale, and distributed to research institutions, libraries, and on-line reference
`databases normally available to researchers. The works in these compendia can be found and
`retrieved via a variety of sources such as on-line indexes, library card catalogs, and via citations
`in other publications.
`
`Solana is a printed publication that was publicly distributed and published via this
`10.
`conventional process. In particular, Solana was publicly distributed as part of a compendium
`published by Springer-Verlag in 1998 called “Lecture Notes in Computer Science” (“LNCS”),
`specifically at Volume 1361, pages 37-51.
`I am aware of publications on the Internet that
`identify the publication date of Solana as occurring in 1997. For example, a thesis by Mr. Solana
`entitled “Collaborative domain in internet environments” cites the Solana paper in its
`Bibliography as follows:
`
`[1 19] Solana, E. and Harms, J . Flexible Internet Secure Transactions Based on
`Collaborative Domains. Proceedings of the 5th Security Protocols International
`Workshop. Paris 7th - 9th April 1997. Springer-Verlag Lecture notes in computer science;
`Vol. 1361.
`
`As the Springer-Verlag website (www.springer.com) explains, the LNCS series
`11.
`“has established itself as a medium for the publication of new developments in computer science
`and infonnation technology research and teaching - quickly, informally, and at a high level.” It
`
`Page 2 of 19
`
`Page 2 of 19
`
`

`
`Reexamination Control No. 95/001,789
`
`Declaration of Michael Allyn Fratto
`
`further explains that “LNCS has always enjoyed close cooperation with the computer science
`R&D community, with numerous renowned academics, and with prestigious institutes and
`learned societies. Our mission is to serve this community by providing a most valuable
`publication service.” According to the publisher’s website, the book in which Solana was
`published “constitutes the strictly refereed post-workshop proceedings of the 5th International
`Workshop on Security Protocols, held in Paris, France, in April l997.” Moreover, the publisher’s
`website indicates that the papers in the compendium were presented at the workshop.
`In
`particular, it notes: “The 17 revised full papers presented address all current aspects of security
`protocols.” Thus, as is customary, the papers of this compendium were distributed to the
`conference attendees and then collected, edited, and published. In short, Solana was formally
`published and publicly available as of the conference date in 1997, and no later than 1998 when
`Volume 1361 of Lecture Notes in Computer Science was formally published. Either way, the
`publication and public dissemination of Solana occurred well before the February 2000 date by
`which the 211 is to be evaluated. See Exhibit C.
`
`Reed is a printed publication that was distributed as part of the published
`12.
`proceedings of the 12"‘ Annual Computer Security Applications Conference that occurred in
`1996. The Association of Computing Machinery (ACM) website lists the publication date of
`Reed as follows:
`
`Proxies For Anonymous Routing
`
`Authors:
`
`M~_G._fiee«;l
`E...E..§.YJL€ES.Ql1
` fl
`
`.. _.....r.'.
`
`' 1996 Article
`
`Iihl!_QLi:2n§£m3 ISBN 20-8 186 ~7606-X
`
`Published in:
`. proceeding
`ACSAC '96 Proceedings of the 12th Annual Computer Security Applications
`Congerence
`page 95
`IEEE Compute! Society Washinflan. DC. USA 01996
`
` $
`- Downloads (6 Wnks): 0
`- Downloads (12 Months): 0
`- Citation Count: 22
`
`As its citation indicates, the Reed publication was publicly distributed during the
`13.
`12th Annual Computer Security Applications Conference held in 1996, a fact that is noted on
`page 1 of the publication. The IEEE website confirms that the 12"‘ Annual Computer Security
`Applications Conference was held between December 9-13, 1996. The ACSAC website also
`indicates in program materials for this Conference that Mr. Reed’s paper was presented and made
`available to attendees in the session between 3:30 and 5:30 on Wednesday December 11, 1996 in
`the Track B session of the conference. http://www.acsac.org/pastconf/1996/wed.html. The
`program materials note that “Paper sessions include refereed papers that describe the latest in
`implementations and applications-oriented research.” See id.
`
`Reed also was distributed to the public in 1996 as part of a formally published
`14.
`treatise published by the IEEE Computer Society entitled “ACSAC ’96 Proceedings of the 12th
`Annual Computer Security Applications Conference” (ISBN:0-8186-7606-X). The IEEE
`Computer Society is a well-known and highly regarded publisher of technical papers in the field
`of computers and computer networking. As the IEEE website explains, in the Computer Society
`subsection, it “has been providing conferences and workshops with professional publishing
`
`Page 3 of 19
`
`Page 3 of 19
`
`

`
`Reexamination Control No. 95/001,789
`
`Declaration of Michael Allyn Fratto
`
`services for over 35 years.” See,
`http://wvvw.ieee.org/publications_standards/publications/authors/conference_proceedings.html.
`The IEEE Computer Society’s website also confirms that its post—conference treaties compiling
`papers presented at its conferences are made publicly available. See Id. at
`http://wvvw.computer.org/portal/web/cscps/faq. The IEEE website also notes that “Proceedings
`published by CPS are submitted for professional indexing.” Id. at
`http://www.computer.org/portal/web/cscps/faq.
`
`Thus, the Reed printed publication was published and publically available as of the
`15.
`conference date and at least by December 31, 1996 when the ACSAC ’96 Proceedings treaties
`was published. Either way, the Reed publication was publicly disseminated well before February
`15, 2000.
`
`III.
`
`The Request For Comments (“RFCs”) Documents are Printed Publications
`
`On pages 8-9, of the Response, the Patent Owner contends that there is no
`16.
`evidence that several of the RFC documents cited in the Request and the Office Action were
`published on the dates indicated on each of the RFC documents.
`I disagree.
`
`The Internet Engineering Task Force (IETF) is responsible for the standardization
`17.
`process and governance of Internet protocols and processes. The IETF uses several types of
`documents to publish the work within the IETF and uses an established publication procedure.
`An RFC is a “Request for Comments” publication. The RFC series publication began in 1969.
`http://www.rfc-editor.org/RFCoverview.html. The RFC series is the publication vehicle for
`technical specifications as well as policy documents produced by the IETF, and also the IAB
`(lntemet Architecture Board), and the IRTF (Internet Research Task Force). http://www.rfc-
`editor.org/RFCoverview.html. As the IETF website explains, the RFC series “[c]ontains
`technical and organizational documents about the Internet, including the technical specifications
`and policy documents produced by the Internet Engineering Task Force.” http://www.rfc-
`editor.org/RFC Editor home page. The RFC editor publishes RFCs online.
`Id.
`
`The specific process for publication of RFCs as of October 1996 was set forth in
`18.
`Best Current Practice 9 (BCP 9). That document explains that RFC’s are “published through the
`RFC mechanism.” BCP 9 at 7, available at http://tools.ietf.org/html/bcp9. According to that
`mechanism “Each distinct version of an Internet standards-related specification is published as
`part of the ‘Request for Comments’ (RFC) document series. This archival series is the official
`publication channel for Internet standards documents and other publications of the IESG, IAB,
`and Internet community.” Id. at 5. As further explained, “RFCs can be obtained from a number
`of Internet hosts using anonymous FTP, gopher, World Wide Web, and other Internet document-
`retrieval systems.” Id.
`
`The IETF website also explains that “Historically, all RFCs were labeled Network
`19.
`Working Group. ‘Network Working Group’ refers to the original version of today’s IETF when
`people from the original set of ARPANET sites and whomever else was interested -- the meetings
`were open -- got together to discuss, design, and document proposed protocols [RFC0003].”
`Section 3.1 of RFC 5741 at 3 available at (http://www.rfc-editor.org/rfc/rfc5741.txt).' As fiirther
`
`1 The top most left line in each RFC identifies the working group within which the RFC was
`discussed, e. g., Internet Engineering Task Force (IETF), Internet Architecture Board (IAB),
`Internet Research Task Force (IRTF), and Independent Submission.
`Id. at 3-4.
`
`Page 4 of 19
`
`Page 4 of 19
`
`

`
`Reexamination Control No. 95/001,789
`
`Declaration of Michael Allyn Fratto
`
`explained, the right column of each RFC publication contains the name of the author and his or
`her affiliation, as well as month and year in which that the RFC was published and made publicly
`available. Id. at 3. The RFC number is the number “assigned by the RFC Editor upon
`publication of the document.” Id. at 4.
`
`As further explained by the IETF website “When an RFC is published, an
`20.
`announcement is sent to ietf-announce and rfc-dist mailing lists. The canonical URI is of the
`form: http://www.rfc—editor.org/rfc/rfcXXXX.txt.” See http://www.rfc-
`editor.org/pubprocess.html.
`
`The IETF maintains historical archives of all RFCs that have been published
`21.
`through its transparent procedures. The month and year of the announcement of each RFC
`corresponds to the publication date reported on each RFC.
`In my experience, announcements
`include a hyperlink to allow viewers of the announcement to jump directly to the RFC document.
`
`As further noted on the IETF website “Published RFCs never change.”
`22.
`http://www.ietf.org/rfc.html. “When an RFC is updated, it gets a new number.”
`http://www.ietfiorg/newcomershtml. Thus, if a topic addressed in an RFC results in a new
`version of that standard, protocol or topic, the new version will be published with a different RFC
`number and in a document reflecting the new date of distribution of that document.
`
`The IETF’s process is fully transparent and anyone can join and participate via
`23.
`email lists (where the bulk of the work is done) free of charge. Individuals working in the field of
`computer networking in February of 2000 would be very familiar with the RFC publication
`procedures administered by the IETF, and would know that RFCs are indexed, organized by
`subject matter, published in a regular and transparent manner, and distributed via numerous
`pathways. Indeed, an essential feature of the IETF process is that it is a public and wholly
`transparent process.
`
`Thus, the RFC documents cited in the Request and in the Office action would each
`24.
`have been published during the month and year that is listed in the heading of the RFC in
`accordance with IETF BCP 9. Each of these RFCs also would have been publicly distributed by
`the IETF and armounced via their mailing list during the month and year listed in the heading of
`the RFC, and thus would have been publicly available without restriction as of the date noted on
`the document.
`
`Page 5 of 19
`
`Page 5 of 19
`
`

`
`Reexamination Control No. 95/001,789
`
`Declaration of Michael Allyn Fratto
`
`IV.
`
`Initial Comments on the Claims and Specification of the 211 Patent
`
`The 21] claims use the term “domain name service system” (DNS systems) to
`26.
`refer to systems that are able to establish secure communication links. This phrase is not used in
`the 211 patent other than in the claims.
`
`The 21 1 claims indicate the DNS systems must be able to (i) store domain names
`27.
`and associated IP addresses of those domain names and (ii) receive domain name queries for
`network addresses. These two functions together constitute the well-known DNS lookup
`functionality that is integral to the domain name system of the Internet. The 21 1 patent uses the
`term “DNS server” to refer to this look-up functionality. See, e. g., 21 1 patent at col.3 8, 11.57-60.
`(“Conventional Domain Name Servers (DNSS) provide a look-up function that returns the IP
`address of a requested computer or host.”)
`
`The 211 patent uses a different term, “DNS proxy server,” to refer to the
`28.
`functionality in the DNS system that creates a secure communications link. See, e. g., 211 patent
`at co1.6, ll.7-9 (“a DNS proxy server that transparently creates a virtual private network in
`response to a domain name inquiry”). The 211 patent also uses different terms when describing
`combinations of DNS server and DNS proxy functionalities. For example, the 21 1 patent states
`“a modified DNS server 2602 includes a conventional DNS server function 2609 gig a DNS
`proxy 2610.” 211 patent at col.39, 1.51-53. Similarly, it says that a “specialized DNS server”
`“traps DNS requests, and if the request is from a special type of user
`the server does not return
`the true IP address of the target node, but instead automatically sets up a virtual private network
`between the target node and the user.” 211 patent at col.39, 11.30-32. Thus, in the 21 l patent and
`its claims, the conventional lookup functionality (i.e., the “DNS server”) is different from
`functionality that establishes secure communication links (i.e., the “DNS proxy server”) and both
`are different from a “DNS system” which has at least these two functionalities.
`
`The claims also require the DNS systems to “indicate in response to the query [for
`29.
`a network address] that the domain name service system supports establishing a secure
`communication link” (claim 1). There is no discussion in the 211 patent of what constitutes such
`an indicat[ion] or how to implement this functionality.
`
`The way the 21 1 claims are written does not require the “indicate” function to be
`30.
`implemented in the DNS lookup step (i.e., the “DNS server” function). This make sense, because
`a DNS lookup function, like an address book, is simply an information resource service, e. g., it
`pairs information about domain names and their corresponding IP addresses, and delegates name
`resolution for domain names for which it does not have information to other DNS’s, consistent
`with the description of the DNS function in the 211 patent at col.38, ll.58-64. I also note the
`“indicat[ion]” required by the claims is that the “DNS system” “supports establishing” a secure
`communication link. One of ordinary skill in the art would understand “supports establishing” to
`mean simply “assists” or “facilitates” establishing a secure communication link.
`
`The 211 patent claims also do not require the DNS systems to implement all of the
`31.
`functionalities listed in the claims on a single computer or within a single process. Instead, the
`21 1 patent makes it clear that a DNS system having these functionalities can be made up of
`different machines and/or distinct and separate processes, and that these can be distributed
`services. For example, the 211 patent states at col.40, ll.27-31, that “It will be appreciated that
`the functions of DNS proxy 2610 and DNS server 2609 can be combined into a single server for
`convenience. Moreover, although element 2602 is shown as combining the functions of two
`
`Page 6 of 19
`
`Page 6 of 19
`
`

`
`Reexamination Control No. 95/001,789
`
`Declaration of Michael Allyn Fratto
`
`servers, the two servers can be made to operate independent y.” (emphasis added). Thus, a DNS
`system according to the claims can be distributed across multiple computer systems, can be
`implemented using elements of the system at remote locations, and can be implemented using
`distinct processes as long as they, in the aggregate, provide the functionalities listed in the claims.
`This also is consistent with the network-based nature of these DNS systems, and because they
`operate in compliance with Internet standards.
`
`I note that Dr. Keromytis states in {[16 of his Declaration that in one embodiment
`32.
`the “DNS server” itself “supports the establishment of a secure communication link” and that it
`does so “beyond merely returning a requested IP address or public key.” This description
`conflicts with what the 211 patent is describing. Specifically, his comments are describing the
`features of a modified DNS server in Figure 26, which includes a conventional DNS server
`function (item 2609) Q1 separate functionalities that handle establishing secure communication
`links, which is referred to as the DNS proxy function (item 2610). As I explain above, the
`“modified DNS server” corresponds to a “DNS system” in the claims, not the DNS server alone.
`
`I also note that Dr. Keromytis’ description is not consistent with the claim
`33.
`language which does not reguire the DNS server element (i.e., the elements associated with the
`lookup function) to perform all of the functions of the “specialized DNS server” identified in the
`211 specification. For example, nothing in the claims require “trapping” or returning non-true IP
`addresses of the target node or of “automatically” setting up anything.
`
`I also disagree with several of Dr. Keromytis’ statements implying that the 211
`34.
`claims require lookup functions to be performed differently than how these lookups are done by
`conventional DNS servers. E_i;§t, the claims do not make this distinction — they either require the
`systems store domain names and associated IP addresses (e. g., claims 1, 36 and 60) or perform
`conventional DNS lookups (e.g., claim 15, which states “the domain name service system is
`configured to provide, in response to the query, the network address corresponding to a domain
`name from the plurality of domain names and the corresponding network addresses”). Second,
`the 211 description that Dr. Keromytis points to in 111117-19 of his Declaration makes clear that
`conventional DNS server function is distinct from the elements of the DNS system that establish
`the secure communication link. See, e. g., 211 at col.39, 1.19-31 (explaining that DNS systems
`(2062) in Figure 26 contain distinct DNS server (2609) and a DNS proxy (2610) elements).
`
`V.
`
`Solana
`
`Dr. Keromytis acknowledges that Solana describes a domain-based security
`35.
`architecture for lntemet transactions, but seems to have overlooked or misunderstood several
`important features of the Solana systems and the environments in which they are to be deployed.
`In particular, Dr. Keromytis does not acknowledge in his analysis that systems such as the Solana
`system that are interoperable with Internet standards must inherently have certain capabilities,
`such as communicating in the TCP/IP protocol and performing DNS lookups.
`
`Solana describes a Collaborative Domains security architecture that can be used to
`36.
`handle “a generic Internet transaction (such as a WWW query...) taking place between two
`principals,... initiators (. . .the WWW client...) and responders (...the WWW server. . .).” Solana
`at 42. WWW queries typically contain domain names that require resolution into IP addresses for
`the query to be acted upon. To be able to handle WWW queries as it states it does, the Solana
`systems must be able to resolve domain names into IP addresses. A person familiar with Internet
`
`Page 7 of 19
`
`7
`
`Page 7 of 19
`
`

`
`Reexamination Control No. 95/001,789
`
`Declaration of Michael Allyn Fratto
`
`communication standards would recognize that this means that the Solana systems must perform
`DNS lookup functions.
`
`Solana also explains that its systems are designed to work within existing domain
`37.
`structures at the IP level (e.g., the public Internet structure). Solana at 40-41 (“[W]e assume that
`the criteria to compose domains (for instance, according to security or administrative needs) are
`already established and that a naming convention for domains has been defined”) See also id.
`(indicating that in designing the Solana systems, they “concentrate exclusively on the impact that
`the domain collaboration might have in the provision of flexible and manageable mechanisms to
`secure Internet transactions.”). Thus, conventional domain name resolution processing occurs.
`
`Solana describes an architecture that readily accommodates this required DNS
`38.
`lookup function. For example, Solana indicates that “naming information” is stored in the
`Directory Service (DS) using “existing naming infrastructures (DNS-sec, X.509). . .” Solana at 43.
`The “naming information” stored in the DS enables the locating and retrieval of “certificates that
`bind domains to their public keys” which is necessary to enable the secure inter-domain
`communications per the Solana scheme. DNS-sec refers to “DNS Security Extensions”
`(published as RFC 2065 in January of 1997). See Exhibit D. DNS-sec is an add-on to the DNS
`server system and authenticates data by digitally signing records used in a DNS query. DNS-sec
`cannot perform its function as stand-alone software ~ it must be deployed through a DNS servers
`that conventionally respond to domain-to—IP translation queries. Thus, by indicating that the
`“naming information” is stored in a DNS-sec-based naming infrastructure, Solana necessarily is
`indicating that (i) the DS depicted in Fig. 1 of Solana includes DNS servers that incorporate
`DNS-sec security extensions, and (ii) the “naming information” stored in the DS must include
`both domain names and corresponding IP addresses, as both are used by these DNS servers.
`Also, I note that this explanation is consistent with the depiction of the DS as containing multiple
`servers — this is what the stacked cylinders in Figure 1 on page 43 of Solana are indicating.
`
`Solana also necessarily incorporates DNS server functionality based on the design
`39.
`of the DNS systems shown in Figure 1. Specifically, Solana shows an initiator (a user on a
`computer) communicating (e. g. sending a “WWW query”) through an encrypted and
`authenticated channel to a “Domain Border System” (DBS) element.
`Id. at 43-44. Solana
`explains that the DBS “is the active player in the domain collaboration...” Id. at 43. As shown in
`Figure 1, the DBS receives the communication (e.g., a WWW query), and acts in response to it
`(e.g., by performing authentication, interacting with the LAD, DS, DAK and establishing
`authenticated or encrypted sessions between the principals). In this role, the DBS necessarily will
`perform DNS lookups using DNS servers (e.g., if the WWW query contains a domain name
`instead of an IP address). This description is consistent with the idea that the Solana systems
`integrate mechanisms (e.g., conventional DNS servers) to resolve domain names into IP
`addresses —~ whether in the DS or in other operational elements of the Solana system, such as the
`Domain Border System (DBS). See, e. g., Solana at 43-44 and Figure l.
`
`In 1] 25 of his Declaration, Dr. Keromytis states that “Solana explains that the
`40.
`‘naming information’ is stored in the DS in the form of UNIs, which may include “a common
`name, an E-mail address, or a network address.” This is incorrect.
`
`According to Solana, UNI (Uniform Naming Information) consists of a common
`41.
`name (e.g., “Joe Smith”), an email address (e.g., joe@smith.com) or a network address (e.g., an
`IP address or a domain name) that is uniquely associated with a principal involved in a
`
`Page 8 of 19
`
`Page 8 of 19
`
`

`
`Reexamination Control No. 95/001,789
`
`Declaration of Michael Allyn Fratto
`
`transaction being mediated by the Solana system. See Solana at 43 (a UNI is “needed to
`designate principals and domains globally and unequivocally”). For a “WWW query,” the
`principals will be a web client (the initiator) and a web server (the responder), and the UNI will
`be an email address or a network address. Both of these types of UNI will contain enough
`information (a user and a domain) to uniquely identify each principal. Solana explains that UNIS
`are stored in a Local Authentication Database (LAD) in table, and have a one-to-one relationship
`to the public key of the principal (e.g., one network address to one public key). See Id. (Fig. 1).
`
`Solana also explains that UNI information (e.g., the network address of a
`42.
`principal) may optionally be “published in the Directory Service.” Thus, contrary to what Dr.
`Keromytis is asserting, Solana is @ saying that “naming information” is published in the DS Q
`the form of a UNI as Dr. Keromytis states, and certainly not only in the form of an IP address.
`Instead, Solana explains that while UNI information may be published in the DS, “naming
`information” (including optional IP addresses) is stored in the DS using “existing naming
`infrastructures (DNS-sec, x.509)....” Id.
`
`Dr. Keromytis’ explanations at fill] 23-27 of his Declaration make no sense given
`43.
`how the Solana systems must function. Solana explains that its systems establish domain-to-
`domain relationships to allow principals in different domains to interact with each other without
`having to independently establish secure principal-to-principal relationships for each transaction.
`See, e. g., id. at 42. The Solana DNS systems do this by publishing “naming information” in a
`Directory Service (DS) linking particular domains to certificates that securely bind domains to
`their public keys.
`Id. at 43. Other domains can access this published information, find the public
`keys of domains using the “naming information,” and then use the public keys to establish a
`secure domain-to-domain communication link. In this scheme, simple logic dictates that the
`domain name will be published as part of the “naming information” in the DS.
`
`This also makes sense because a domain p_a_m_e is a single, fixed identifier for a
`44.
`domain that is used to navigate to the domain via the Internet domain name system. Publishing
`the domain E in the DS enables other domains to reliably and efficiently locate the keys
`needed to set up inter-domain relationships. By contrast, publishing E; IP addresses in the DS
`as Dr. Keromytis suggests would be illogical. 1, many different IP addresses can be
`associated with a single domain, and these associations may change or be eliminated, so if only
`IP addresses were included in “naming information,” it would not reliably identify domains, and
`if were disassociated from the domain, would render the Solana system inoperative. Second,
`Solana says that information stored as UNI in the LAD is not always published in the DS. If Dr.
`Keromytis were correct (i.e., that a UNI only can contain an IP address and is the only thing
`published in the DS), situations would arise where m “naming information” would be published.
`This would make discovery of the public keys needed for the Solana system to work impossible
`(e.g., requesting a certificate by searching for an “unpublished” IP address would fail because that
`information would not be in the DS). Third, publishing IP addresses in the DS to identify
`certificates binding public keys to domains could compromise the security of the Solana system
`(e.g., by exposing IP addresses of principals). Finally, nothing in Solana says that “naming
`information” published in the DS cannot include a domain name and an associated IP address.
`
`Solana also indicates its system communicates in conformance with the TCP/IP
`45.
`protocol. Solana at 2-3, 42 n.2. The Domain Name System—as defined in, for example, RFCs
`1034 and I035—was designed to address the growth of the Internet by providing reliable
`methods for routing IP packets under the TCP/IP protocol to their proper destination. RFC 1180
`
`Page 9 of 19
`
`Page 9 of 19
`
`

`
`Reexamination Control No. 95/001,789
`Declaration of Michael Allyn Fratto
`
`at 21. The concept of DNS was thus devised “to provide a mechanism for naming resources” that
`has broad applicability across “different hosts, networks, protocol families, internets, and
`administrative organizations.” RFC 1035 at 2. As explained in RFC 1034, a WWW “query
`names the domain name of interest,” and such “queries for address