IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`In re Inter Partes Reexamination of:
`
`
`Mail Stop Inter Partes Reexam
`Commissioner for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`Dear Commissioner:
`
`PATENT OWNER’S RESPONSE TO
`OFFICE ACTION OF SEPTEMBER 26, 2012
`On December 29, 2011, the U.S. Patent and Trademark Office (“Office”) issued a first Office
`Action (“First OA” or “First Office Action”) in these reexamination proceedings. VirnetX Inc.
`(“VirnetX” or “Patent Owner”), the owner of U.S. Patent No. 7,418,504 (“the ’504 patent”), filed a
`Response (“Response”) on March 29, 2012. Requester Apple Inc. (“Apple” or “Requester”) filed
`Comments (“Comments”) on June 25, 2012. On September 26, 2012, the Office issued a second
`Office Action (“Second OA” or “Second Office Action”), which was an Action Closing Prosecution
`(“ACP”), in these proceedings.
`Claims 1-60 are patentable at least for the reasons that follow and the reasons stated in
`VirnetX’s March 29 Response. Thus, VirnetX requests that claims 1-60 be confirmed. This
`Response is supported by a Supplemental Declaration of Angelos D. Keromytis, Ph.D. (“Supp.
`Keromytis Decl.”). At times, this Response also refers to the initial Declaration of Angelos D.
`Keromytis, Ph.D. (“Keromytis Decl.”) supporting the Response filed on March 29, 2012.
`I.
`The Rejections Are Based on Improper Claim Constructions
`The Office’s patentability conclusions are defective because the Office takes incorrect
`positions on claim construction. In some instances, the Office proposes unreasonably broad
`constructions, stretching the ’504 patent claims beyond their proper scope to read on the asserted
`references. In other instances, the Office advocates constructions that are inconsistent with clear
`
`
`
`Control No.: 95/001,788
`
`Group Art Unit: 3992
`
`Examiner: Roland Foster
`
`Confirmation No.: 5823
`
`
` )
`
`
`)
`)
`)
`)
`)
`)
`)
`)
`)
`)
`
`
`
`
` Victor Larson et al.
`
`
`U.S. Patent No. 7,418,504
`
`Issued: August 26, 2008
`
`For: AGILE NETWORK PROTOCOL FOR SECURE
`COMMUNICATIONS USING SECURE
`DOMAIN NAMES
`
`VirnetX Exhibit 2017
`Black Swamp IP, LLC v. VirnetX Inc.
`IPR2016-00693
`
`Page 1 of 64
`
`

