IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`) )
`
`)
`)
`
`In re Inter Partes Reexamination of:
`
`Victor Larson et a!.
`
`U.S. Patent No. 7,418,504
`
`Issued: August 26,2008
`
`For: AGILE NETWORK PROTOCOL FOR SECURE)
`COMMUNICATIONS USING SECURE
`DOMAIN NAMES
`
`)
`)
`) Group Art Unit: 3992
`)
`)
`)
`
`Control No.: 95/001,788
`
`Examiner: Roland Foster
`
`Confirmation No.: 5823
`
`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
`issued a first Office
`On December 29,2011,
`the U.S. Patent and Trademark Office ("Office")
`Action ("First OA" or "First Office Action")
`in these reexamination proceedings. VimetX Inc.
`("VimetX" 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.
`least for the reasons that follow and the reasons stated in
`Claims 1-60 are patentable at
`VimetX's March 29 Response.
`Thus, VimetX requests
`that claims 1-60 be confirmed.
`This
`Response is supported by a Supplemental Declaration of Angelos D. Keromytis, Ph.D.
`("Supp.
`Keromytis Dec!."). At
`times,
`this Response also refers to the initial Declaration of Angelos D.
`Keromytis, Ph.D. ("Keromytis Dec!.") 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
`
`Petitioner Apple - Ex. 1069, p. 1
`
`

`

