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

`

`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 meto
`understand the technologies and standardsrelated to that problem set, and to create a set of
`comparative measures by which to assess the product, its performance andits functionality.
`WhenI 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
`8.
`I understand that the Patent Owneris challenging that the Solana and Reed papers
`were publicly distributed.
`I have been told 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.
`9.
`From my personal experiences, I am aware that research topics developed by
`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 and his or
`her research for review by the conference representatives, often well before the conference was
`held. The conference organizers select only someofthese papers for presentation at the
`conference. The papers selected for presentation are usually distributed before, but nolater than
`during the conference, which allowsattendees to read them anddiscuss their findings with the
`presenting researcher. The presented papersare 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.
`10.
`Solana is a printed publication that was publicly distributed and published via this
`conventional process. In particular, Solana waspublicly 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 paperin its
`Bibliography as follows:
`[119] Solana, E. and Harms,J. Flexible Internet Secure Transactions Based on
`Collaborative Domains. Proceedings of the Sth Security Protocols International
`Workshop.Paris 7th - 9th April 1997. Springer-Verlag Lecture notes in computerscience;
`Vol. 1361.
`
`As the Springer-Verlag website (www.springer.com) explains, the LNCSseries
`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
`
`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 prestigiousinstitutes and
`learned societies. Our missionis to serve this community by providing a most valuable
`publication service.” Accordingto the publisher’s website, the book in which Solana was
`published “constitutes the strictly refereed post-workshop proceedings of the Sth 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 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 211 is to be evaluated. See Exhibit C.
`
`Reed is a printed publication that was distributed as part of the published
`12.
`proceedingsof the 12"" Annual Computer Security Applications Conferencethat occurred in
`1996. The Association of Computing Machinery (ACM) website lists the publication date of
`Reed as follows:
`
`Proxies For Anonymous Routing
`
`“>. wee | 1996 Article
`Authors: MG.Reed
`
`PLE.Syverson
`
`D.M.Goldschiag
`
`tableofcontents ISBN :0-8186-7606-X
`
`Published in:
`» Proceeding
`ACSAC '96 Proceedings of the 12th Annual Computer Security Applications
`Conference
`Page 95
`IEEE Computer Society Washington, DC, USA ©1986
`
`we eter
`—+ Sibliometrics
`» Downloads (6 Weeks): 0
`* Downloads (12 Months): 0
`+ Citation Count: 22
`
`13._As its citation indicates, the Reed publication was publicly distributed during the
`12th Annual Computer Security Applications Conference held in 1996, a fact that is noted on
`page | of the publication. The IEEE website confirmsthat the 12" Annual ComputerSecurity
`Applications Conference was held between December 9-13, 1996. The ACSACwebsitealso
`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 describethelatest in
`implementations and applications-oriented research.” See id.
`14.
`Reed also wasdistributed to the public in 1996 aspart of a formally published
`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://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 Jd.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.
`15.
`Thus, the Reed printed publication was published and publically available as of the
`conference date and at least by December 31, 1996 when the ACSAC ’96 Proceedingstreaties
`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
`16.
`On pages 8-9, of the Response, the Patent Owner contendsthat there is no
`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.
`I disagree.
`17.
`The Internet Engineering Task Force (IETF)is responsible for the standardization
`process and governanceofInternet protocols and processes. The IETF uses several 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 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 (Internet Research Task Force). http://www.trfc-
`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.
`/d.
`18.
`The specific process for publication of RFCs as of October 1996 wasset forth in
`Best Current Practice 9 (BCP 9). That document explains that RFC’s are “published through the
`RFC mechanism.” BCP9 at7, available at http://tools.ietf.org/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 documents and other publications of the IESG, IAB,
`and Internet community.” /d. 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.
`19.|The IETF website also explains that “Historically, all RFCs were labeled Network
`Working Group. ‘Network Working Group’ refers to the original version of today’s IETF when
`people from the original set of ARPANETsites and whomeverelse wasinterested -- 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/rfe/rfe5741 txt)! As further
`
`' 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 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 nameof the author andhis or
`her affiliation, as well as month and year in which that 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.” /d. at 4.
`
`Asfurther explained by the IETF website “When an RFCis published, an
`20.
`announcementis sent to ietf-announceandrfc-dist mailing lists. The canonical URIis of the
`form: http://www.rfc-editor.org/rfe/rficXXXXtxt.” 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 announcementof each RFC
`correspondsto the publication date reported on each RFC.
`In my experience, announcements
`include a hyperlink to allow viewers of the announcementto 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.ietf.org/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 documentreflecting 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 workingin 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 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 that it is a public and wholly
`transparent process.
`
`Thus, the RFC documentscited 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 announcedvia their mailing list during the month and yearlisted 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 211 claims use the term “domain nameservice system” (DNS systems) to
`26.
`refer to systemsthat are able to establish secure communication links. This phrase is not used in
`the 211 patent other than in the claims.
`
`The 211 claims indicate the DNS systems must be able to (i) store domain names
`27.
`and associated IP addresses of those domain namesand(ii) receive domain name queries for
`network addresses. These two functions together constitute the well-known DNSlookup
`functionality that is integral to the domain namesystem of the Internet. The 211 patent uses the
`term “DNSserver”to refer to this look-up functionality. See, e.g, 211 patentat col.38,11.57-60.
`(“Conventional Domain NameServers (DNSs) provide a look-up function that returns the IP
`address of a requested computerorhost.”’)
`28.
`The 211 patent uses a different term, “DNSproxy server,” to refer to the
`functionality in the DNS system that creates a secure communicationslink. See, e.g., 211 patent
`at col.6,11.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 211 patentstates
`“a modified DNS server 2602 includes a conventional DNS server function 2609 and 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 211] patent and
`its 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” whichhasat least these two functionalities.
`29.
`The claimsalso require the DNS systemsto “indicate in response to the query [for
`a network address] that the domain nameservice 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 implementthis functionality.
`30.
`The way the 211 claims are written does not require the “indicate” function to be
`implemented in the DNS lookupstep(i.e., the “DNS server” function). This make sense, because
`a DNSlookup function,like an address book, is simply an information resourceservice, e.g., it
`pairs information about domain namesand their corresponding IP addresses, and delegates name
`resolution for domain namesfor 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, 11.58-64. I also note the
`“indicat[ion]” required by the claimsis 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 communicationlink.
`31.
`The 211 patent claims also do not require the DNS systems to implementall of the
`functionalities listed in the claims on a single computer or within a single process. Instead, the
`211 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 211 patent states at col.40,11.27-31, 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 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 independently.” (emphasis added). Thus, a DNS
`system accordingto 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 asthey, 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.
`32.
`[note that Dr. Keromytisstates in §16 of his Declaration that in one embodiment
`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 211 patent is describing. Specifically, his comments are describing the
`features of a modified DNSserverin Figure 26, which includes a conventional DNSserver
`function (item 2609) and separate functionalities that handle establishing secure communication
`links, which is referred to as the DNS proxy function (item 2610). As] explain above, the
`“modified DNS server” corresponds to a “DNSsystem”in the claims, not the DNSserver alone.
`33.
`T also note that Dr. Keromytis’ description is not consistent with the claim
`language which doesnot require the DNSserver 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.
`34.
`also disagree with several of Dr. Keromytis’ statements implying that the 211
`claims require lookup functionsto be performed differently than how these lookups are done by
`conventional DNSservers. First, the claims do not makethis distinction — they either require the
`systems store domain namesandassociated IP addresses(e¢.g., claims 1, 36 and 60) or 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
`
`name from the plurality of domain namesand the corresponding network addresses”). Second,
`the 211 description that Dr. Keromytis points to in §§17-19 of his Declaration makesclear that
`conventional DNSserverfunctionis distinct from the elements of the DNS system that establish
`the secure communication link. See, e.g., 211 at col.39, 119-31 (explaining that DNS systems
`(2062) in Figure 26 contain distinct DNS server (2609) and a DNSproxy (2610) elements).
`
`Vv.
`
`Solana
`
`Dr. Keromytis acknowledges that Solana describes a domain-based security
`35.
`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 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.
`
`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 WWWclient...) 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 queriesasit states it does, the Solana
`systems mustbe able to resolve domain namesinto IP addresses. A person familiar with Internet
`
`Page 7 of 19
`
`Page 7 of 19
`
`

`

