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
`
`)
`)
`)
`)
`)
`)
`)
`)
`
`
`COMMENTS BY THIRD PARTY REQUESTER PURSUANT TO 37 C.F.R. § 1.947
`
`
`Control No.: 95/001,788
`Group Art Unit: 3992
`Examiner: Roland Foster
`Confirmation No.: 5823
`
`
`Mail Stop Inter Partes Reexam
`Commissioner for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`Sir:
`On March 29, 20102, Patent Owner filed an overlength response (“Response”) to the
`
`December 29, 2012 Office action (“Office Action”) and a petition under 37 C.F.R. § 1.183
`seeking waiver of the page limit for that response. On May 25, 2012, the Examiner granted
`Patent Owner’s petition, and set the date for a response by the Requestor for 30 days from the
`date of decision, which fell on Sunday June 24, 2012. This response is timely filed on the next
`business day. 35 U.S.C. § 21. Third Party Requester believes that no fee is due in connection
`with the present response. However, any fee required for entry or consideration of this paper
`may be debited from Deposit Account No. 18-1260.
`
`I.
`
`Introduction
`For reasons set forth in detail below, Requestor urges the Examiner to maintain the
`rejections of claims 1-60 set forth in the Office Action. Provided herewith is Declaration of
`Michael Allyn Fratto under 37 C.F.R. § 1.132 (“Fratto”). Pages 1-6 of that declaration response
`to contentions of the Patent Owner regarding the status of Solana, Reed, and several RFC
`publications. Requester submits those pages do not count against the 50-page limit for Response
`under 37 C.F.R § 1.943(b), pursuant to MPEP §2667.
`
`
`
`Petitioner Apple - Ex. 1067, p. 1
`
`