`
`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`
`disclaimers in the ’504 patent specification. Still in others, the Office does not apply the claim
`construction it elsewhere purports to adopt. These are effectively new claim-construction positions
`taken in the ACP, which Patent Owner has not had a chance to rebut. Given these new positions
`advocated by the Office, the latest Office Action should not have been an ACP.1 See M.P.E.P.
`§ 2671.02 (“Before an ACP is in order, a clear issue should be developed.”). Moreover, as explained
`below, even under the new positions raised in the ACP, the Office has not demonstrated that the
`claims are unpatentable.
`A.
`Standards for Claim Construction
`“During reexamination, claims are given the broadest reasonable interpretation consistent
`with the specification . . . .” Id. § 2258(I)(G); In re Abbott Diabetes Care Inc., 696 F.3d 1142, 1148
`(Fed. Cir. 2012). But while “the USPTO must give claims their broadest reasonable interpretation in
`light of the Specification,” this does not mean that it may construe a claim term to have an atypical
`meaning. In re Kuibira, Appeal No. 2009-002409, 2010 WL 390100, at *2 (B.P.A.I. Feb. 1, 2010).
`Instead, “the words of the claim must be given their ordinary meaning unless the ordinary meaning is
`inconsistent with the Specification.” Id. (emphasis added). As the Board noted, “the purpose
`[of giving claims their broadest reasonable interpretation] is not to stretch the interpretation of a
`claim limitation beyond what would be reasonably understood by the skilled worker in the light of
`the Specification, to read on a prior art structure which could possibly, but not reasonably, be covered
`by it.” In re Alferness, Appeal No. 2009-0122, 2009 WL 1171349, at *6 (B.P.A.I. Apr. 30, 2009).
`Given the Federal Circuit’s and the Board’s focus on reading claims in light of the specification, the
`Examiner is not free to disregard plain statements in the specification disclaiming certain
`embodiments from the scope of the claimed invention.
`B.
`The Rejections Are Based on Incorrect Constructions of the Claimed
`“Domain Name Service System”
`Independent claim 1 recites “a domain name service system configured to . . . comprise an
`indication that the domain name service system supports establishing a secure communication link”
`(emphases added). Independent claims 36 and 60 also recite a “domain name service system.”
`Accordingly, every claim of the ’504 patent expressly recites, or incorporates by virtue of its
`dependency, features relating to a “domain name service system” (“DNS system”). (See ’504 patent
`
`
`1 The Second Office Action should not have been an ACP, so Patent Owner requests a new,
`nonfinal Office Action for at least the reasons discussed in Patent Owner’s Petition to Reopen
`Prosecution Pursuant to 37 C.F.R. § 1.181, filed November 26, 2012.
`
`2
`
`Page 2 of 64
`
`

`
`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`
`55:49-60:14.) The Office’s construction of the claimed “DNS system,” however, is unreasonably
`broad.
`
`In construing “DNS system,” the Office states that a DNS system can include a single “DNS
`device” or multiple “DNS devices.” (Second OA at 15-18, referring to sections of the ’504 patent
`that discuss the roles of gatekeeper 2603, DNS proxy 2610, and DNS server 2609.) The Office then
`stretches this understanding to contend that virtually any device—regardless of whether it has any
`DNS functionality—may be a “DNS device” as long as it is in the same network as at least one
`device that actually has DNS functionality. Indeed, the Office construes a “DNS system” and
`interprets a “DNS device” as having no bounds whatsoever, and it applies those terms accordingly.
`(See id.)
`Through these improper constructions, the Office has stretched the recited DNS system
`beyond its proper scope to encompass, in the asserted references, many devices that one of ordinary
`skill in the art would have viewed as non-DNS devices, outside the scope of a DNS system. (Supp.
`Keromytis Decl. ¶¶ 8-9.) For example, the Office contends devices like firewalls, key exchanger
`nodes, client and server devices, and other devices performing no DNS functions whatsoever are part
`of the claimed DNS system. If the Office’s unbounded view of a DNS device is correct, virtually
`any component, if connected to a computing network that has DNS functionality somewhere within it
`(e.g., the Internet), qualifies as a DNS device within a DNS system. (Id. ¶ 9.) The Office’s
`construction is simply unreasonably broad and is inconsistent with how one of ordinary skill in the
`art would have understood a DNS system, particularly in light of the ’504 patent specification.
`The Office relies on the ’504 patent’s description of gatekeeper 2603, DNS proxy 2610, and
`DNS server 2609 to support its unreasonable interpretation of a DNS system. However, the
`’504 patent discloses significant DNS functionality and coordination between these devices in acting
`upon a DNS request. (Id. ¶¶ 6-7.) For example, the ’504 patent specification explains that, in one
`scenario, DNS proxy 2610 receives a DNS request, determines that the DNS request is for a
`nonsecure target site, and passes the DNS request through to DNS server 2609 for resolution to the
`client. (’504 patent 40:6-8, 40:25-29, 40:53-56.) Thus, DNS proxy 2610 and DNS server 2609
`interact with each other to process a DNS request, and the client need not run separate lookups with
`both the proxy and the server. (Id.; Supp. Keromytis Decl. ¶ 7.) Alternatively, DNS proxy 2610 may
`determine that the DNS request is for a secure target site, perform an authorization check, transmit a
`message to gatekeeper 2603 to facilitate creating a VPN link, and obtain a resolved address from the
`gatekeeper 2603 to return to the client. (’504 patent 40:6-24, 40:57-59.) Again, in this scenario, the
`DNS proxy 2610 and the gatekeeper 2603 interact together to process a DNS request, and the client
`
`3
`
`Page 3 of 64
`
`

`
`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`need not run separate lookups with the proxy and the gatekeeper. (Id.; Supp. Keromytis Decl. ¶ 7.)
`These devices all have significant DNS functionality, and any assertion that DNS devices may
`include devices not having actual DNS functionality directly contradicts the explicit and consistent
`teachings of the ’504 patent specification. By doing just this, the Office adopts an unreasonable
`construction of a DNS system with no outer limits that sweeps in non-DNS devices. (Supp.
`Keromytis Decl. ¶¶ 8-9.) The ’504 patent specification does not support the Office’s unbounded
`interpretation.
`The asserted references also contradict the Office’s overbroad construction of a “DNS
`device” and a “DNS system.” As one example discussed in greater detail below, RFC 2230
`describes a “domain name system” and explains that various nodes on a network may utilize this
`domain name system. (RFC 2230 1.) RFC 2230 describes the proxy routers R1 and R2 as nodes that
`interact with the domain name system by performing DNS requests that the domain name system
`must then process, but the routers are never described as being part of the domain name system itself.
`(See, e.g., id. at 2-6.) Thus, the domain name system is described as being separate and apart from
`the routers that merely interact with the domain name system by making DNS requests. In spite of
`this fact, the Office nonetheless concludes that R1 and R2 are DNS devices that are part of the
`claimed DNS system. (See Second OA at 15-18.) Thus, this reference and others, as discussed in
`greater detail in the sections corresponding to those references, demonstrate that the Office’s
`construction is unreasonable and contrary to the understanding of a person of ordinary skill in the art
`at the time of the invention.
`For these reasons and those discussed in greater detail below, the rejections are based on an
`improper construction of the claimed DNS system and should be withdrawn.
`C.
`The Rejections Are Based on Incorrect Constructions of the Claimed
`“Indication”
`Every claim of the ’504 patent also recites, or incorporates by virtue of its dependency, the
`feature of “an indication that the domain name service system supports establishing a secure
`communication link.” (See ’504 patent 55:49-60:14.) The Office’s construction of the recited
`“indication” is also incorrect and renders the Office’s patentability conclusions defective for at least
`two reasons. First, the Office adopts a construction of the claimed indication but then concludes that
`the cited references disclose this feature without ever applying its construction. Second, the Office
`instead implicitly adopts a second, unreasonably broad construction that is disclaimed in the ’504
`patent specification. Thus, as discussed in greater detail below, the Office’s rejections should be
`withdrawn.
`
`4
`
`Page 4 of 64
`
`

