VirnetX Exhibit 2020
`Apple Inc. v. VirnetX Inc.
`IPR2016-01585
`
`Page 1 of 19
`
`

`

`Reexamination Control No. 95/001,788
`Declaration of Michael Allyn Fratto
`
`Since before 1999, | have had an extensive background and experience in network
`6.
`security systems, software and related technologies. In myposition 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 andthe 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 ofa 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 whichto assess the product, its performanceandits functionality.
`WhenI performeda review, I would set up a test network with the product, verify its operation,
`conductthe tests, and ensure the results were accurate. During the period 1997 to 2000, my
`particular focus was on remote networking products including modems, ISDN,andvirtual
`private networking products, development of secure and insecure networking standards, and
`networkand host-based firewall products.
`
`II.
`
`Solana and Reed Are Printed Publications That Were Available Well Before
`February of 2000
`
`I understand that the Patent Owneris challenging that the Solana and Reed papers
`8.
`were publicly distributed.
`I have beentold that in order to qualify as a printed publication within
`the meaning of §102, 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 researchertypically has to submit a written paper summarizing the topic andhis or
`her research for review by the conference representatives, often well before the conference was
`held. The conference organizers select only someof 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 papersare typically then published as a compendium,
`madeavailable 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.
`
`Solanais 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 domainin internet environments”cites the Solana paperin 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 LNCSseries
`11.
`“thas 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 “LNCShas always enjoyed close cooperation with the computer science
`R&D community, with numerous renowned academics, and with prestigiousinstitutes 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 proceedingsofthe 5th International
`Workshopon Security Protocols, held in Paris, France, in April 1997.” Moreover, the
`publisher’s website indicates that the papers in the compendium werepresented at the workshop.
`In particular, it notes: “The 17 revised full papers presented addressall 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.
`proceedingsofthe 12" Annual Computer Security Applications Conference that occurred in
`1996. The Association of Computing Machinery (ACM)websitelists the publication date of
`Reed as follows:
`
`Proxies
`
`For Anonymous Routing
`
`tableofcontents ISBN: 0-8 186 -7606-X
`
`~~| 1996 Artice
`Authors: MG.Reed
`
`PE,Syverson
`
`D.M.Goldschiag
`
`Published in:
`+ Proceeding
`ACSAC '96 Proceedings of the 12th Annual Computer Security Applications
`Conference
`Page 95
`{EEE Computer Society Washingtan, OC, USA ©1988
`
`—4 Bibliometrics
`* Downloads (6 Weeks): 0
`+ Downloads (12 Months): 0
`+ Citation Count: 22
`
`Asits 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
`page1 of the publication. The IEEE website confirmsthat 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
`madeavailable to attendees in the session between 3:30 and 5:30 on Wednesday December11,
`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.
`
`Page 3 of 19
`
`Page 3 of 19
`
`

`

