Page 1 of 34
`
`VIRNETX EXHIBIT 20(cid:20)(cid:25)
`Apple v. VirnetX
`Trial IPR2015-008(cid:26)(cid:20)
`
`

`
`Control Number: 95/001,270
`
`REMARKS
`
`Claims 1, 4, 10, 12-15, 17, 20, 26, 28-31, 33, and 35 of the ‘180 Patent are under
`
`reexamination, with claims 1, 17, and 33 being independent. Claims 1, 10, 12-15, 17,26, 28-31,
`
`and 33 stand rejected. Claims 4, 20, and 35 are confirmed to be patentable.
`
`Submitted herewith is a Declaration of Jason Nieh, Ph.D., Pursuant to 37 C.F.R. § 1.132
`
`(“Nieh Dec.”) in support of the Patent Owner’s response.
`
`1.
`
`Patent Owner’s Response To the Rejection
`
`A.
`
`Introduction
`
`The Patent Owner’s invention, as defined in independent claim 1, is directed to a method
`
`for accessing a secure computer network address. The method comprises the steps of: (i)
`
`receiving a secure domain name; (ii) sending a query message to a secure domain name service,
`
`the query message requesting from the secure domain name service a secure computer network
`
`address corresponding to the secure domain name; (iii) receiving from the secure domain name
`
`service a response message containing the secure computer network address corresponding to the
`
`secure domain name; and (iv) sending an access request message to the secure computer network
`
`address using a virtual private network communication link.
`
`The patent provides a technique for establishing a virtual private network (“VPN”)
`
`communication link between a first computer and a second computer over a computer network.
`
`‘180 Patent at col. 49, 11. 57-59. To illustrate one non-limiting example, a client computer is
`
`connected to a computer network, such as the Internet.
`
`Id. at col. 50, 11. 1-4. The client
`
`computer connects to a server over a non-VPN communication link using a web browser to
`
`display a web page. Id. at col. 50, 11. 8-25.
`
`According to one variation, the web page can contain a hyperlink for selecting a VPN
`
`communication link to the server.
`
`Id. at col. 50, 11. 25-31. By selecting the hyperlink, a client
`
`can secure the communication between itself and the server.
`
`Id. at col. 51, 11. 5-14. The user
`
`need only click the hyperlink — no need to enter user identification information, passwords, or
`
`encryption keys.
`
`Id. Accordingly, in this example, establishing a secure communication link
`
`between the user and server are performed transparently to a user.
`
`Id.
`
`To support
`
`this
`
`transparency, the technique disclosed in the ‘180 Patent provides for automatically replacing the
`
`BST99 1646338-14 077580 0090
`
`Page 2 of 34
`
`-2-
`
`Page 2 of 34
`
`

`
`Control Number: 95/001,270
`
`top-level domain name of the server within the web browser with a secure top-level domain
`
`name for the server.
`
`Id. at col. 51, 11. 15-28. For example, if the top-level domain name for the
`
`server is “com,” it may be replaced with “.scom”. Id.
`
`Because a secure top-level domain name can be a non-standard domain name, a query to
`
`a standard domain name system (“DNS”) would return a message indicating that the universal
`
`resource locator (“URL”) is unknown.
`
`Id. at col. 5], 11. 28-35. Therefore, according to the
`
`patent, the query can be sent to a secure domain name service for obtaining the URL for the
`
`secure top-level domain name.
`
`Id. The secure domain name service can contain a cross-
`
`reference database of secure domain names and corresponding secure network addresses.
`
`Id. at
`
`col. 52, 11. 4-26. That is, for each secure domain name, the secure domain name service stores a
`
`computer network address corresponding to the secure domain name.
`
`Id. An entity can register
`
`a secure domain name in the secure domain name service so that a user who desires a secure
`
`communication link to the web site of the entity can automatically obtain the secure computer
`
`network address for the secure website.
`
`Id. An entity can also register several secure domain
`
`names, with each respective secure domain name representing a different priority level of access
`
`to the secure website. Id.
`
`For example, a securities trading website can provide users secure access so that a denial
`
`of service attack on the website will be ineffectual with respect to users subscribing to the secure
`
`website service.
`
`Id. Different levels of subscription can be arranged based on, for example, an
`
`escalating fee, so that a user can select a desired level of guarantee for connecting to the secure
`
`securities trading website.
`
`Id. When a user queries the secure domain name service for the
`
`secure computer network address for the securities trading website, the secure domain name
`
`service determines the particular secure computer network address based on the user's identity
`
`and the user's subscription level. Id.
`
`B.
`
`Applicable Standards for Rejection
`
`1.
`
`Applicable Standard for Rejection Under 35 U.S.C. § 102
`
`Claims 1, 10, 12-15, 17, 26, 28-31, and 33 of the ‘180 Patent stand rejected under 35
`
`U.S.C. § 102. A rejection under 35 U.S.C. § 102 requires that “each and every element as set
`
`forth in the claim is found, either expressly or inherently described,
`
`in a single prior art
`
`reference.” See MPEP § 2131, citing Verdegaa1Br0s. v. Union Oil Col. 0fCalif0rrzia, 814 F.2d
`
`BST99 1646338-14.0775 80 0090
`
`Page 3 of 34
`
`-3-
`
`Page 3 of 34
`
`