`
`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`
`The Office construes the recited “indication” term as “a visible message or signal to a user
`that the DNS system supports establishing a secure communication link.” (Second OA at 18, citing
`Apple Comments, Ex. A.) But the Office never applies this construction when attempting to show
`how the references allegedly disclose the recited indication. As one example, the Office asserts that
`Solana’s use of certificates and encryption keys discloses the recited indication, without explaining
`how the use of certificates and keys provides a “visible message or signal to a user.” (See, e.g., id. at
`7, incorporating Req. at 44-45; see also id. at 19-25.) In fact, those skilled in the art would have
`understood that certificates and encryption keys were not visible messages or signals to a user.
`(Supp. Keromytis Decl. ¶ 11.) The Office similarly omits this analysis in rejections based on other
`references.
`Although VirnetX does not agree with the Office’s purported claim construction, VirnetX’s
`ability to challenge the application of its construction is significantly hampered because the Office
`has not explained how it should be applied. As a result, Patent Owner has to guess as to the true
`basis for the rejection, improperly placing the burden of establishing a prima facie case of
`anticipation on Patent Owner rather than the Office. In re Jung, 637 F.3d 1356, 1362 (Fed. Cir.
`2011) (“The Patent and Trademark Office (‘PTO’) satisfies its initial burden of production by
`‘adequately explain[ing] the shortcomings it perceives so that the applicant is properly notified and
`able to respond.’” (alteration in original) (citation omitted)). By concealing the basis for its rejection
`in this manner, the Office has also contravened 35 U.S.C. § 132. Chester v. Miller, 906 F.2d 1574,
`1578 (Fed. Cir. 1990) (Section 132 is violated “when a rejection is so uninformative that it prevents
`the applicant from recognizing and seeking to counter the grounds for rejection”).
`Also, the Second Office Action applies a much broader construction of “indication” that
`encompasses features that neither indicate that the domain name service system supports establishing
`a secure communication link nor are visible to any users, such as merely returning an IP address, a
`public key, or a certificate demonstrating authenticity of the source of the public key. (See, e.g., OA
`at 34, “interpreting the claimed ‘indication’ as a provision of an address is reasonably broad
`consistent with the specification”; id. at 42, “the release of the Cert RR [a certificate demonstrating
`authenticity of a source of a public key] by the DNS server . . . certainly indicates secure
`communications is supported . . . .”) This implied construction is improper because it is inconsistent
`with the ’504 patent specification. M.P.E.P. § 2258(I)(G) (“During reexamination, claims are given
`the broadest reasonable interpretation consistent with the specification . . . .” (emphasis added)); see
`also Abbott, 696 F.3d at 1149 (“Usually [the specification] is dispositive; it is the single best guide to
`the meaning of a disputed term.” (citation omitted)).
`
`5
`
`Page 5 of 64
`
`

