IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`Control No.: 95/001,789
`
`Group Art Unit: 3992
`
`Examiner: Roland Foster
`
`Confirmation No.: 6053
`
`
`
`In re Inter Partes Reexamination of:
`
` Victor Larson et al.
`
`U.S. Patent No. 7,921,211
`
`Issued: April 5, 2011
`
`For: AGILE NETWORK PROTOCOL FOR SECURE
`COMMUNICATIONS USING SECURE
`DOMAIN NAMES
`
` )
`
`
`)
`)
`)
`)
`)
`)
`)
`)
`)
`)
`
`
`
`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 January 18, 2012, 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,921,211 (“the ’211 patent”), filed a
`Response (“Response”) on April 18, 2012. Requester Apple Inc. (“Apple” or “Requester”) filed
`Comments (“Comments”) on August 6, 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 April 18 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 April 18, 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 ’211 patent claims beyond their proper scope to read on the asserted
`references. In other instances, the Office advocates constructions that are inconsistent with clear
`
`Page 1 of 67
`
`VirnetX Exhibit 2017
`Black Swamp IP, LLC v. VirnetX Inc.
`IPR2016-00957
`
`

`

`Control No. 95/001,789
`Attorney Docket No. 11798.0012
`
`disclaimers in the ’211 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 . . . .” M.P.E.P. § 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 Unreasonable Constructions of the Claimed
`“Domain Name Service System”
`Independent claim 1 recites “a domain name service system configured and arranged to . . .
`indicate in response to the query whether 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 ’211 patent expressly recites, or incorporates
`by virtue of its dependency, features relating to a “domain name service system” (“DNS system”).
`
`
`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 67
`
`

`

`Control No. 95/001,789
`Attorney Docket No. 11798.0012
`
`(See ’211 patent 55:38-60:8.) 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 ’211 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. ¶¶ 8-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 ’211 patent specification.
`The Office relies on the ’211 patent’s description of gatekeeper 2603, DNS proxy 2610, and
`DNS server 2609 to support its unreasonable interpretation of a DNS system. However, the
`’211 patent discloses significant DNS functionality and coordination between these devices in acting
`upon a DNS request. (Id. ¶ 7.) For example, the ’211 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. (’211 patent 39:57-59, 40:9-13, 40:36-39.) 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. (’211 patent 39:57-40:8, 40:40-42.) Again, in this scenario,
`
`3
`
`Page 3 of 67
`
`

`

`Control No. 95/001,789
`Attorney Docket No. 11798.0012
`
`the DNS proxy 2610 and the gatekeeper 2603 interact together to process a DNS request, and the
`client 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 ’211 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. ¶¶ 7-9.) The ’211 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 38-39.) 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 Unreasonable Constructions of the
`“Indicate” Feature
`Every claim of the ’211 patent also recites: “indicate in response to the query whether the
`domain name service system supports establishing a secure communication link,” or incorporates the
`“indicate” or “indicating” features of the independent claims by virtue of its dependency. (See ’211
`patent 55:38-60:8.) The Office’s construction of the recited “indicate”2 is also incorrect and renders
`the Office’s patentability conclusions defective for at least two reasons. First, the Office adopts a
`construction for “indicate” but then concludes that the cited references disclose this feature without
`
`2 The Office uses the term “indication.” Patent Owner understands that the Office’s
`discussion of indication relates to the “indicate” feature discussed above.
`
`4
`
`Page 4 of 67
`
`

`

`Control No. 95/001,789
`Attorney Docket No. 11798.0012
`
`ever applying its construction. Second, the Office instead implicitly adopts a second, unreasonably
`broad construction that is disclaimed in the ’211 patent specification. Thus, as discussed in greater
`detail below, the Office’s rejections should be withdrawn.
`The Office construes the recited “indicate” feature 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 this feature. As one example, the Office asserts that Solana’s
`use of certificates and encryption keys discloses this feature, 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 45-46; see also id. at 18-22.) 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 the recited “indicate”
`feature that encompasses features that neither indicate whether 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 44, “the release of a Cert RR [a certificate
`demonstrating authenticity of a source of a public key] by the DNS server by itself certainly indicates
`secure communications is supported . . . .”) This implied construction is improper because it is
`
`5
`
`Page 5 of 67
`
`

`