`
`Control Number: 95/001,270
`
`628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). The above-stated rejection, however, fails to
`
`meet this standard.
`
`2.
`
`Applicable Standard for Rejection Under 35 U.S.C. § 103(a)
`
`Claims 1, 10, 12-15, 17, 26, 28-31, and 33 of the ‘180 Patent also stand rejected under 35
`
`U.S.C. § l03(a).
`
`ln reconsidering the outstanding 35 U.S.C. § 103(a) rejections, the Examiner
`
`must consider any evidence supporting the patentability of the claimed invention, such as any
`
`evidence in the specification or any other evidence submitted by the Patent Owner, such as the
`
`secondary considerations of non-obviousness submitted herewith. The ultimate determination of
`
`patentability is based on the entire record, by a preponderance of evidence, which requires the
`
`evidence to be more convincing than the evidence which is sought in opposition to it. See MPEP
`
`§ 2142 (citing In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992)).
`
`Each of the rejections under 35 U.S.C. § 103(a) fails to meet these standards by a
`
`preponderance of the evidence.
`
`3.
`
`Applicable Standard for Demonstrating a Publication Date
`
`As identified below, a number of references have not been shown to qualify as prior art to
`
`the ‘180 Patent. The Office Action and the Request for Inter Partes Reexamination of Patent
`
`(“Request”) both fail to demonstrate the actual publication date of various of the relied upon
`
`references necessary to establish a prima facie showing that each reference is prior art. The
`
`Patent Owner is left to assume that the assertion that the references are prior art arises from the
`
`copyright date printed on the face of each reference. This copyright date is rgt, however, the
`
`publication date.
`
`The distinction between a publication date and a copyright date is critical. To establish a
`
`date of publication, the reference must be shown to have “been disseminated or otherwise made
`
`available to the extent that persons interested and ordinarily skilled in the subject matter or art,
`
`exercising reasonable diligence, can locate it.” In re Wyre, 655 F.2d 221, 226 (C.C.P.A. 1981).
`
`Unlike a publication date, a copyright date merely establishes “the date that the document was
`
`created or printed.” Hilgraeve, Inc. v. Symantec Corp., 271 F. Supp. 2d 964, 975 (E.D. Mich.
`
`2003).
`
`Presuming the author of a document accurately represented the date the document was
`
`created, this creation date is not evidence of any sort of publication or dissemination. Without
`
`BST99 1646338-14.077580 0090
`
`Page 4 of 34
`
`Page 4 of 34
`
`