`
`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`
`The ’504 patent specification clearly and unequivocally disclaims merely returning an
`address or a public key by describing these actions as “conventional” in the prior art:
`Conventional Domain Name Servers (DNSs) provide a look-up function that returns
`the IP address of a requested computer or host. . . .
`One conventional scheme that provides secure virtual private networks over the
`Internet provides the DNS server with public keys of the machines that the DNS
`server has the address for. This allows hosts to retrieve automatically the public keys
`of a host that the host is to communicate with . . . . One implementation of this
`standard is presently being developed as part of the Free S/WAN project (RFC 2535).
`(’504 patent 39:7-42, emphases added.) The specification explains that DNS systems that perform
`no more than these conventional functions have many shortcomings, and further explains novel
`DNS-system embodiments that go beyond these conventional functions by supporting establishing
`secure communications. (Supp. Keromytis Decl. ¶ 12.)
`Furthermore, the ’504 patent specification repeatedly and explicitly disparages systems with
`functionalities limited to the conventional IP-address and public-key features discussed above.
`Abbott, 696 F.3d at 1149-50 (holding that disparagement of features in the specification supports
`disclaimer). For example, the ’504 patent specification explains:
`In the conventional architecture . . . , nefarious listeners on the Internet could
`intercept the DNS REQ and DNS RESP packets . . . . This would hamper anonymous
`communications on the Internet. . . .
`The conventional scheme suffers from certain drawbacks . . . .
`According to certain aspects of the invention . . . , the server does not return the true
`IP address of the target node, but instead automatically sets up a virtual private
`network . . . .
`Had the user requested lookup of a non-secure web site, such as site 2611, DNS
`proxy would merely pass through to conventional DNS server 2609 the look-up
`request, which would be handled in a conventional manner, returning the IP
`address . . . .
`(’504 patent 39:7-40:29, emphases added.)
`Never does the specification equate the mere return of requested DNS records, such as an IP
`address or key certificate, with supporting secure communications. Indeed, in one embodiment, the
`DNS system does not return an IP address, “but instead automatically sets up a virtual private
`network between the target node and the user.” (Id. at 39:50-51; Supp. Keromytis Decl. ¶ 13.) In
`another embodiment, “DNS proxy 2610 transmits a message to gatekeeper 2603 requesting that a
`virtual private network be created between user computer 2601 and secure target site 2604,” with an
`IP address only being returned after the secure communication link is set up. (’504 patent 40:12-24,
`emphases added.) In yet another embodiment, “a secure VPN is established between the user’s
`
`6
`
`Page 6 of 64
`
`