`Control No. 95/001,789
`Attorney Docket No. 11798.0012
`
`inconsistent with the ’211 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)).
`The ’211 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).
`(’211 patent 38:58-39:26, 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 ’211 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 ’211 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 . . . .
`(’211 patent 38:58-40:13, 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:34-35; Supp. Keromytis Decl. ¶ 13.) In
`
`6
`
`Page 6 of 67
`
`

`

`Control No. 95/001,789
`Attorney Docket No. 11798.0012
`
`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. (’211 patent 39:63-
`40:8, emphases added.) In yet another embodiment, “a secure VPN is established between the user’s
`computer and the secure target site,” without any return of DNS records. (Id. at 40:55-65.) 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:6-15.)
`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.” (’211 patent 51:22-28.) 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:32-50.) 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:51-53.)
`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:9-13, “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:40-45, 40:32-
`39, 41:25-33; Supp. Keromytis Decl. ¶ 15.) Therefore, the Office’s unreasonably broad claim
`construction, improperly encompasses the very conventional and unremarkable features that the
`’211 patent specification “repeatedly, consistently, and exclusively” distinguishes and disparages.
`Abbott, 696 F.3d at 1150.
`The ’211 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 and arranged to indicate whether the
`DNS system supports establishing a secure communication link. (See, e.g., ’211 patent claim 1.)
`Certain dependent claims are additionally directed to the returning of requested DNS records, which
`the ’211 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
`
`7
`
`Page 7 of 67
`
`

`

`Control No. 95/001,789
`Attorney Docket No. 11798.0012
`
`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
`support establishing a secure communication link, but additionally return an IP address. (See, e.g.,
`id. at 39:57-40:8, 41:6-15.) Thus, the ’211 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 “indicate” feature 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 ’211 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 ’211 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
`
`8
`
`Page 8 of 67
`
`

`

`Control No. 95/001,789
`Attorney Docket No. 11798.0012
`
`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.”).
`II.
`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 and Arranged to . . . Indicate in Response to
`the Query Whether the Domain Name Service System
`Supports Establishing a Secure Communication Link”
`Independent claim 1 recites, among other things, “a domain name service system configured
`and arranged to indicate in response to the query whether the domain name service system supports
`establishing a secure communication link.” Solana fails to disclose this feature for at least the three
`reasons discussed below.
`
`(i) Solana Does Not Disclose the Recited “Indicate” Feature
`as that Term Is Construed by the Office
`As discussed above in Section I.C, the Office interprets the “indicate” feature to be “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 recited “indicat[ing]”
`step of claim 1. 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.) 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
`the recited “indicat[ing]” 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.
`
`9
`
`Page 9 of 67
`
`

`

`Control No. 95/001,789
`Attorney Docket No. 11798.0012
`
`
`(ii) Solana Does Not Disclose the Recited “Indicate” Feature
`Under a Proper Broadest Reasonable Interpretation
`Solana also does not disclose the recited “indicate” feature under a proper broadest
`reasonable interpretation because Solana discloses a conventional certificate/key architecture similar
`to that expressly disclaimed and disparaged by the ’211 patent specification. As discussed above in
`Section I.C, merely returning requested resources such as IP addresses and public keys does not
`“indicate” whether a domain name service system supports establishing a secure communication link,
`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.3 (Second OA at 18-19.) RFC 2065, however, was replaced
`and made obsolete by RFC 2535, which the ’211 patent distinguishes as a “conventional scheme.”
`(See Ex. A-6 at 1, 44-45; see also ’211 patent 39:18-26, “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
`’211 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 “indicate”
`feature recited in the claims because the broadest reasonable interpretation of the term cannot include
`such architectures as the ’211 patent distinguishes its embodiments from these types of
`implementations. See Abbott, 696 F.3d at 1149-50.
`(iii) Solana Does Not Disclose “Indicat[ing] in Response to the
`Query [for a Network Address] Whether the Domain
`Name Service System Supports Establishing a Secure
`Communication Link”
`As discussed in the Response, Solana does not disclose that the alleged domain name service
`system is configured an arranged to “indicate in response to the query [for a network address]
`whether the domain name service system supports establishing a secure communication link,” as
`recited in claim 1 (emphasis added). (See Response at 16-17.) Instead, as explained in the Response,
`Solana teaches that the returning of keys and certificates, which the Office points to as the claimed
`“indicating” limitations, is performed in response to the query for the key itself. (Id.) The Second
`Office Action ignores Patent Owner’s argument, incorrectly labeling it as “premised on the notion
`
`3 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 67
`
`

`

`Control No. 95/001,789
`Attorney Docket No. 11798.0012
`
`that Solana fails to disclose a DNS system.” (See Second OA at 21-22.) The Office thus improperly
`designated the Second Office Action as an ACP. See M.P.E.P. § 2671.02 (“Before an ACP is in
`order, a clear issue should be developed.”). For at least this reason, the Office’s rejection should be
`withdrawn. Moreover, for at least the reasons discussed in the Response, (see Response at 16-17),
`Solana does not disclose this feature and the rejection should be withdrawn.
`b.
`Solana Does Not Disclose “a Domain Name Service System
`Configured and Arranged 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 and arranged 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 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 18,
`citing Solana 43.) Because Solana discloses that existing infrastructures such as DNS-sec or X.509
`may be used for this purpose, the Office refers to this as the “DNS-sec embodiment of Solana.”
`(Id. at 18-19.) 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 20-21.)
`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
`
`11
`
`Page 11 of 67
`
`

`

`Control No. 95/001,789
`Attorney Docket No. 11798.0012
`
`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 asser