`
`Control Number: 95/001,270
`
`more, a bald assertion of the creation of the document does not meet the “publication” standard
`
`required for a document to be relied upon as prior art.
`
`The party asserting the prior art bears the burden of establishing a date of publication.
`
`See Carella v. Starlight Archery, 804 F.2d 135, 139 (Fed. Cir. 1986) (finding that a mailer did
`
`not qualify as prior art because there was no evidence as to when the mailer was received by any
`
`of the addresses). Here,
`
`the Office bears the burden of establishing a prima facie case of
`
`unaptentability, including that the references relied upon are proper prior art. See In re Hall, 781
`
`F.2d 897 (Fed. Cir. 1986)(Affidavits on public availability of a reference were necessary for the
`
`Examiner to establish the reference to be prior art). Yet, neither the Office Action nor the
`
`Request even attempt to show that various of the references identified below were disseminated
`
`or made publicly available.
`
`Thus, the Patent Owner respectfully submits that, as demonstrated below, a number of
`
`references relied upon in the Office Action have not been shown to be prior art to the rejected
`
`claims. Accordingly,
`
`the Patent Owner respectfully requests that the rejections over these
`
`references be withdrawn.
`
`C.
`
`The Rejection of Claims Over Alleged Prior Art
`
`The outstanding rejections rely on the erroneous premise that the “secure domain name”
`
`and “secure domain name service” recited in independent claims 1, 17, and 33 of the ‘180 Patent
`
`are a standard domain name and domain name service, respectively.
`
`In the interest of brevity,
`
`the Patent Owner here reveals the fault in this premise by outlining the differences here at the
`
`outset and refers back to these statements when addressing each rejection of the Office Action
`
`below.
`
`The Request and Office Action rely on the erroneous premise that a seine domain name
`
`is a domain name that happens to correspond to a secure computer. See, e. g., Office Action at 6;
`
`Request at 15. Alternatively, the Request and Office Action rely on the faulty position that a
`
`seie domain name corresponds to an address that simply requires authorization. Request at 21.
`
`These assertions are in clear contradiction to the specification of the ‘180 Patent, which takes
`
`pains to explain that a secure domain name is different from a domain name that just happens to
`
`be associated with a secure computer or just happens to be associated with an address requiring
`
`authorization.
`
`Id.; ‘180 Patent at col. 51, 11. 18-28; Nieh Dec. at 1] 10. To illustrate, in various
`
`BST99 1646338-14.077580 0090
`
`Page 5 of 34
`
`-5-
`
`Page 5 of 34
`
`

`
`Control Number: 95/001,270
`
`implementations,
`
`the ‘I80 Patent describes that a secure domain name is a “a non—standard
`
`domain name.”
`
`‘180 Patent at col. 51, 11. 29-31; Nieh Dec. at ‘H 10. Examples of such non-
`
`standard domain names are described in Claim 11:
`
`.scom,
`
`.snet,
`
`.sorg,
`
`.sedu,
`
`.smil, and .sgov.
`
`Nieh Dec. at 1] 10. Dependent claim 2 also differentiates between a secure domain name and a
`
`non-secure domain name in reciting the step of “automatically generating a secure domain name
`
`corresponding to a non-secure domain name.” Id. To further illustrate, the ‘I80 Patent describes
`
`that “a query [with a secure domain name] to a standard domain name service (DNS) will return
`
`a message indicating that the universal resource locator (URL) is unknown.” Id.; ‘180 Patent at
`
`col. 51, 11. 28-32. Thus, the Patent Owner respectfully submits that the inventors of the ‘I80
`
`Patent acted as their own lexicographers in providing that the secure domain name recited in
`
`claims 1, 17, and 33 of the ‘I80 Patent cannot be properly read to be a domain name that just
`
`happens to be associated with a secure computer or just happens to be associated with an address
`
`requiring authorization. Nieh Dec. at 1] 10. As seen from the previous sentences, a secure
`
`domain name is different from a domain name that just happens to be associated with a secure
`
`computer or secure computer network address. For example, as pointed above, the domain name
`
`that just happens to correspond to a secure computer or a domain name that just happens to
`
`correspond to an address
`
`requiring authentication can be resolved,
`
`for example, by a
`
`conventional domain name service; whereas, as noted above, a secure domain name cannot be
`
`resolved by a conventional domain name service, for example. Id.
`
`Furthermore, the Patent Owner notes that even if the recitation “secure domain name” is
`
`defined according to the Request to mean a domain name corresponding to a secure computer or
`
`a domain name corresponding to an address requiring authorization, various of the cited
`
`documents still fail to describe or suggest this feature. Nieh Dec. at 1] 1 1. Specifically, the relied
`
`upon portions of the cited documents describe domain names of computers that do not require
`
`authorization for access.
`
`Instead, the computers (e. g., a VPN tunnel server or a PPTP server) of
`
`the cited documents are for securing a connection between a client computer and a target
`
`computer.
`
`Id. To this end,
`
`the computers (e.g., a VPN tunnel server or a PPTP server)
`
`themselves do not have a secure computer network address because they do not require
`
`authorization for access or authorization for a client computer to communicate with them.
`
`Id.
`
`Any client computer can without authorization communicate with one of these computers (e. g. a
`
`VPN tunnel server or a PPTP server); it is the target computer that may requires authorization for
`
`BST99 1646338-l4 0775800090
`
`Page 6 of 34
`
`-5-
`
`Page 6 of 34
`
`