`
`Control No. 95/001,788
`Comments of the Requestor on the Patent Owner Response
`II.
`Response to Patent Owner Contentions on Status of References as Prior Art.
`On pages 5-9 of the Response, Patent Owner argues that there is “no evidence” that the
`
`Solana, Reed, and “RFCs” are prior art under 35 U.S.C. § 102(a) or (b). The Patent Owner’s
`claims border on the frivolous – each of the contested references is unquestionably a printed
`publication, and only by a studied ignorance of the facts can Patent Owner assert otherwise.
`
`Patent Owner grossly misstates Requestor’s burden to establish that the cited publications
`were publicly disseminated. According to Patent Owner, Requestor was required to provide “a
`showing” with “evidence proving” the date each reference was made publically available.
`Response at 6 (citing 37 C.F.R. §11.18). This is plainly incorrect – all that is required is that
`Requester represent that the reference was published. In fact, 37 C.F.R. § 11.18 (the regulation
`patent owner cites) states precisely this – it provides that the submission of a paper by a party is a
`certification that “[t]o the best of the party’s knowledge, information and belief, formed after an
`inquiry reasonable under the circumstances… [t]he allegations and other factual contentions
`have evidentiary support or, if specifically so identified, are likely to have evidentiary support
`after a reasonable opportunity for further investigation or discovery.” 37 CFR 11.18(b)(2)(iii).
`Moreover, In re Wyer, 655 F.2d 221 (C.C.P.A. 1980) (cited by the Patent Owner) did not hold a
`party had to preemptively present evidence to prove public availability. To the contrary, it held
`only that “sufficient proof” as to the publication date must exist. Id. at 226-27. Thus, no
`authority supports Patent Owner’s contention that Requestor was required to present independent
`evidence with its request proving the date of public availability of each reference.
`Regardless, each of Solana, Reed and the RFC documents was publicly disseminated
`
`more than a year before February 15, 2000.1 A reference is publicly accessible if it was
`“disseminated or otherwise made available to the extent that persons interested and ordinarily
`skilled in the subject matter or art exercising reasonable diligence can locate it.” Kyocera
`Wireless Corp. v. Int'l Trade Comm’'n, 545 F.3d 1340, 1350 (2008) (internal quotation marks
`omitted). Each of Solana and Reed was formally published as part of a compilation of technical
`papers originally presented to conferences of experts in network and security techniques. Each
`paper on its face states this, and provides the dates of each conference. Each paper, thus, was
`made publicly available to the relevant public more than year before the effective filing date of
`
`
`1
`The Patent Owner did not contest Requester’s assertions that the effective filing date of
`the ’504 patent is no earlier than February 15, 2000, as set forth on page 10 of the Request.
`
`2
`
`
`Petitioner Apple - Ex. 1067, p. 2
`
`

`
`Control No. 95/001,788
`Comments of the Requestor on the Patent Owner Response
`the ‘504 patent. See e.g., In re Bayer, 568 F.2d 1357, 1361 (C.C. P.A.1978). Patent Owner does
`not seriously contest these facts. Instead, Patent Owner simply contends Requester did not
`present additional evidence with the Request proving that these statements were true. Requester
`had no such burden. Nonetheless, to remove any doubt, Requester presents additional evidence
`in the Declaration of Michael Fratto (“Fratto ”) which conclusively establishes that each of
`Solana and Reed was formally published and distributed years before February 15, 2000.
`Solana was published in a treatise called “Lecture Notes in Computer Science” (LCNS)
`
`by Springer-Verlag in 1998.2 Fratto at ¶9-10. The introduction to this treatise dated in
`December of 1997 indicates that Solana was first presented to the relevant public at a conference
`on networking in April of 1997. Id. at ¶11. As described, LCNS presents “the strictly refereed
`post-workshop proceedings of the 5th International Workshop on Security Protocols, held in
`Paris, France, in April 1997.” Id. at ¶10. Consequently, Solana is a printed publication that was
`made publicly available in 1997, and was formally published no later than 1998.
`Reed indicates that it was first distributed to the public at the 12th Annual Computer
`
`Security Applications Conference in December 1996. As Mr. Fratto explains, under the ACSA
`procedures, Reed would have been made publically available no later than the start date of the
`conference. Fratto at ¶12-13. Mr. Fratto also provides evidence showing the date and time that
`the Reed paper was presented at this conference. Additionally, Mr. Fratto provide evidences
`from the Association of Computing Machinery (ACM) website reporting the citation of the Reed
`paper, demonstrating its public availability. Thus, Reed is a printed publication that was made
`publicly available no later than December of 1996.
`
`Next, Patent Owner challenges the status of several Request for Comment (RFC)
`documents cited in the Request, claiming that “the record is devoid of evidence that any of these
`references are … printed publications as of” each publication date listed on each RFC. This is a
`frivolous challenge. As anyone working in the field of network communications would know,
`RFC documents are published and disseminated to the relevant public by the Internet
`Engineering Task Force (IETF) pursuant to a transparent and well-known process. Under these
`well-known procedures, RFCs are self-authenticating printed publications – each contains
`
`
`2
`Requester notes that the IDS submitted with the Request incorrectly lists the publication
`date of the LCNS treatise as “1997” – the actual publication date was 1998. This distinction has
`no consequence – Solana remains prior art under 35 U.S.C. § 102(b).
`
`3
`
`
`Petitioner Apple - Ex. 1067, p. 3
`
`

`
`Control No. 95/001,788
`Comments of the Requestor on the Patent Owner Response
`verifiable information documenting the date of its public distribution. Specifically: (i) each
`number assigned to an RFC is unique and is not “re-used” if the subject matter in an RFC is
`revised or updated, (ii) the date each RFC is distributed to the public is listed the front page of
`the RFC, (iii) RFCs are distributed to the public over the Internet, via numerous protocols, (iv)
`each RFC is announced via an email distribution list on the date it is released to the public, and
`(v) RFCs are maintained in numerous archives publicly accessible via the Internet. Id. at ¶18-
`22. Indeed, Patent Owner cites several RFCs as publications in the ‘504 disclosure. Given this,
`it is remarkable that Patent Owner can even suggest that RFCs are not publicly disseminated.3
`The evidence, thus, overwhelmingly establishes that Solana, Reed and the various RFCs are
`printed publications applicable as prior art to the ’504 patent claims.
`
`III. The Rejections Of the Claims Were Proper And Should Be Maintained
`A.
`Claim Interpretation
`Claims are given “their broadest reasonable interpretation, consistent with the
`
`specification, in reexamination proceedings.” In re Trans Texas Holding Corp., 498 F.3d 1290,
`1298 (Fed. Cir. 2007). In determining that meaning “it is improper to ‘confin[e] the claims to
`th[e] embodiments’ found in the specification.” Id. at 1299 (quoting Phillips v. AWH Corp., 415
`F.3d 1303, 1323 (Fed. Cir. 2005) (en banc)). While “the specification [should be used] to
`interpret the meaning of a claim,” the PTO cannot “import[] limitations from the specification
`into the claim.” Id. “A patentee may act as its own lexicographer and assign to a term a unique
`definition that is different from its ordinary and customary meaning; however, a patentee must
`clearly express that intent in the written description.” Helmsderfer v. Bobrick Washroom Equip.,
`Inc., 527 F.3d 1379, 1381 (Fed. Cir. 2008) (emphasis added). No such definitions of key claim
`terms is provided in the ’504 patent (i.e., “domain service system”, “secure communication link”,
`“indication”, “supports”, or “supporting”, “connectable” or “enables”).4 Thus, these terms must
`be given their broadest reasonable interpretation in these reexamination proceedings.
`
`
`3
`See, e.g., ’504 patent at page 3 (citing RFCs 2401 and 2543 as “publications”).
`4
`At trial, Patent Owner argued that a “DNS proxy server” is simply “a computer or
`program that responds to a domain name inquiry in place of a DNS.” Ex. A, Markman at 19-20.
`Patent Owner also argued that the phrase “Domain Name Service System” did not need a
`construction but if it did, it was just “a computer system that includes a domain name service
`(DNS).” Id. Patent Owner also asserted the claimed DNS systems did not have to be able to
`
`4
`
`
`Petitioner Apple - Ex. 1067, p. 4
`
`

`
`B.
`
`Control No. 95/001,788
`Comments of the Requestor on the Patent Owner Response
`Response to Patent Owner’s Arguments Regarding the Rejection of Claims
`1-2, 5-6, 8-9, and 14-60 Under 35 U.S.C. § 102(b) based on Solana (Ground
`Nos. 1, 5, 9, 13, 17, 21, 25, 30)
`1.
`Solana Describes the Claimed DNS Systems
`As explained in the Request, Solana describes domain name service systems (“DNS
`
`systems”) that establish secure communication links between an initiator (the source domain)
`and a responder (the destination domain). See Request at 39- 46; see also Declaration of
`Angelos D. Keromytis (“Keromytis”) at ¶ 20-21. Solana also describes that its DNS systems are
`connected to a communication network, store a plurality of domain names and corresponding
`network addresses, receive queries for a network address and comprises an indication that it (i.e.,
`the “domain name service system”) supports establishing secure communication links.
`Consequently, the Office properly found that Solana describes “DNS systems” that anticipate
`independent claims 1, 36 and 60. In response, Patent Owner asserts Solana does not teach DNS
`systems that: (1) “store domain names and corresponding network addresses”; 5 (2) “receive a
`query for network address” or (3) “comprise an indication that the domain name service system
`supports establishing a secure communication link.” Each of these is incorrect.
`a.
`Solana Describes DNS Systems that Store a Plurality of
`Domain Names and Corresponding Network Addresses and
`That Receive Requests for a Network Address
`
`The Office correctly found that Solana discloses both “a domain name service system
`
`configured to . . . store a plurality of domain names and corresponding network addresses” and
`that the system receives requests for a network address. As explained in the Request (see, e.g.,
`Request at 39- 46), Solana describes DNS systems that create domain-to-domain relationships to
`enable principals in different Internet domains to more efficiently and securely conduct “generic”
`Internet transactions. One of the elements of this scheme is the “Directory Service” (DS), which
`Solana explains publishes “naming information” and certificates that “securely bind domains to
`their public keys.” See Solana at 43 (Fig. 1). This published “naming information” is used to
`retrieve public keys associated with and establish secure links between the domains. Logically,
`
`distinguish between secure and unsecure sites. See Id. Patent Owner’s arguments at trial should
`be considered in determining the broadest reasonable construction of the claims.
`5
`The independent claims do not require the DNS system to actually resolve a domain
`name into an IP address – that is an additional step specified in dependent claims (e.g., claim 15).
`Thus, the independent claims only require DNS systems that, inter alia, store domain names and
`corresponding IP addresses.
`
`
`
`5
`
`Petitioner Apple - Ex. 1067, p. 5
`
`

`
`Control No. 95/001,788
`Comments of the Requestor on the Patent Owner Response
`the “naming information” published in the DS must contain at least the domain name of each of
`the domains being managed in this way. Fratto at ¶ 37-45. Solana also explains that the
`“naming information” may optionally include IP addresses associated with principals in a
`domain. See Solana at 43 (explaining that “information [i.e., a UNI consisting of a network
`address] may also be published in the Directory Service.”)6 Thus, Solana describes a DNS
`system comprising a DS that “stores domain names and corresponding network addresses.”
`In response, Patent Owner first argues (incorrectly) that “Solana does not disclose that
`the DS stores a plurality of domain names and corresponding network addresses” and instead
`“merely discloses that the DS stores ‘naming information and … certificates that securely bind
`domains to their public keys.’” Response at 12. This is incorrect, and to assert otherwise, Patent
`Owner and its expert must misrepresent or ignore key teachings of Solana. For example, Dr.
`Keromytis incorrectly 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.” Keromytis at ¶25. This is incorrect –Solana nowhere states that “naming information”
`is stored in the DS in the form of UNIs.7 Instead, Solana states that “naming information” may
`stored in the DS according to “existing naming infrastructures (DNS-sec, X.509)…” (emphasis
`added). To store the “naming information” in a DNS-sec compliant naming infrastructure
`requires the DS to include a DNS server that has incorporated DNS-sec security extensions
`termed “Key Resource Records.”8 Fratto at ¶ 45. Thus, Solana, by stating that “naming
`information” is stored in a DNS-sec compliant infrastructure in the DS, it is indicating that the
`DS necessarily includes a DNS server that maintains domain names and corresponding IP
`addresses and performs DNS name resolution (i.e., the functions of a DNS server). Fratto at ¶
`37-38. Indeed, this is why the DS is depicted as consisting of the multiple servers in Fig. 1 of
`Solana. Thus, the central premise of the Patent Owner’s response – that “naming information”
`
`
`6
`Dr. Keromytis contends the UNI holds only one data element – a common name, an
`email address or a network address – that is uniquely associated with a principal or the domain.
`See Keromytis at ¶ 25.
`7
`Solana explains that data in the UNI alone (i.e., as a single IP address) is stored in
`another location - the Local Authentication Database (LAD), where it is associated in tables in a
`1:1 relationship with the public keys of the principals that the UNIs “globally and unequivocally”
`identify. See Solana at 43.
`8
`This is also consistent with the representation of the DS in Fig. 1 of Solana (p.43) as
`comprising multiple servers.
`
`
`
`6
`
`Petitioner Apple - Ex. 1067, p. 6
`
`

`
`Control No. 95/001,788
`Comments of the Requestor on the Patent Owner Response
`published in the DS only contains a “UNI” (i.e., only an IP address) and the public certificate of
`a domain – is simply false. Fratto at ¶ 39-42.
`Patent Owner’s incorrect reading of Solana is also illogical given the role that “naming
`
`information” plays in the Solana DNS systems. Specifically, Solana shows that “naming
`information” is published in the DS to enable retrieval of public keys associated with secure
`domains needed to establish “domain-to-domain” relationships that are at the heart of the Solana
`scheme. This is done by querying the DS using “naming information” associated with a secure
`domain that allows retrieval of a certificate binding the public key to that domain. Fratto at ¶ 37-
`45. Under Patent Owner’s logic, the only “naming information” that is published in the DS will
`be a “UNI” (i.e., an IP address) but not a domain name. Keromytis at ¶ 25. Yet, as Solana
`clearly states, publishing “network addresses” in the DS is optional – which means that
`frequently the DS will have no “naming information” associated with a domain certificate.
`Solana at 43. Patent Owner’s tortured reading of Solana cannot possibly be correct for at least
`the reason that if “naming information” in DS contain no information that can be used to find the
`public keys of a secure domain, the Solana scheme would be rendered inoperative. Moreover, IP
`addresses, unlike domain names, frequently change, which would require a constant updating of
`the correlations between IP addresses and the public keys of domains, thus calling into question
`the accuracy of the data in the DS. By contrast, a DNS server within the DS can maintain
`associations between IP addresses in a domain and a domain name – perfectly in sync with the
`purpose of “naming information” in the Solana DNS systems.
`Patent Owner also contends that the Solana DNS systems do not receive “requests for a
`network address” required by the independent claims. Like its other assertions about Solana, this
`is incorrect. Solana’s DNS systems receive “requests for a network address” because they act on
`“generic Internet transactions” such as “WWW queries” that inherently contain “a request for a
`network address.” Fratto at ¶ 37-38; Solana at 42. “[I]n considering the disclosure of a
`reference, it is proper to take into account not only specific teachings of the reference but also the
`inferences which one skilled in the art would reasonably be expected to draw therefrom.” In re
`Preda, 401 F.2d 825, 826 (CCPA 1968)”). Here, Patent Owner simply ignores the statements in
`Solana that explain its DNS systems operate in an environment that require them to work within
`existing domain structures at the IP level (e.g., the public Internet structure). Fratto at ¶ 40.; see
`also Solana at p. 40-41 (“…we assume that the criteria to compose domains (for instance,
`
`
`
`
`7
`
`Petitioner Apple - Ex. 1067, p. 7
`
`

`
`Control No. 95/001,788
`Comments of the Requestor on the Patent Owner Response
`according to security or administrative needs) are already established and that a naming
`convention for domains has been defined.”)(emphasis added); see also id. at 42, FN2 (“the term
`“transaction has been preferred to application or service to stress the genericity (levels 4-6 of the
`TCP/IP stack) of the proposed concepts.”) Because Solana’s DNS systems must function in
`these standardized and established schemes, they necessarily receive “a request for a network
`address” when they act on a “generic Internet transaction … such as a WWW query,” Fratto at ¶
`35-37.
`
`The Patent Owner’s analysis is flawed because it assumes, incorrectly, that the claims
`require a particular configuration of components to make up a claimed “DNS system.” Thus,
`Patent Owner improperly (and incorrectly) criticizes Solana because one of the components in
`Solana (i.e., the DS) allegedly does not perform all of the functions recited in the claims. Indeed,
`in its response, Patent Owner consciously ignores features of the Solana DNS systems other than
`the DS that “store domain a plurality of domain names and corresponding network addresses”
`and “receive a query for a network address.” Specifically, as Figure 1 of Solana shows, the
`Solana DNS system receives a WWW query from a principal acting as an initiator. As explained
`above, a WWW query is “a request for a network address” and invariably will include a domain
`name requiring resolution into an IP address. Fratto at ¶ 37-48. In the Solana DNS systems,
`name resolution is performed not only to perform conventional Internet domain navigation
`functions, but also to enable the DBS to retrieve the initiator’s public key from the LAD – as is
`explained plainly at pp. 43-45 of Solana. Solana explains that the DBS is “the active player in
`the domain collaboration” and shows that the DBS receives and acts on requests (i.e., WWW
`queries) from initiators. Fratto at ¶ 38; Solana at Fig 1 (page 43). Being a computer system
`compatible with Internet standards governing communication and domain navigation, the DBS
`must inherently possess DNS name resolution capabilities – whether that resolution is done
`locally or, as is conventional, via a delegated DNS server is irrelevant to the claims, because the
`claims do not require all functions to be integrated into a single computer or process. Indeed,
`consistent with a design that integrates use of conventional DNS servers, Solana explains that its
`DNS systems can include multiple directory servers (i.e., multiple cylinders depicted in Figure 1
`at p. 43). And that this is not expressly stated in the text of Solana is irrelevant – a person of
`ordinary skill in the art would recognize that this is being described in Solana because of the
`context uses (i.e., explaining that its DNS systems handle WWW queries in a way that is
`
`
`
`
`8
`
`Petitioner Apple - Ex. 1067, p. 8
`
`

`
`Control No. 95/001,788
`Comments of the Requestor on the Patent Owner Response
`compatible with Internet protocols). Thus, Solana anticipates claims 1, 36 and 60 because it
`describes DNS systems configured to store a plurality domain names and corresponding network
`addresses, and to receive a query for a network address.
`The Patent Owner advances other incorrect theories about Solana to contest that the
`
`independent claims are anticipated. For example, Patent Owner claims that “requests sent from
`the initiator and responder … are queries for keys stored in the DS or the LAD.” See, e.g.,
`Response at ¶ 13-14. Solana, however, expressly states that requests can be WWW queries,
`which “generic Internet transactions” and inherently present domain names requiring name
`resolution as explained above. Fratto at ¶ 37-45. That an IP address provided in response to
`resolution of a WWW query will also used to retrieve keys needed to set up authenticated and
`encrypted inter-domain communications is thus irrelevant. Patent Owner’s discussion of the
`procedures depicted in Figures 2a and 2b of Solana is similarly flawed and irrelevant. These
`figures are again depicting events that occur after the initial WWW query has been sent by the
`initiator and has been acted upon by the DNS system (e.g., by the DBS). Fratto at ¶ 46. The
`Patent Owner statement, thus, that “the only query issued by the initiator is a query for a public
`key, and not a query for a network address” is thus plainly false, as a WWW query (i.e., the
`request sent by the initiator) inherently includes a request containing a domain name requiring
`resolution into an IP address. Fratto at ¶ 37-38. And, critically, nothing in the claims restricts the
`meaning of “request” to require it to only present a request a network address.
`
`Consequently, the findings of the Examiner that the independent claims are anticipated
`by Solana because the Solana DNS systems store domain names and corresponding IP addresses
`and receive requests for a network address should be maintained.
`b.
`Solana Discloses a Domain Name Service System That Includes
`An Indication That the Domain Name Service System
`Supports Establishing a Secure Communication Link
`
`The Examiner correctly found that Solana discloses “a Domain Name Service System
`
`configured to . . . comprise an indication that the domain name service system supports
`establishing a secure communication link.” Initially, Patent Owner’s responses strain to avoid
`stating what, exactly, constitutes “an indication that the [DNS system] supports establishing a
`secure communication link.” Instead, Patent Owner simply stands by its incorrect position that
`the systems described in Solana are not “DNS systems” and thus, whether they provide the
`required “indication” or not is irrelevant. See, e.g., Response at 15 (“These positions are
`
`9
`
`
`Petitioner Apple - Ex. 1067, p. 9
`
`

`
`Control No. 95/001,788
`Comments of the Requestor on the Patent Owner Response
`incorrect because Solana does not disclose the domain name service system recited in claim 1”).
`Notably, Patent Owner does not argue that Solana’s use of certificates and keys are not
`“indications” which would be understood by a person of ordinary skill to have constituted an
`“indication” required by the claims. Fratto at ¶ 49. Thus, because Solana describes DNS
`systems that provide the “indication” required by the claims, the Examiner’s finding of
`anticipation of claims 1, 36 and 60 was proper and should be maintained.
`
`2.
`Dependent Claims 5, 23, and 47 (Ground Nos. 1, 2, 5, 6)
`The Examiner correctly found that Solana discloses every limitation of dependent claims
`
`5, 23, and 47. In response, Patent Owner argues only that Solana does not disclose a query for a
`network address, and that the other cited references do not remedy that deficiency. Response at
`35. However, as discussed above, Solana discloses that its DNS systems act on WWW queries
`that inherently request network addresses. Fratto at ¶ 37-38. Thus, the Examiner’s rejection of
`these claims as being anticipated by Solana under 35 U.S.C. §102 and as being under §103 based
`on Solana in view of RFC 920 and/or RFC 2504 was proper and should be maintained.
`
`3.
`Dependent Claims 8 and 9 (Ground Nos. 1, 5)
`The Examiner correctly found that Solana discloses that the domain name service is
`
`connectable to a virtual private network. Patent Owner disagrees, arguing Solana only mentions
`the term VPN once in the context of organizations interacting with the Internet through
`restrictive firewalls. Response at 37. But again, Patent Owner fails to consider the teachings of
`Solana as a whole. Solana indisputably discusses the interplay of its system with VPNs. In
`particular, in discussing how its systems manage inter-domain confidentiality, Solana explains:
`The functionality offered by the DBSs in this scheme is often known as secure
`gatewaying. The main advantage of inter-domain confidentiality lies in the fact that
`services may be provided transparently to the parties involved in the transaction. This is
`especially convenient for:
`-
`Organizations having well protected private networks which are mostly concerned
`by securing bulk data exchanges beyond their borders at low management costs.
`See Solana at 45 (emphasis added). This explanation (which Patent Owner ignores) shows that
`the Solana DNS systems interface with and support communications over “private networks”
`(i.e., VPNs), and are thus “connectable” to VPNs. Moreover, the claims impose no requirements
`as to how the DNS systems must be “connectable” to a VPN. Consequently, the Examiner’s
`
`
`
`
`10
`
`Petitioner Apple - Ex. 1067, p. 10
`
`

`
`Control No. 95/001,788
`Comments of the Requestor on the Patent Owner Response
`rejection of claims 8 and 9 as anticipated by Solana, or as being obvious under §103 based on
`Solana in view of RFC 2504 was proper and should be maintained.
`
`4.
`Dependent Claims 16, 17, 27, 33, 40, 41, 51, and 57 (Ground Nos. 1, 5)
`The Examiner correctly found that Solana discloses every limitation of dependent claims
`16, 17, 27, 33, 40, 41, 51, and 57. In rebuttal, Patent Owner only argues that Solana does not
`describe a “domain name service system” and that the other cited references do not remedy that
`deficiency. Response at 41-42. Since Patent Owner’s assertions are incorrect, the Examiner’s
`rejection of these claims as anticipated by Solana, and as being obvious under §103 based on
`Solana in view of RFC 2504 was proper and should be maintained.
`
`5.
`Dependent Claims 18 and 42 (Ground Nos. 1, 5).
`The Examiner correctly found that Solana discloses every limitation of dependent claims
`18 and 42, including that “at least one of the plurality of domain names is reserved for secure
`communication links.” In response, Patent Owner asserts that Solana does not disclose that
`UNIs are used only for secure communications, thus one of the domain names is not “reserved.”
`Response at 45. As explained above, Patent Owner’s characterization of how UNI information is
`stored in the DS is incorrect, and ignores that when stored according to the DNS-sec
`infrastructure will associate security information with domain names. Fratto at ¶ 37. Also, the
`claims do not require that all domain names be used exclusively for secure communications.
`Because Solana describes at least one domain name being used to support secure communication
`links, it shows a domain name being “reserved” for that use. Consequently, the Examiner’s
`rejections of claims 18 and 42 as anticipated by Solana and as obvious under § 103 based on
`Solana in view of RFC 2504 were proper and should be maintained.
`
`6.
`Dependent Claims 24 and 48 (Ground Nos. 1, 2, 5, 6).
`The Examiner correctly found that Solana discloses every limitation of dependent claims
`24 and 48, including the requirement that “at least one of the plurality of domain names
`comprises an indication that the domain name service system supports establishing a secure
`communication link.” Patent Owner disagrees, arguing that the UNI “associated with” a
`certificate does not inherently provide an indication that the domain to which a certificate is
`associated is a “secure” domain. Response at 48. Again, Patent Owner incorrectly describes
`how naming information is published in the DS. Fratto at ¶ 37-45. Also, it ignores that Solana
`
`
`
`
`11
`
`Petitioner Apple - Ex. 1067, p. 11
`
`

`
`Control No. 95/001,788
`Comments of the Requestor on the Patent Owner Response
`teaches that as applied in its scheme the certificates associated with the domains in the DS are
`used to establish authenticated and encrypted communications between domains. They thus,
`“support” establishing a secure communication link as required by claims 24 and 48.
`Consequently, the Examiner’s rejections of these claims as anticipated by Solana, and as being
`obvious under § 103 based on Solana in view of RFC 920 and/or RFC 2504 was proper and
`should be maintained.
`
`7.
`Dependent Claims 26 and 50 (Ground Nos. 1, 5).
`The Examiner correctly found that Solana discloses every limitation of dependent claims
`26 and 50, including that “at least one of the plurality of domain names enables establishment of
`a secure communication link.” Patent Owner disagrees, contending that using a UNI “when”
`establishing a secure communication link does not mean that the UNI “itself” enables the secure
`communications link. Response at 53.