`
`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`computer and the secure target site,” without any return of DNS records. (Id. at 41:5-15.) In still
`another, “[t]he gatekeeper would establish a VPN between the client and the requested target” before
`any IP address is returned. (Id. at 41:23-32.)
`Likewise, in an embodiment relating to Fig. 34, the SDNS only returns a secure URL after it
`has already coordinated with the VPN gatekeeper to establish a VPN. (Supp. Keromytis Decl. ¶ 14.)
`For example, in step 3409, “SDNS 3313 accesses VPN gatekeeper 3314 for establishing a VPN
`communication link between software module 3309 [on computer 3301] and secure server 3320,”
`and then VPN gatekeeper provisions computer 3301 and secure web server 3320 or its edge router,
`“thereby creating the VPN.” (’504 patent 51:34-40.) Next, in step 3410, the SDNS 3313 returns a
`secure URL either through an administrative VPN link or “in the clear,” it does not matter which.
`(Id. at 51:44-61.) Then, in step 3411, the software module on computer 3301 “accesses secure server
`3320 through VPN communication link 3321 based on the VPN resources allocated by VPN
`gatekeeper 3314.” (Id. at 51:62-64.)
`By comparison, the mere return of requested DNS records, without more, is described in the
`specification only as a default process for non-secure communications. (Id. at 40:25-29, “Had the
`user requested lookup of a non-secure web site . . . , DNS proxy would merely pass through to
`conventional DNS server 2609 the look-up request,” emphasis added; see also id. at 39:56-61, 40:49-
`56, 41:41-49; Supp. Keromytis Decl. ¶ 15.) Therefore, the Office’s unreasonably broad claim
`construction, improperly encompasses the very conventional and unremarkable features that the
`’504 patent specification “repeatedly, consistently, and exclusively” distinguishes and disparages.
`Abbott, 696 F.3d at 1150.
`The ’504 patent claims reinforce the specification’s disparagement of the conventional
`features in the prior art. Many of the claims recite various configurations of a DNS system. These
`configurations include, for example, a DNS system configured to comprise an indication that the
`DNS system supports establishing a secure communication link. (See, e.g., ’504 patent claim 1.)
`Certain dependent claims are also directed to the returning of requested DNS records, which the ’504
`patent claims as another configuration. (See, e.g., id. at claim 15, “[t]he system of claim 1, wherein
`the domain name service system is configured to provide, in response to the query, the network
`address corresponding to a domain name,” emphasis added; see also id. at claims 14, 16, 35, 38-40,
`59.) These query-response claims reflect the specification embodiments that not only establish a
`secure communication link, but additionally return an IP address. (See, e.g., id. at 40:6-24, 41:23-
`32.) Thus, the ’504 patent’s specification and its claims are in harmony regarding the conventional
`features of returning requested DNS records, such as an IP address or public key. Construing the
`
`7
`
`Page 7 of 64
`
`

`
`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`
`recited “indication” to include the disparaged and disclaimed conventional features, as the Office has
`done, is unreasonable in light of the specification and the differentiation in the claims. Indeed,
`returning requested DNS records indicates nothing more than that a DNS system has merely
`performed the conventional duties asked of it.
`Recognizing that the ’504 patent describes IP address or public key messages as conventional
`features, Requester appears to argue that only explicit, rigid definitions or disclaimers can affect
`claim scope. (Comments at 4.) This is not the law. The Federal Circuit has instructed that the type
`of “rigid formalism” advocated by Requester is not required to establish a disclaimer:
`Astrazeneca seems to suggest that clear disavowal requires an “expression of
`manifest exclusion or restriction” in the form of “my invention does not
`include _____.” But again, such rigid formalism is not required: Where the general
`summary or description of the invention describes a feature of the invention . . . and
`criticizes other products . . . that lack that same feature, this operates as a clear
`disavowal of these other products (and processes using these products).
`Astrazeneca AB v. Mut. Pharm. Co., 384 F.3d 1333, 1340 (Fed. Cir. 2004) (holding that the
`patentee’s specification “clearly disavow[ed] nonsurfactant solubilizers” by describing, in relation to
`the invention, micelle structures only formed by surfactant solubilizers, while at the same time
`criticizing the undesired effects associated with using other types of solubilizers); see also Abbott,
`696 F.3d at 1148-50 (holding that the broadest reasonable construction of “electrochemical sensor”
`was one without cables or wires, and that the specification did not need to include an “express
`disclaimer” of a sensor with cables and wires when every disclosed embodiment was devoid of
`cables and wires, and the specification only mentioned a sensor with cables or wires to disparage the
`prior art).
`The disclaimers found in the ’504 patent far exceed the threshold set by controlling cases and
`reflect an unmistakable disavowal of claim scope that the Office must respect in its claim-
`construction analysis. Because the cited references disclose only conventional features that are
`outside the scope of the properly construed claims, the Office should withdraw the rejections relying
`on those references and allow all pending claims. If the Office persists in rejecting the claims, the
`next Office Action should be a nonfinal action setting forth its construction of the disputed claim
`terms and explaining how its construction applies to each of the cited references for each of the
`rejected claims. See M.P.E.P. § 2671.02 (“Before an ACP is in order, a clear issue should be
`developed.”).
`
`8
`
`Page 8 of 64
`
`