`
`Control Number: 95/001,270
`
`access.
`
`Id. Therefore, neither the domain name of the computers (e. g., a VPN tunnel server or a
`
`PPTP server) nor their corresponding computer network address is secure — even if this term is
`
`defined according to the Request.
`
`Id. As such, these cited documents do not teach a secure
`
`computer network address or, correspondingly, a secure domain name.
`
`Similarly, the Request and Office Action rely on the faulty position that a secure domain
`
`name service is nothing more than a conventional DNS server that happens to resolve domain
`
`names of secure computers. See, e.g., Office Action at 7; Request at 15. Alternatively, the
`
`Request and Office Action also rely on the faulty position that a secure domain name service is
`
`nothing more than a conventional DNS server that happens to resolve domain names of
`
`computers that are used to establish a secure connection, such as a VPN tunnel server or a PPTP
`
`server. See, e. g., Office Action at 16; Request at 21. Again, these arguments are belied by the
`
`‘180 Patent itself. The specification of the ‘180 Patent clearly teaches that the claimed secure
`
`domain name service is unlike a conventional domain name service, which the inventors
`
`understood as including both DNS and DNS with public key security. Nieh Dec. at 1] 12; see col.
`
`51, 11. 29-45; col. 52, ll.4-26. To illustrate, the ‘180 Patent explicitly states that a secure domain
`
`name service can resolve addresses for a secure domain name; whereas, a conventional domain
`
`name service cannot resolve addresses for a secure domain name. See, ‘180 Patent at col. 51, 11.
`
`18-45 (stating “[b]ecause the secure top-level domain name is a non—standard domain name, a
`
`query to a standard domain name service (DNS) will return a message indicating that
`
`the
`
`universal resource locator (URL) is unknown”); Nieh Dec. at 1] 12. A secure domain name
`
`service is not a domain name service that resolves a domain name query that, unbeknownst to the
`
`secure domain name service, happens to be associated with a secure domain name. Nieh Dec. at
`
`1] 12. A secure domain name service of the ‘180 Patent, instead, recognizes that a query message
`
`is requesting a secure computer network address and performs its services accordingly. Nieh
`
`Dec. at 1] 12. Furthermore,
`
`in various implementations, the ‘180 Patent describes a secure
`
`domain name service as providing additional functionalities not available with a traditional
`
`domain name service, as described above in Section l.A. and in the ‘180 Patent at col. 52, ll. 4-
`
`26.
`
`Id. The ‘I80 Patent even describes the drawbacks of the conventional scheme of traditional
`
`DNS and public key security:
`
`One conventional scheme that provides secure virtual private networks
`over the lntemet provides the DNS server with the public keys of the machines
`that
`the DNS server has the addresses for. This allows hosts to retrieve
`
`BST9‘) 16946338-14.077580 0090
`
`Page 7 of 34
`
`.7.
`
`Page 7 of 34
`
`

`
`Control Number: 95/001,270
`
`automatically the public keys of a host that the host is to communicate with so
`that the host can set up a VPN without having the user enter the public key of the
`destination host. One implementation of this
`standard is presently being
`developed as part of the FreeS/WAN project (RFC 2535).
`The conventional scheme suffers from certain drawbacks. For example,
`any user can perform a DNS request. Moreover, DNS requests resolve to the same
`value for all users.
`
`‘180 Patent at col. 40, 11. 6-17; Nieh Dec. at 1] 12. Thus, the Patent Owner respectfully submits
`
`that the secure domain name service recited in claims 1, 17, and 33 of the ‘180 Patent is different
`
`from a conventional domain name service that resolves a domain name query that, unbeknownst
`
`to the secure domain name service, happens to be requesting resolution of a secure domain name.
`
`1. The Rejection of Claims 1, 10, 12, 14, 17, 26, 28, 30, 31, and 33 Under 35
`U.S.C. § l02(a) in view of Aventail Connect v3.1/V2.6 Administrator’s
`Guide (hereafter “Aventail”)
`
`Claims 1, 10, 12, 14, 17, 26, 28, 30, 31, and 33 of the ‘180 Patent stand rejected under 35
`
`U.S.C. § 102(a) as being anticipated by Aventail. The rejection is based on the reasons given on
`
`pages 12-19 of the Request, Appendix A to the Request, and the additional reasons presented on
`
`pages 6-12 of the Office Action. The Patent Owner respectfully traverses this rejection because
`
`(1') Aventail has not been shown to be prior art under § 102(a) and (ii) assuming, arguerzdo, that
`
`Aventail qualifies as prior art, Aventail has not been shown to teach, either expressly or
`
`inherently, each and every element of independent claims 1, 17, and 33. The following remarks
`
`address each of these points in turn.
`
`a) Aventail has not been shown to be prior art under § 102(a)
`
`Both the Office Action and the Request assert that Aventail was published between 1996
`
`and 1999 without any stated support. Request at 5; Office Action at 2. The Patent Owner can
`
`only presume that this assertion arises from the copyright date range printed on the face of the
`
`reference: “© 1996-1999 Aventail Corporation.” See Aventail at i. As stated in Section l.B.3.,
`
`above, this copyright date range is n_ot the publication date of Aventail and the Office Action has
`
`failed to make any showing that it is.
`
`Further, the closeness of proximity of the alleged publication date of Aventail to the April
`
`26, 2000 priority date of the ‘180 Patent raises further doubt as to the availability of Aventail as
`
`prior art. Suppose the relied upon sections of the Aventail reference were created on December
`
`BST99 1646338-14.0775 800090
`
`Page 8 of 34
`
`-3-
`
`Page 8 of 34
`
`