`Reexamination Control No. 95/001,789
`Declaration of Michael Allyn Fratto
`
`communication standards would recognizethat this meansthat the Solana systems must perform
`DNSlookup functions.
`37.
`Solana also explains that its systems are designed to work within existing domain
`structures at the IP level (e.g., the public Internet structure). Solana at 40-41 (“[W]Je assumethat
`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 alsoid.
`(indicating that in designing the Solana systems, they “concentrate exclusively on the impact that
`the domain collaboration might havein the provision offlexible and manageable mechanismsto
`secure Internet transactions.”). Thus, conventional domain nameresolution processing occurs.
`38.
`Solana describesan architecture that readily accommodatesthis required DNS
`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
`communicationsper 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 DNSservers
`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
`indicatingthat (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 mustinclude
`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 | on page 43 of Solanaare indicating.
`39.
`Solana also necessarily incorporates DNSserver functionality based on the design
`of the DNS systems shownin Figure 1. Specifically, Solana showsan 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.
`/d. at 43-44. Solana
`explains that the DBS “is the active player in the domain collaboration...” Jd. at 43. As shownin
`Figure 1, the DBS receives the communication (e.g., a WWW query), andacts in responsetoit
`(e.g., by performing authentication, interacting with the LAD, DS, DAK andestablishing
`authenticated or encrypted sessions between the principals). In this role, the DBS necessarily will
`perform DNSlookups 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 DNS servers) to resolve domain namesinto IP
`addresses -- whether in the DS orin other operational elements of the Solana system, such asthe
`Domain Border System (DBS). See, e.g., Solana at 43-44 and Figure 1.
`40.
`In { 25 of his Declaration, Dr. Keromytis states that “Solana explains that the
`‘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 UNIis “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 /d. (Fig. 1).
`42.
`Solana also explains that UNI information (e.g., the network address of a
`principal) may optionally be “published in the Directory Service.” Thus, contrary to what Dr.
`Keromytis is asserting, Solana is not 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)....” Jd.
`43.
`Dr. Keromytis’ explanationsat §J 23-27 of his Declaration make no sense given
`how the Solana systems must function. Solana explains thatits systems establish domain-to-
`domainrelationshipsto 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 DNSsystemsdo this 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 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 namewill be published as part of the “naming information”in the DS.
`44,
`This also makes sense because a domain name isa single, fixed identifier for a
`domainthatis used to navigate to the domain via the Internet domain name system. Publishing
`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 be illogical. 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 includedin “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 UNIin the LADis not always published in the DS. If Dr.
`Keromytis werecorrect (i.e., that a UNI only can contain an IP address andis the only thing
`published in the DS), situations would arise where no “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 addressesofprincipals). Finally, nothing in Solana says that “naming
`information” published in the DS cannot include a domain nameandan associated IP address.
`45.
`Solana also indicates its system communicates in conformance with the TCP/IP
`protocol. Solana at 2-3, 42 n.2. The Domain Name System—asdefined in, for example, RFCs
`1034 and 1035—was designed to address the growth of the Internet by providingreliable
`methodsfor routing IP packets under the TCP/IP protocol to their proper destination. RFC //80
`
`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 wasthus devised “to provide a mechanism for naming resources”that
`has broad applicability across “different hosts, networks, protocol families, internets, and
`administrative organizations.” RFC /035 at2. As explained in RFC /034,a WWW “query
`names the domain nameofinterest,” and such “queries for address resources” are answered by
`the “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 forits disclosed WWW
`transactions. Thus, the WWW queries being handled in the So/ana schemenecessarily 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
`names and corresponding IP addresses.
`I note that in Jf 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 211] patent. They are not
`relevant to the handling of “generic” WWWtransactions and do not suggest that the Solana
`
`systems cannot include DNSserver functionality to resolve domain namesinto IP addresses.
`46.
`I do not agree with Dr. Keromytis’ conclusions in
`28-34 that the Solana systems
`are not a DNS system “configured and arranged to receive the query for a network address.” An
`integral function of the So/ana systemsis the ability to receive and act on “generic” Internet
`transactions, such as WWW queries. As shownin Figure 1, an initiator sends a WWW query to
`the DBS. WWW queries, because they are “generic Internet” transactions, will be sent via
`TCP/IP and usually contain a domain name,rather than an IP address. To act on these, the DBS
`must be able to perform a DNS lookupto obtain an IP address whichis then used to set up secure
`communications with the responder’s domain.
`In addition, the domain nameis usedto retrieve
`the appropriate keys from the LAD or DS. For example,to retrieve the public key for a domain,
`the DBS will use the domain name to query the DS which stores domain namesaspart of the
`“naming information” according to the DNS-sec naminginfrastructure I discuss aboveat J 37.
`Indeed, as section 2.2 of the DNS-Sec protocol (RFC 2065) explains, “security aware DNS
`servers will automatically attempt to return KEY resources as additional information, along with
`those resource records actually requested, to minimize the numberof queries needed.” I also
`disagree with Dr. Keromytis’ statements at J] 35-37 that Solana doesnot “indicate in response to
`the query [for a network address]” whether the domain nameservice system supportsestablishing
`a secure communication link. As I discuss immediately above, this argument ignores that Solana
`teaches that requests can be WWW queries, and that an IP address provided in response to
`resolution of a WWW query will be used prior to retrieving keys necessary to set up
`authenticated and encrypted inter-domain communications.
`47.
`[also disagree with Dr. Keromytis’ characterization at Jf 31-33 of his Declaration
`regarding what is being shown in Figure 2a. Fig. 2a is showing what happensafter the original
`WWW querysent bytheinitiator has been received and acted upon by the DBS. This is evident
`because the IP address of the responde