`Reexamination Control No. 95/001,788
`Declaration of Michael Allyn Fratto
`
`Reed also wasdistributed to the public in 1996 as part of a formally published
`14.
`treatise published by the IEEE Computer Society entitled “ACSAC 96 Proceedingsof 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 papersin 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 confirmsthat its post-conference treaties compiling
`papers presentedat its conferences are made publicly available. See /d.at
`http://www.computer.org/portal/web/cscps/faq. The IEEE website also notes that “Proceedings
`published by CPS are submitted for professional indexing.” Jd. 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.
`
`Ill.
`
`The Request For Comments (“RFCs”) Documents are Printed Publications
`
`On pages 8-9, of the Response, the Patent Ownercontendsthat there is no
`16.
`evidence that several of the RFC documentscited 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 governanceofInternet protocols and processes. The IETF usesseveral types of
`documents to publish the work within the IETF and uses an established publication procedure.
`An RFCis a “Request for Comments” publication. The RFC series publication began in 1969.
`http://www.rfc-editor.org/RFCoverview.html. The RFCseries 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(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 aboutthe 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. Jd.
`
`The specific process for publication of RFCs as of October 1996 wasset forth in
`18.
`Best Current Practice 9 (BCP 9). That document explains that RFC’s are “published through the
`RFC mechanism.” BCP9 at 7, available at http://tools.ietfiorg/html/bcp9. Accordingto that
`mechanism “Eachdistinct version of an Internet standards-related specification is published as
`part of the ‘Request for Comments’ (RFC) documentseries. This archivalseries is the official
`publication channel for Internet standards documentsand other publications of the IESG, 1AB,
`and Internet community.” Jd. 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.” Jd.
`
`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 ARPANETsites and whomeverelse was interested -- the
`meetings were open -- got together to discuss, design, and documentproposedprotocols
`[RFC0003].” Section 3.1 of RFC 5741 at 3 available at (http://www.rfc-
`editor.org/rfc/rfc5741.txt).’ As further explained, the right column ofeach RFC publication
`contains the nameofthe author andhisor heraffiliation, as well as month and year in whichthat
`the RFC was published and made publicly available. Jd. at 3. The RFC numberis the number
`“assigned by the RFC Editor upon publication of the document.” Jd. at 4.
`
`20.__Asfurther explained by the IETF website “When an RFCis published, an
`announcementis sent to ietf-announceand rfc-dist mailing lists. The canonical URI is of the
`form: http://www.rfc-editor.org/rfc/rfeXXXX.txt.” See http://www.rfc-
`editor.org/pubprocess.html.
`
`The IETF maintainshistorical archives of all RFCs that have been published
`21.
`through its transparent procedures. The month and year of the announcement of each RFC
`correspondsto the publication date reported on each RFC.
`In my experience, announcements
`include a hyperlink to allow viewers of the announcementto jumpdirectly to the RFC document.
`
`Asfurther 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.ietf.org/newcomers.html. Thus, if a topic addressed in an RFC results in a new
`version of that standard, protocolor topic, the new version will be published with a different
`RFC numberand in a documentreflecting the new date ofdistribution of that document.
`
`The IETF’s processis fully transparent and anyonecan join and participate via
`23.
`emaillists (where the bulk of the work is done) free of charge. Individuals working in thefield
`of computer networking in February of 2000 would be very familiar with the RFC publication
`procedures administered by the IETF, and would know that RFCsare indexed, organized by
`subject matter, published in a regular and transparent manner, and distributed via numerous
`pathways. Indeed, an essential feature of the IETF processis thatit is a public and wholly
`transparent process.
`
`Thus, the RFC documentscited in the Request and in the Office action would
`24.
`each have been published during the month and year thatis 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 announcedvia their mailing list during the month and year listed in the heading of
`the RFC, and thus would have been publicly available withoutrestriction as of the date noted on
`the document.
`
`' The top mostleft 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.
`/d. 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 Claimsand Specification of the ’504 Patent
`
`The ’504 claims use the term “domain nameservice system” (DNS systems)to
`25.
`refer to systemsthat are able to establish secure communication links.” This phrase is not used
`in the 504 patent other than in the claims.
`
`The ’504 claimsindicate the DNS systems must be able to (i) store domain names
`26.
`and associated IP addresses of those domain namesand(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 ofthe Internet. The ’504 patent uses the
`term “DNSserver”to refer to this look-up functionality. See, e.g., °504 patentat col.39,11.7-9.
`(“Conventional Domain NameServers (DNSs) provide a look-up function that returns the IP
`address of a requested computeror host.”)
`
`The ’504 patent uses a different term, “DNSproxyserver,”to refer to the
`27.
`functionality in the DNS system that creates a secure communicationslink. See, e.g., "504 patent
`at col.6,Il.11-13 (‘a DNS proxyserverthat transparently creates a virtual private network in
`response to a domain nameinquiry”). The °504 patentalso 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 DNSserver function 2609 and a DNS
`proxy 2610.” °504 patentat col.39, 1.67 —col.40, 1.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 addressof the target node, but instead automatically sets up a virtual private
`network betweenthe target node and the user.” °504 patentat col.39, 11.46-51. Thus, in the 504
`patent andits claims, the conventional lookup functionality (i.e., the “DNS server”) is different
`from functionality that establishes secure communicationlinks (i.e., the “DNS proxy server’)
`and both are different from a “DNS system”whichhasatleast these two functionalities.
`
` Theclaimsalso require the DNS systemsto “comprise an indication that the
`28.
`domain name service system supports establishing a secure communicationlink”(claim 1).°
`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 implementthis functionality.
`
`The waythe ’504 claimsare written does not require the “indication” function to
`29.
`be implemented in the DNS lookupstep(i.e., the “DNS server” function). At a minimum,this
`meansthat the claimed DNSsystems can implementthe required “indication” functionality
`independently from the DNSlookup functionality. This make sense, because a DNS lookup
`function, like an address book, is simply an information resourceservice, ¢.g., it pairs
`information about domain namesand their corresponding IP addresses, and delegates name
`resolution for domain namesfor whichit does not have information to other DNS’s, consistent
`with the description of the DNSfunction in the ’504 patentat col.39,11.7-13. I also note the
`
`Claims 1-35 define DNS systems and claims 36-59 define media including computer executable code used
`to create DNS systems. Claim 60 defines a process with steps corresponding to functionslisted in claims 1 and 36.
`
`The other independent claims (36, 60) indicate that the DNS system must support an indication that the
`3
`DNSsystem supports establishing a secure communication link.
`
`Page 6 of 19
`
`Page 6 of 19
`
`

`

`“supports establishing” a secure
`“indication” required by the claimsis that the “DNS system”
`communication link. Oneof ordinary skill in the art would understand “supports establishing”to
`mean simply “assists” or “facilitates” establishing a secure communication link.
`
`Reexamination Control No. 95/001,788
`Declaration of Michael Allyn Fratto
`99 66
`
`The ’504 patent claimsalso do not require the DNS systems to implementall of
`30.
`the functionalities listed in the claims on a single computer or within a single process. Instead,
`the ’504 patent makesit 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 ’504 patentstates at col.40,11.44-48, that “It will be appreciated that
`the functions of DNS proxy 2610 and DNSserver 2609 can be combinedinto a single server for
`convenience. Moreover, although element 2602 is shown as combiningthe functions of two
`servers, the two servers can be madeto operate independently.” (Emphasis added.) Thus, a
`DNSsystem 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.
`
`Inote that Dr. Keromytisstates in J 16 of his Declaration that in one embodiment
`31.
`the “DNSserver”itself “supports the establishment of a secure communication link” andthatit
`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 DNSserver in Figure 26, which includes a conventional DNS server
`function (item 2609) and separate functionalities that handle establishing secure communication
`links, whichis 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 DNSserveralone.
`
`[also note that Dr. Keromytis’ description is not consistent with the claim
`32.
`language which does not require 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
`’504 specification. For example, nothing in the claims require “trapping” or returning non-true
`IP addressesof the target node or of “automatically” setting up anything.
`
`IT also disagree with several of Dr. Keromytis’ statements implying that the °504
`33.
`claims require lookup functions to be performeddifferently than how these lookupsare done by
`conventional DNS servers. First, the claims do not makethis distinction — they either simply
`require the systems store domain namesandassociated IP addresses(e.g., claims 1, 36 and 60) or
`to perform conventional DNS lookups(e.g., claim 15, which states “the domain nameservice
`system is configured to provide, in response to the query, the network address corresponding to a
`domain namefrom the plurality of domain namesandthe corresponding network addresses”).
`See also, e.g., claims 20, 21 (the DNS system “comprises a domain namedatabase, and wherein
`the domain namedatabasestores the plurality of domain namesand the corresponding network
`
`addresses”). Second, the ’504 description that Dr. Keromytis points to in [J 17-19 of his
`Declaration makesclear that conventional DNS server functionis 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 DNSproxy (2610) elements).
`
`Page 7 of 19
`
`Page 7 of 19
`
`

`

`Reexamination Control No. 95/001,788
`Declaration of Michael Allyn Fratto
`
`Vv.
`
`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 environmentsin which they are to be deployed.
`In particular, Dr. Keromytis does not acknowledgein 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.
`
`35.|Solana describes a Collaborative Domainssecurity architecture that can be used
`to handle “a generic Internet transaction (such asa WWW query...) taking place between two
`principals,... initiators (...the WWW client...) and responders(...the WWW server...).”
`Solana at 42. WWW queries typically contain domain namesthat require resolution into IP
`addresses for the query to be acted upon. To be able to handle WWW queriesas it states it does,
`the Solana systems must be able to resolve domain namesinto IP addresses. A person familiar
`with Internet communication standards would recognize that this meansthat the Solana systems
`must perform DNS lookup functions.
`
`Solana also explainsthat its systems are designed to work within existing domain
`36.
`structuresat 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 So/ana systems, they “concentrate exclusively on the impact
`that the domain collaboration might have in the provision offlexible and manageable
`mechanismsto secure Internet transactions.”). Thus, conventional domain nameresolution
`processing does occurs.
`
`Solana describes an architecture that readily accommodatesthis 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 andretrieval of“certificates
`that bind domainsto their public keys” which is necessary to enable the secure inter-domain
`communications per the Solana scheme. DNS-secrefers 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 DNSservers
`that conventionally respond to domain-to-IP translation queries. Thus, by indicating that the
`“naming information”is stored in a DNS-sec-based naminginfrastructure, Solana necessarily is
`indicating that (i) the DS depicted in Fig. 1 of Solana includes DNSservers that incorporate
`DNS-sec security extensions, and (ii) the “naming information”stored in the DS must include
`both domain namesand corresponding IP addresses, as both are used by these DNSservers.
`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 Solanaare indicating.
`
`Solana also necessarily incorporates DNSserver functionality based on the design
`38.
`of the DNSsystems shown in Figure 1. Specifically, Solana showsan 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
`
`/d. at 43-44. Solana
`authenticated channel to a “Domain Border System” (DBS) element.
`explains that the DBS “‘is the active player in the domain collaboration...” /d. at 43. As shown in
`Figure 1, the DBS receives the communication (e.g., a WWW query), and acts in responsetoit
`(e.g., by performing authentication, interacting with the LAD, DS, DAK andestablishing
`authenticated or encrypted sessions betweenthe principals). In this role, the DBS necessarily
`will perform DNS lookups using DNSservers(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 DNSservers) to resolve domain namesinto IP
`addresses — whether in the DSorin 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 425 ofhis Declaration, Dr. Keromytis states that “Solana explainsthat the
`39.
`‘naming information’is stored in the DS in theform of UNIs, which mayinclude “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 UNIis “neededto
`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-onerelationship
`to the public key ofthe 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.
`Keromytisis asserting, Solanais not saying that “naming information”is published in the DS in
`the form of a UNI as Dr. Keromytisstates, and certainly not only in the form of an IP address.
`Instead, Solana explains that while UNI information may be publishedin the DS,“naming
`information”(including optional IP addresses) is stored in the DS using “existing naming
`infrastructures (DNS-sec, x.509)....” Jd.
`
`Dr. Keromytis’ explanationsat J 23-27 of his Declaration make no sense given
`42.
`howthe Solana systems must function. Solana explainsthat its systems establish domain-to-
`domainrelationships 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. at42. The Solana DNSsystemsdothis by publishing “naming information”in a
`Directory Service (DS)linking particular domainsto certificates that securely bind domainsto
`their public keys.
`/d. at 43. Other domains can accessthis 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 namewill be published as part of the “naming information”in the DS.
`
`
`This also makes sense because a domain nameis a single, fixed identifier for a
`43.
`domainthat 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 name in the DS enables other domainsto reliably and efficiently locate the keys
`neededto set up inter-domain relationships. By contrast, publishing only IP addresses in the DS
`as Dr. Keromytis suggests would beillogical. First, many different IP addresses can be
`associated with a single domain, and these associations may changeor 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 LADis not always published in the DS. If Dr.
`Keromytis werecorrect (i.e., that a UNI only can contain an IP addressandis the only thing
`published in the DS), situations would arise where no “naming information” would be published.
`This would makediscovery of the public keys needed for the Solana system to work impossible
`(e.g., requesting a certificate by searching for an “unpublished” IP address wouldfail because
`that information would not be in the DS). Third, publishing IP addressesin the DSto identify
`certificates binding public keys to domains could compromisethe security of the Solana system
`(e.g., by exposing IP addressesofprincipals). Finally, nothing in Solana says that “naming
`information” published in the DS cannot include a domain nameandan associated IP address.
`
`Solana also indicates its system communicates in conformance with the TCP/IP
`44.
`protocol. See Solana at 2-3, 42 n.2. The Domain Name System—as definedin, for example,
`RFCs 1034 and 1035—-was designed to address the growth ofthe Internet by providing reliable
`methods for routing IP packets under the TCP/IP protocolto their proper destination. See RFC
`1180 at 21. The concept of the domain name system 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 nameofinterest,” and such “queries for address
`resources”are answeredbythe “return [of] Internet host addresses.” RFC 1034 at 5. The broad
`applicability of the DNSis utilized by the Solana system in order to support nameresolution for
`its disclosed WWWtransactions. Thus, the WWW queries being handled in the Solana scheme
`necessarily include domain names, and the return of such queries necessarily includes IP
`addresses. This also indicates that the “naming information” published within the DS of Solana
`includes both domain namesand corresponding IP addresses.
`I note that in {J 21-22 of his
`Declaration, Dr. Keromytis discusses the mechanisms by which secure channels are established
`in the Solana scheme. These procedures are analogous to the DNSproxy function discussed in
`the ‘504 patent. They are not relevant to the handling of “generic” WWWtransactions and do
`
`not suggest that the Solana systems cannot include DNSserverfunctionality to resolve domain
`namesinto IP addresses.
`
`I do not agree with Dr. Keromytis’ conclusion in paragraph 30 that the Solana
`45.
`systemsare not a DNSsystem “configured to receive a query for a network address.” An
`integral function of the Solana systemsis the ability to receive and act on “generic” Internet
`transactions, such as WWW queries. As shown in Figure 1, an initiator sends a WWW query to
`the DBS. WWWqueries, because they are “generic Internet” transactions, will be sent via
`TCP/IP and usually will contain a domain name,rather than an IP address. To act on these
`WWW aueries, the DBS mustbe able to perform or have performed a DNSlookupto obtain an
`IP address whichis then used to set up secure communications with the responder’s domain.
`In
`addition, the domain nameis used to retrieve the appropriate keys from the LAD or DS. For
`example,to retrieve the public key for a domain, the DBSwill use the domain nameto query the
`DS which stores domain namesas part of the “naming information” according to the DNS-sec
`
`Page 10 of 19
`
`10
`
`Page 10 of 19
`
`

`