`
`Control Number: 95/001,270
`
`31, 1999, and the copyright date range accordingly amended to read “1996-1999.” Under these
`
`circumstances, it is possible that the document was not disseminated until after the filing date of
`
`the ‘180 Patent, a mere four months later. Under these circumstances, Aventail clearly would
`
`not be eligible to be relied upon as prior art to the ‘180 Patent.
`
`Thus, the Patent Owner respectfully submits that the Office Action has failed to establish
`
`that Aventail
`
`is prior art and requests all
`
`rejections based on Aventail be withdrawn.
`
`Nonetheless, the Patent Owner addresses Aventail below as though it is qualified prior art.
`
`b) Aventail has not been shown to teach each and every element of
`independent claims 1, 17, and 33
`
`( 1) Aventail fails to teach “a secure domain name” and “a secure
`domain name service”
`
`First, Aventail fails to describe or suggest a secure domain name and a secure domain
`
`name service, as recited in claims 1, 17, and 33. Aventail discloses a system and architecture for
`
`transmitting data between two computers using the SOCKS protocol. Nieh Dec. at 1] 14. The
`
`system routes certain, predefined network traffic from a WinSock (Windows sockets) application
`
`to an extranet (SOCKS) server, possibly through successive servers. Aventail at 7; Nieh Dec. at
`
`1] 14. Upon receipt of the network traffic, the SOCKS server transmits the network traffic to the
`
`lntemet or external network. Aventail at 7; Nieh Dec. at 1] 14. Aventail’s disclosure is limited to
`
`connections created at the socket layer of the network architecture. Nieh Dec. at 1] 14.
`
`In operation, Aventail discloses that a component of the Aventail Connect software
`
`described in the reference resides between WinSock and the underlying TCP/IP stack. Aventail
`
`at 9; Nieh Dec. at 1] 15. The Aventail Connect software is disclosed to intercept all connection
`
`requests from the user, and determines whether each request matches local, preset Criteria for
`
`redirection to a SOCKS server.
`
`See Aventail at 10; Nieh Dec. at 1] 15.
`
`If redirection is
`
`appropriate,
`
`then Aventail Connect creates a false DNS entry to return to the requesting
`
`application. See Aventail at 12; Nieh Dec. at 1] 16. Aventail discloses that Aventail Connect
`
`then forwards the destination hostname to the extranet SOCK server over a SOCKS connection.
`
`See Aventail at 12; Nieh Dec. at 1] 16. The SOCKS server performs the hostname resolution.
`
`Aventail at 12; Nieh Dec. at 1] 17. Once the hostname is resolved, the user can transmit data over
`
`BST99 1646338440775 800090
`
`Page 9 of 34
`
`Page 9 of 34
`
`