`
`II.
`
`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`The Rejections Based on Solana Should Be Withdrawn (Issues 1-8)
`A.
`The Rejection of Claims 1, 2, 5, 6, 8, 9, and 14-60 Based on Solana
`(Issue 1) Should Be Withdrawn
`The Second Office Action rejects claims 1, 2, 5, 6, 8, 9, and 14-60 under 35 U.S.C. § 102(b)
`based on Solana. (Second OA at 5.) For at least the reasons discussed in the Response and discussed
`below, this rejection should be withdrawn and the claims should be confirmed.
`1.
`Independent Claim 1
`a. Solana Does Not Disclose “a Domain Name Service System
`Configured to . . . Comprise an Indication that the Domain
`Name Service System Supports Establishing a Secure
`Communication Link”
`Independent claim 1 recites, among other things, “a domain name service system configured
`to . . . comprise an indication that the domain name service system supports establishing a secure
`communication link.” Solana fails to disclose this feature for at least the two reasons discussed
`below.
`
`(i) Solana Does Not Disclose the Recited “Indication” as that
`Term Is Construed by the Office
`As discussed above in Section I.C, the Office interprets the “indication” recited in claim 1 as
`“a visible message or signal to a user that the DNS system supports establishing a secure
`communication link.” (Second OA at 18, citing Apple Comments, Ex. A.) However, the Office does
`not even apply its own construction of this term when addressing Solana in connection with the term.
`Instead, the Office merely states that Solana uses certificates and encryption keys, but never explains
`how Solana’s use of certificates and encryption keys is a “visible message or signal to a user.” (See
`id. at 7, incorporating Req. at 44-45, emphases added.) This is because Solana does not disclose that
`its certificates and encryption keys are visible messages or signals to a user at all. (Supp. Keromytis
`Decl. ¶ 16.) Thus, because the Office does not demonstrate how Solana discloses an “indication” as
`the Office [albeit improperly] interprets the term, the rejection of claim 1 is legally deficient and
`cannot support a finding that Solana anticipates the claim. For at least these reasons and those
`discussed above in Section I.C, the rejection of claim 1 should be withdrawn.
`(ii) Solana Does Not Disclose the Recited “Indication” Under
`a Proper Broadest Reasonable Interpretation
`Solana also does not disclose the recited “indication” under a proper broadest reasonable
`interpretation because Solana discloses a conventional certificate/key architecture similar to that
`expressly disclaimed and disparaged by the ’504 patent specification. As discussed above in Section
`I.C, merely returning requested resources such as IP addresses and public keys is not an “indication”
`
`9
`
`Page 9 of 64
`
`

`
`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`
`as the term is properly construed under the Office’s broadest reasonable interpretation standard, in
`light of the specification.
`Specifically, the Office asserts that Solana discloses a “DNS-sec embodiment” by allegedly
`incorporating by reference RFC 2065.2 (Second OA at 19.) RFC 2065, however, was replaced and
`made obsolete by RFC 2535, which the ’504 patent distinguishes as a “conventional scheme.” (See
`Ex. A-6 at 1, 44-45; see also ’504 patent 39:34-41, “One conventional scheme that provides secure
`virtual private networks over the Internet provides the DNS server with the public keys of the
`machines that the DNS server has the addresses for. . . . One implementation of this standard is
`presently being developed as part of the FreeS/WAN project (RFC 2535),” emphases added.) The
`’504 patent’s disparaging of RFC 2535 as conventional equally applies to RFC 2535’s predecessor,
`RFC 2065. As such, Solana’s conventional certificate/key architectures cannot show the
`“indication” recited in the claims because the broadest reasonable interpretation of the term cannot
`include such architectures as the ’504 patent distinguishes its embodiments from these types of
`implementations. See Abbott, 696 F.3d at 1149-50.
`b.
`Solana Does Not Disclose “a Domain Name Service System
`Configured to . . . Store Domain Names and
`Corresponding Network Addresses” and “Receive a
`Query for a Network Address”
`Independent claim 1 also recites, among other things, “a domain name service system
`configured to . . . store domain names and corresponding network addresses . . . and receive a query
`for a network address.” Solana fails to disclose these features for at least the two reasons discussed
`below.
`First, Solana does not explicitly disclose the recited features, (see Supp. Keromytis Decl.
`¶ 18; see also Response at 11-13), and does not incorporate by reference any publication that does.
`The Office does not dispute that Solana fails to explicitly disclose these features. Instead, the Office
`improperly asserts that Solana incorporates by reference three different RFCs allegedly disclosing
`these features based on Solana’s generalized reference to one of those RFCs in a footnote. As
`explained below, the Office’s position is untenable.
`Specifically, the Office cites to a portion of Solana disclosing a Directory Service (DS) that
`holds naming information and certificates that bind domains to their public keys. (Second OA at 19,
`citing Solana 43.) Because Solana discloses that existing infrastructures such as DNS-sec or X.509
`
`
`2 As discussed below in Section II.A.1.b, VirnetX disagrees with the Office’s assertion that
`Solana incorporates RFC 2065 by reference.
`
`10
`
`Page 10 of 64
`
`

`
`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`may be used for this purpose, the Office refers to this as the “DNS-sec embodiment of Solana.” (Id.)
`The Office then points to a different section in Solana describing previously implemented certificate
`structures, such as DNS-sec, where Solana cites generally to RFC 2065 in a footnote. (Id., citing
`Solana 39 n.16.) Because RFC 2065 in turn mentions RFCs 1034 and 1035, the Office asserts that
`“the DNS-sec embodiment of Solana incorporates at least RFC(s) 1034, 1035, and 2065.” (Id.) The
`Office then cites to various portions of RFC 1034 and RFC 2065, and concludes that the Solana
`“DNS-sec embodiment” discloses the above-mentioned features. (Id. at 21-22.) Solana, however,
`does not incorporate these three RFCs because Solana merely references only RFC 2065 in a
`footnote and does not “identify with detailed particularity what specific material it incorporates and
`clearly indicate where that material is found.” Adv. Display Sys., Inc. v. Kent State Univ., 212 F.3d
`1272, 1282 (Fed. Cir. 2000) (emphases added); see also In re de Seversky, 474 F.2d 671, 674
`(C.C.P.A. 1973) (stating that “mere reference to another application, or patent, or publication is not
`an incorporation of anything therein . . . .”).
`Moreover, Solana does not even mention the other two RFCs, 1034 and 1035. While the
`Office asserts that RFC 2065 “cites to and incorporates” these RFCs, (Second OA at 19), RFC 2065
`merely states that “[i]t assumes that the reader is familiar with the Domain Name System,
`particularly as described in RFCs 1033, 1034, and 1035” (Req. Ex. D-4 at 3). This statement hardly
`amounts to “identify[ing] with detailed particularity what specific material it incorporates and
`clearly indicat[ing] where that material is found.” Adv. Display Sys., 212 F.3d at 1282 (emphases
`added). Asserting that Solana’s mere reference to RFC 2065 incorporates all three RFCs is legally
`deficient, as it contends to incorporate references that Solana does not even mention.
`Second, even if Solana had properly incorporated RFC 2065 by reference (which it does not),
`this does not mean that Solana’s DS is necessarily configured to store domain names and
`corresponding network addresses, and to receive a query for a network address. For example, the
`Second Office Action suggests, and Requester’s Comments explicitly assert, that by referencing
`DNS-sec, Solana discloses that the DS is a DNS server. (See Second OA at 19-22; see also
`Comments at 6, arguing that by disclosing that DNS-sec may be used in the DS, Solana “requires the
`DS to include a DNS server . . . .) This is not true. The portion of Solana relied on by both the
`Office and Requester states that
`[a] coordinated, global Directory Service (DS) holding naming information and
`especially certificates that securely bind domains to their public keys is also required
`and constitutes the cryptographic support for inter-domain transactions. As
`mentioned, existing naming infrastructures (DNS-sec, X.509) might be used for this
`purpose.
`
`11
`
`Page 11 of 64
`
`

`
`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`(Solana 43, emphases added.) Thus, Solana discloses that a naming infrastructure such as DNS-sec
`may be used to “hold[] naming information and especially certificates that securely bind domains to
`their public keys.” (Id.) But using the DNS