`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`
`the Office does not apply the claim
`in others,
`Still
`in the '504 patent specification.
`disclaimers
`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
`See M.P.E.P.
`advocated by the Office,
`the latest Office Action should not have been an ACP. J
`§ 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
`reasonable interpretation consistent
`"During reexamination,
`claims are given the broadest
`" Id. § 2258(I)(G); In re Abbott Diabetes Care Inc., 696 F.3d 1142, 1148
`with the specification ....
`(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
`In re Kuibira, Appeal No. 2009-002409, 2010 WL 390100, at *2 (B.P.A.I. Feb. 1,2010).
`meaning.
`Instead, "the words of the claim must be given their ordinary meaning unless the ordinary meaning is
`Id.
`inconsistent with the Specification."
`(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
`(See' 504 patent
`dependency,
`features relating to a "domain name service system" ("DNS system").
`
`J 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
`
`Petitioner Apple - Ex. 1069, p. 2
`
`

`

`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`
`55:49-60:14.)
`broad.
`
`The Office's construction of the claimed "DNS system," however,
`
`is unreasonably
`
`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.)
`
`the Office has stretched the recited DNS system
`Through these improper constructions,
`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
`(ld. ~ 9.) The Office's
`(e.g.,
`the Internet), qualifies as a DNS device within a DNS system.
`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
`(ld. ~~ 6-7.) For example,
`upon a DNS request.
`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.
`(Jd.; 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
`
`Petitioner Apple - Ex. 1069, p. 3
`
`

`

`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`
`(Jd.; Supp. Keromytis Decl. ~ 7.)
`need not run separate lookups with the proxy and the gatekeeper.
`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 Office's overbroad construction of a "DNS
`also contradict
`The asserted references
`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 Rl 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 Rl and R2 are DNS devices that are part of the
`(See Second OA at 15-18.) Thus, this reference and others, as discussed in
`claimed DNS system.
`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"
`the
`Every claim of the '504 patent also recites, or incorporates by virtue of its dependency,
`feature of "an indication that
`the domain name service system supports establishing a secure
`(See '504 patent 55:49-60:14.)
`communication
`link."
`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
`
`Petitioner Apple - Ex. 1069, p. 4
`
`

`

`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 Dec!' ~ 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, VimetX'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
`In re Jung, 637 F.3d 1356, 1362 (Fed. Cir.
`anticipation on Patent Owner rather than the Office.
`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
`the Office has also contravened 35 U.S.c. § 132. Chester v. Miller, 906 F.2d 1574,
`in this manner,
`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").
`that
`Also,
`the Second Office Action applies a much broader construction of "indication"
`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
`(See, e.g., OA
`public key, or a certificate demonstrating authenticity of the source of the public key.
`at 34, "interpreting the claimed 'indication'
`as a provision of an address
`is reasonably broad
`id. at 42, "the release of the Cert RR [a certificate demonstrating
`consistent with the specification";
`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
`
`Petitioner Apple - Ex. 1069, p. 5
`
`

`

`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`
`disclaims merely returning an
`specification clearly and unequivocally
`The ' 504 patent
`in the prior art:
`address or a public key by describing these actions as "conventional"
`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
`(ld. at 39:50-51; Supp. Keromytis Decl. ~ 13.)
`network between the target node and the user."
`In
`"DNS proxy 2610 transmits a message to gatekeeper 2603 requesting that a
`another embodiment,
`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
`
`Petitioner Apple - Ex. 1069, p. 6
`
`

`

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

`

`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`
`features, as the Office has
`recited "indication" to include the disparaged and disclaimed conventional
`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:
`of
`Astrazeneca
`seems
`to suggest
`that clear disavowal
`requires
`an "expression
`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 ofthese other products (and processes using these products).
`Astrazeneca AB v. Mut. Pharm. Co., 384 F.3d 1333, 1340 (Fed. Cir. 2004)
`the
`(holding that
`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
`See M.P.E.P. § 2671.02 ("Before an ACP is in order, a clear
`rejected claims.
`issue should be
`developed.").
`
`8
`
`Petitioner Apple - Ex. 1069, p. 8
`
`

`

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

`

`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`
`in
`
`as the term is properly construed under the Office's broadest reasonable interpretation standard,
`light of the specification.
`the Office asserts that Solana discloses a "DNS-sec embodiment" by allegedly
`Specifically,
`incorporating by reference RFC 2065.2
`(Second OA at 19.) RFC 2065, however, was replaced and
`(See
`made obsolete by RFC 2535, which the '504 patent distinguishes as a "conventional
`scheme."
`see also '504 patent 39:34-41, "One conventional scheme that provides secure
`Ex. A-6 at 1,44-45;
`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,
`such, Solana's
`RFC 2065.
`As
`conventional
`certificateikey
`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
`See Abbott, 696 F.3d at 1149-50.
`implementations.
`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"
`claim 1 also recites, among other
`things, "a domain name service system
`Independent
`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.
`
`(see Supp. Keromytis Dec!.
`First, Solana does not explicitly disclose the recited features,
`~ 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.
`the Office cites to a portion of Solana disclosing a Directory Service (DS) that
`Specifically,
`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.l.b, VirnetX disagrees with the Office's assertion that
`Solana incorporates RFC 2065 by reference.
`
`10
`
`Petitioner Apple - Ex. 1069, p. 10
`
`

`

`Control No. 95/001,788
`Attorney Docket No. 11798.0006
`
`(Jd.)
`may be used for this purpose, the Office refers to this as the "DNS-sec embodiment of Solana."
`The Office then points to a different section in Solana describing previously implemented certificate
`structures, such as DN S-sec, where Solana cites generally to RFC 2065 in a footnote.
`(Jd., 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
`(Id. at 21-22.) Solana, however,
`"DNS-sec embodiment" discloses the above-mentioned features.
`incorporate these three RFCs because Solana merely references only RFC 2065 in a
`does not
`footnote and does not "identify with detailed particularity what specific material
`it incorporates and
`clearly indicate where that material
`isfound." Adv. Display Sys., Inc. v. Kent State Univ., 212 F.3d
`(emphases added); see also In re de Seversky, 474 F.2d 671, 674
`1272, 1282 (Fed. Cir. 2000)
`(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
`to "identifyjing] with detailed particularity what specific material
`it
`incorporates
`amounts
`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
`(See Second OA at 19-22; see also
`that
`the DS is a DNS server.
`Comments at 6, arguing that by disclosing that DNS-sec may be used in the DS, Solana "requires the
`) This is not true. The portion of Solana relied on by both the
`DS to include a DNS server ....
`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
`
`Petitioner Apple - Ex. 1069, p. 11
`
`

`

`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
`(ld.) But using the DNS-sec infrastructure to hold naming information and
`their public keys."
`certificates does not disclose storing domain names and corresponding
`network addresses or
`receiving a query for a network address.
`(Supp. Keromytis Decl, ~ 18.) Thus, even the alleged and
`improper
`incorporation of a DNS-sec infrastructure to disclose holding naming information and
`certificates still does not disclose or suggest the recited features.
`In view of the above, Solana does not disclose "a doma