IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`In re Inter Partes Reexamination of
`
`U.S. Patent No. 7,418,504
`
`Larson et al.
`
`Issued: August 26, 2008
`
`For:
`
`AGILE NETWORK PROTOCOL FOR
`SECURE COMMUNICATIONS
`
`USING SECURE DOMAIN NAMES
`
`Control No.: 95/001,788
`
`Group Art Unit:
`
`3992
`
`Examiner: Roland Foster
`
`Confirmation No.: 5823
`
`\/\/\J\./\/\/g/M
`
`DECLARATION OF MICHAEL ALLYN FRATTO UNDER 37 C.F.R. § 1.132
`
`I, MICHAEL ALLYN FRATTO, declare that the following statements are true to the
`best of my knowledge, information, and belief, formed after reasonable inquiry under the
`circumstances.
`
`I.
`
`Background and Expertise
`
`I have been retained by Apple Inc. (“Apple”) to provide my opinions on topics
`I.
`raised in the above-referenced reexamination proceeding (the ‘788 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 ‘788 reexamination involves U.S. Patent No. 7,418,504 (the
`3.
`“’504 patent”), and that VimetX Inc. owns the ’504 patent (“Patent Owner”).
`I have reviewed
`the ‘504 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 ‘504 patent were entitled to benefit was February 15, 2000.
`1 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.
`
`1 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 ‘504 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.
`
`Page 1 of 19
`
`VIRNETX EXHIBIT 2020
`
`Apple V. Vi1'netX
`IPR2016-00331
`
`Page 1 of 19
`
`
`
`VIRNETX EXHIBIT 2020
`Apple v. VirnetX
`IPR2016-00331
`
`

`
`Reexamination Control No. 95/001,788
`Declaration of Michael Allyn Fratto
`
`Since before 1999, l 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
`products. I also interviewed IT administrators and executives about networking and security
`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 intemet environments” cites the Solana paper in its
`Bibliography as follows:
`
`[119] Solana, E. and Harms, J. Flexible Internet Secure Transactions Based on
`Collaborative Domains. Proceedings of the 5th Security Protocols International
`
`Page 2 of 19
`
`Page 2 of 19
`
`

`
`Reexamination Control No. 95/001,788
`Declaration of Michael Allyn Fratto
`
`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 information technology research and teaching - quickly, informally, and at a high level.” It
`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 1997.” 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 ’504 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"‘ Armual Computer Security Applications Conference that occurred in
`1996. The Association of Computing Machinery (ACM) website lists the publication date of
`Reed as follows:
`
`Proxies or Anonymous Routing
`
`Authors: M._G..Be.ed
`L
`D_M_Gnldschlaa
`
`1996 Article
`
`nmmimmma ISBN:0-8186-7606-X
`
`- Proceedlng
`ACSAC '96 Proceedings of the 12th Annual Computer Security Applications
`Conference
`Page 95
`IEEE computer saucy vvasnington. oc. USA @1993
`
`—-Iainunmemcs
`' Downloads (8 Weeks); 0
`‘ Downloads (12 Months): 0
`~ Gtabn 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"‘ Armual 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://wvvw.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
`
`Page 3 of 19
`
`Page 3 of 19
`
`

`
`Reexamination Control No. 95/001,788
`Declaration of Michael Allyn Fratto
`
`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
`Armual Computer Security Applications Conference” (ISBN:O-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
`services for over 35 years.” See,
`http://www.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://www.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
`15.
`the 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.
`1 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
`(Internet Architecture Board), and the IRTF (lntemet Research Task Force). http://wvvw.rfc-
`editor.org/RFCoverview.html. As the IETF website explains, the RFC series “[c]ontains
`technical and organizational documents about the lntemet, 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 charmel for Internet standards documents and other publications of the IESG, lAB,
`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.
`
`Page 4 of 19
`
`Page 4 of 19
`
`

`
`Reexamination Control No. 95/001,788
`Declaration of Michael Allyn Fratto
`
`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/rfc574l .txt).' As firrther explained, the right colurrm 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.
`armouncement is sent to ietf-armounce 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 armouncement of each RFC
`corresponds to the publication date reported on each RFC.
`In my experience, armouncements
`include a hyperlink to allow viewers of the armouncement 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.ietforg/newcomers.html. 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 lETF’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
`24.
`each 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.
`
`I The top most left line in each RFC identifies the working group within which the RFC was
`discussed, e.g., lntemet Engineering Task Force (IETF), lntemet Architecture Board (IAB),
`lntemet Research Task Force (IRTF), and Independent Submission. Id. at 3-4.
`
`Page 5 of 19
`
`Page 5 of 19
`
`

`
`Reexamination Control No. 95/001,788
`Declaration of Michael Allyn Fratto
`
`IV.
`
`Initial Comments on the Claims and Specification of the ’504 Patent
`
`The ’504 claims use the term “domain name service system” (DNS systems) to
`25.
`refer to systems that are able to establish secure communication links.2 This phrase is not used
`in the ’504 patent other than in the claims.
`
`The ’504 claims indicate the DNS systems must be able to (i) store domain names
`26.
`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 ’504 patent uses the
`term “DNS server” to refer to this look-up fimctionality. See, e.g., ’504 patent at col.39, ll.7-9.
`(“Conventional Domain Name Servers (DNSs) provide a look-up function that returns the IP
`address of a requested computer or host.”)
`
`The ’504 patent uses a different term, “DNS proxy server,” to refer to the
`27.
`functionality in the DNS system that creates a secure communications link. See, e.g., ’504 patent
`at col.6, ll.11-13 (“a DNS proxy server that transparently creates a virtual private network in
`response to a domain name inquiry”). The ’504 patent also uses different terms when describing
`combinations of DNS server and DNS proxy functionalities. For example, the ’504 patent states
`“a modified DNS server 2602 includes a conventional DNS server function 2609 E a DNS
`proxy 2610.” ’504 patent at col.39, 1.67 — col.40, l.5. 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.” ’504 patent at col.39, ll.46-51. Thus, in the ’504
`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 “comprise an indication that the
`28.
`domain name service system supports establishing a secure communication link” (claim I).3
`There is no discussion in the ’504 patent of what constitutes an indication that the DNS system
`supports establishing a secure communication link or how to implement this fimctionality.
`
`The way the ’504 claims are written does not require the “indication” function to
`29.
`be implemented in the DNS lookup step (i.e., the “DNS server” function). At a minimum, this
`means that the claimed DNS systems can implement the required “indication” functionality
`independently from the DNS lookup fimctionality. 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 ’504 patent at col.39, ll.7-13. I also note the
`
`Claims 1-35 define DNS systems and claims 36-59 define media including computer executable code used
`2
`to create DNS systems. Claim 60 defines a process with steps corresponding to ftmctions listed in claims 1 and 36.
`
`The other independent claims (36, 60) indicate that the DNS system must support an indication that the
`3
`DNS system supports establishing a secure communication link.
`
`Page 6 of 19
`
`Page 6 of 19
`
`

`
`Reexamination Control No. 95/001,788
`Declaration of Michael Allyn Fratto
`$9 66
`“indication” 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 ’504 patent claims also do not require the DNS systems to implement all of
`30.
`the functionalities listed in the claims on a single computer or within a single process. Instead,
`the ’504 patent makes it clear that a DNS system having these fimctionalities can be made up of
`different machines and/or distinct and separate processes, and that these can be distributed
`services. For example, the ’504 patent states at col.40, 11.44-48, 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 fimctions of two
`servers, the two servers can be made to operate independently.” (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 fimctionalities 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 1] 16 of his Declaration that in one embodiment
`31.
`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 ’504 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) ali separate fimctionalities that handle establishing secure communication
`links, which is referred to as the DNS proxy fimction (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
`32.
`language which does not reguire the DNS server element (i.e., the elements associated with the
`lookup fimction) to perform all of the fimctions of the “specialized DNS server” identified in the
`’504 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 ’504
`33.
`claims require lookup fimctions to be performed differently than how these lookups are done by
`conventional DNS servers. 1, the claims do not make this distinction — they either simply
`require the systems store domain names and associated IP addresses (e.g., claims 1, 36 and 60) or
`to 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”).
`See also, e.g., claims 20, 21 (the DNS system “comprises a domain name database, and wherein
`the domain name database stores the plurality of domain names and the corresponding network
`addresses”). Second, the ’504 description that Dr. Keromytis points to in 111] 17-19 of his
`Declaration makes clear that conventional DNS server fimction is distinct from the elements of
`
`the DNS system that establish the secure communication link. See, e.g., ’504 patent at col.39,
`1.67 — col.41, 1.59 (explaining that the DNS systems (2062) in Figure 26 contain distinct DNS
`server (2609) and a DNS proxy (2610) elements).
`
`Page 7 of 19
`
`Page 7 of 19
`
`