`
`Control Number: 95/001,270
`
`a SOCKS connection to the SOCKS server. Nieh Dec. at ‘ll 17. The SOCKS server, then,
`
`separately relays that transmitted data to the target.
`
`Ia’.
`
`Along with this basic operation,
`
`the Request cites to a “Proxy Chaining” and a
`
`“Mu1tiProxy” mode disclosed in Aventail. Request at 12; Aventail at 68-73.
`
`In the “Proxy
`
`Chaining” mode, Aventail discloses that a user can communicate with a target via a number of
`
`proxies such that each proxy server acts as a client to the next downstream proxy server.
`
`Aventail at 68; Nieh Dec. at ‘ll 18. As shown below, in this mode, the user does not communicate
`
`directly with the proxy servers other than the one immediately downstream from it. Aventail at
`
`68, 72; Nieh Dec. at 1] 18.
`
`PROXY EHAINING: Server! appears as as user to sr3r~.rer2.
`
` !""Ila'Il\7Il
`
`Aventail Connect
`client
`
`serverl
`(outbound)
`
`/J
`\”/\'”"
`
`5€(‘/812
`(Aventail Extr-aNet
`Server}:
`
`Destination server
`
`MULTIPRDXY: The user asutheratacates with serverz directly.
`,/—"‘« /"‘*s
`.
`—
`/
`i‘
`I
`E
`.
`:
`
`Internet
`.
`
`/"7
`
`\.—.\
`I:
`
`‘N
`
`
`
`J
`V’
`\
`in \
`Aventail Connect
`client
`
`.—z
`
`~
`server!
`(outbourrd)
`
`‘1,
`
`‘/
`
`/
`
`served’
`(Aventail Extrardet
`Server)
`
`Destrruatrorr server
`
`Aventail at 72.
`
`In the “MultiProxy” mode, Aventail discloses that the user, via Aventail
`
`Connect, connects through each successive proxy server directly. Aventail at 68; Nieh Dec. at 1]
`
`20. Regardless of whether one of these modes is enabled, the operation of Aventail Connect
`
`does not materially differ between the methods. Nieh Dec. at 1] 21.
`
`Nowhere in these teachings does Aventail teach a &cu_re domain name. The Office
`
`Action asserts that the hostname (eg., the alleged secure domain name) is secure because this
`
`traffic is routed through a SOCKS server and utilizes authentication methods and in some cases
`
`encryption. Office Action at 6. To this end, the Office Action interprets a secure domain name
`
`as a domain name associated with a secure computer.
`
`Id. As stated above at the beginning of
`
`Section l.C., which is incorporated herein by reference, this assertion is incorrect. See also Nieh
`
`Dec. at ii 22.
`
`Similarly, Aventail has not been shown to teach a gcg domain name service. The
`
`Office Action suggests that a DNS server that can resolve addresses of secure computers
`
`BST99 164633844 0775800090
`
`Page 10 of 34
`
`-10-
`
`Page 10 of 34
`
`

`
`Control Number: 95/001,270
`
`corresponds to a secure domain name service. See, Office Action at 7. This is incorrect.
`
`Aventail has not been shown to teach anything more than a conventional DNS. Nieh Dec. at 1]
`
`23. As stated above in the beginning of Section I.C., a secure domain name service is not a
`
`conventional domain name service.
`
`Id. A secure domain name service is not a domain name
`
`service that resolves a domain name query that, unbeknownst to the secure domain name service,
`
`happens to be requesting resolution of a secure domain name.
`
`Id.
`
`The Request has not shown Aventail to disclose a domain name service other than a
`
`traditional domain name service. The Request asserts that Aventail discloses two look-up
`
`services, alleged to be described on pages 8 and 12 of that reference. Request at 15. On page 8,
`
`Aventail discloses the traditional protocol for a computer to connect to a remote host. Nieh Dec.
`
`at '1] 24. On page 12, Aventail discloses “forward[ing] the host-name to the extranet (SOCKS)
`
`server [where] the SOCKS server performs the hostname resolution.” Id. Thus, Aventail has not
`
`been shown to disclose anything other than a traditional DNS.
`
`Ia’. As noted above at the outset
`
`of Section l.C., a secure domain name service is unlike a conventional domain name service.
`
`Id.
`
`A secure domain name service is not a domain name service that resolves a domain name query
`
`that, unbeknownst to the secure domain name service, happens to be requesting resolution of a
`
`secure domain name.
`
`la’.
`
`For at least these reason, Aventail fails to describe or suggest a secure domain name and
`
`a secure domain name service, as recited in claims 1, 17, and 33. Therefore, the Patent Owner
`
`respectfully requests reconsideration and withdrawal of the rejection of independent claims 1, 17,
`
`and 33 and the rejected dependent claims 10, 12, 14, 26, 28, 30, and 31.
`
`(2) Aventail fails to teach “a virtual private network link”
`
`Aventail has not been shown to teach sending an access request message to a secure
`
`computer network address using a virtual private network communication link, as recited in
`
`claims 1, 17, and 33.
`
`The links created by the systems and methods disclosed in Aventail differ from the
`
`virtual private network communication link recited in claims 1, 17, and 33. Nieh Dec. at 1] 25.
`
`First, Aventail has not been shown to demonstrate that computers connected via the Aventail
`
`system are able to communicate with each other as though they were on the same network.
`
`la’.
`
`Aventail discloses establishing point-to-point SOCKS connections between a client computer
`
`BST99 1646338—14.07758O 0090
`
`Page 11 of 34
`
`-11-
`
`Page 11 of 34
`
`

`
`Control Number: 95/001,270
`
`and a SOCKS server.
`
`Id. The SOCKS server then relays data received to the intended target.
`
`Ia’.
`
`Aventail does not disclose a virtual private network, as recited in claims 1, 17, and 33, where
`
`data can be addressed to one or more different computers across the network, regardless of the
`
`location of the computer. Id.
`
`For example, suppose two computers, A and B, reside on a public network.
`
`Id. at '1] 26.
`
`Further, suppose two computers, X and Y, reside on a private network.
`
`Id.
`
`If A establishes a
`
`VPN connection with X and Y’s network to address data to X, and B separately establishes a
`
`VPN connection with X and Y’s network to address data to Y, then A would nevertheless be able
`
`to address data to B, X, and Y without additional set up.
`
`Id. This is true because A, B, X, and Y
`
`would all be a part of the same virtual private network. Id.
`
`In contrast, suppose, according to Aventail, which only discloses communications at the
`
`socket layer, A establishes a SOCKS connection with a SOCKS server for relaying data to X,
`
`and B separately establishes a SOCKS connection with the SOCKS server for relaying data to Y.
`
`Id. at
`
`1] 27.
`
`In this situation, not only would A be unable to address data to Y without
`
`establishing a separate SOCKS connection (i.e. a VPN according to the Office Action), but A
`
`would be unable to address data to B over a secure connection.
`
`Id. This is one example of how
`
`the cited portions of Aventail fail to disclose a virtual private network. Id.
`
`Second,
`
`according to Aventail, Aventail Connect’s
`
`fundamental
`
`operation is
`
`incompatible with users transmitting data that is sensitive to network information.
`
`Id. at 1] 28.
`
`As stated above, Aventail discloses that Aventail Connect operates between the WinSock and
`
`TCP/IP layers, as depicted on page 9:
`
`krkrtndows TCPAP rappllc-.-m:.n
`(use: either *N1nSc«c.l~ 1
`W or
`\/'v'vnS;uc L: 2’)
`
`(Layured Service Pruumer)
`Aventall Connect
`
`;,;.,,E.[
`mg mshtllezd at this
`
` Mullltjrle L’SF‘s -;.-.51’:
`
`
`Phg-‘zwr: >51 fir?! «/V0: k
`
`BST99 l64633 8- l 4.0775 800090
`
`Page 12 of 34
`
`-12-
`
`Page 12 of 34
`
`

`
`Control Number: 95/001,270
`
`Aventail at 9;
`
`id. Because Aventail discloses that Aventail Connect operates between these
`
`layers,
`
`it can intercept DNS requests. Nieh Dec. at ‘ll 28. Aventail discloses that Aventail
`
`Connect intercepts certain DNS requests, and returns a false DNS response to the user if the
`
`requested hostname matches a hostname on a user-defined list.
`
`Id. Accordingly, Aventail
`
`discloses that the user will receive false network information from Aventail Connect for these
`
`hostnames.
`
`Id.
`
`If the client computer hopes to transfer to the target data that is sensitive to
`
`network information, Aventail Connect’s falsification of the network information would prevent
`
`the correct transfer of data. Id. at 1] 28. Thus, Aventail has not been shown to disclose a VPN, as
`
`recited in claims 1, 17, and 33. Id.
`
`Third, Aventail has not been shown to disclose a VPN, as recited in claims 1, 17, and 33,
`
`because computers connected according to Aventail do not communicate directly with each
`
`other.
`
`Id. at 1] 29. Aventail discloses a system where a client on a public network transmits data
`
`to a SOCKS server via a singular, point-to-point SOCKS connection at the socket layer of the
`
`network architecture.
`
`Id. The SOCKS server then relays that data to a target computer on a
`
`private network on which the SOCKS server also resides.
`
`Id. All communications between the
`
`client and target stop and start at the intermediate SOCKS server.
`
`Id. The client cannot open a
`
`connection with the target itself Therefore, one skilled in the art would not have considered the
`
`client and target to be virtually on the same private network.
`
`Id.
`
`Instead, the client computer
`
`and target computer are deliberately separated by the intermediate SOCKS server.
`
`Id.
`
`For at least the foregoing reasons, Aventail fails to describe or suggest sending an access
`
`request message to the secure computer network address using a virtual private network
`
`communication link, as recited in claims 1, 17, and 33. Therefore, the Patent Owner respectfully
`
`requests reconsideration and withdrawal of the rejection of independent claims 1, 17, and 33,
`
`along with their dependent claims 10, 12, 14, 26, 28, 30 and 31.
`
`2. The Rejection of Claims 1, 10, 12-15, 17, 26, 28-31, and 33 Under 35
`U.S.C. § 103(a) in view of Microsoft Windows NT Server, Virtual Private
`Networking: An Overview (hereafter “VPN Overview”) and RFC 1035
`
`Claims 1, 10, 12-15, 17, 26, 28-31, and 33 of the ‘ISO Patent stand rejected under 35
`
`U.S.C. § 103(a) as being unpatentable over VPN Overview in view of RFC 1035. The rejection
`
`is based on the reasons given on pages 19-25 and Appendix B of the Request. The Patent Owner
`
`respectfully traverses this rejection because (i) VPN Overview has not been shown to be prior
`
`BST99 16463 3 8- l 4 0775800090
`
`Page 13 of 34
`
`-13-
`
`Page 13 of 34
`
`

`
`Control Number: 95/001,270
`
`art, and (ii) assuming, arguerzdo, that VPN Overview qualifies as prior art, VPN Overview and
`
`RFC 1035, alone or in combination, have not been shown to teach, either expressly or inherently,
`
`each and every element of each of the independent claims 1, 17, and 33. The following remarks
`
`address each of these points in turn.
`
`a) VPN Overview has not been show to qualify as prior art.
`
`Both the Office Action and the Request assert that VPN Overview was published in 1998
`
`without any stated support. Request at 5; Office Action at 2. The Patent Owner can only
`
`presume that these assertions arise from the copyright year printed on the face of the reference.
`
`See, VPN Overview at 2. As stated in Section I.B.3., above, this copyright date range is go_t the
`
`publication date of VPN Overview and the Office Action has failed to make any showing that it
`
`is.
`
`Indeed, the document is on its face identified as nothing more than a draft. VPN Overview at
`
`1 (Stating the following: “White Paper — DR