`
`Reexamination Control No. 95/001,788
`Declaration of Michael Allyn Fratto
`
`V.
`
`Solana
`
`Dr. Keromytis acknowledges that Solana describes a domain-based security
`34.
`architecture for Internet 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
`35.
`to 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. WW 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 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
`36.
`structures at the IP level (e.g., the public Internet structure). See Solana at 40-41 (“. . .we 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 does occurs.
`
`Solana describes an architecture that readily accommodates this required DNS
`37.
`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
`carmot 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 fimctionality based on the design
`38.
`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
`
`Page 8 of 19
`
`Page 8 of 19
`
`

`
`Reexamination Control No. 95/001,788
`
`Declaration of Michael Allyn Fratto
`
`authenticated charmel 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 1.
`
`In 1] 25 of his Declaration, Dr. Keromytis states that “Solana explains that the
`39.
`‘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
`40.
`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
`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 UNls
`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
`41.
`principal) may optionally be “published in the Directory Service.” Thus, contrary to what Dr.
`Keromytis is asserting, Solana is ngt saying that “naming information” is published in the DS in
`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 111] 23-27 of his Declaration make no sense given
`42.
`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 name is a single, fixed identifier for a
`43.
`domain that is used to navigate to the domain via the Internet domain name system. Publishing
`
`Page 9 of 19
`
`Page 9 of 19
`
`

`
`Reexamination Control No. 95/001,788
`Declaration of Michael Allyn Fratto
`
`the domain ngarrne in the DS enables other domains to reliably and efficiently locate the keys
`needed to set up inter-domain relationships. By contrast, publishing my 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. lf 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 Q “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
`i