throbber
IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`Attorney Docket No. 077580-0090
`
`)
`
`) )
`
`)
`) Examiner:
`) Andrew L. Nalven
`)
`) Group Art Unit: 3992
`)
`)
`
`In the Reexamination of:
`Edmund Munger, et al.
`
`U.S. Patent No.: 7,188,180
`Filed: November 7, 2003
`Issued: March 6, 2007
`
`For: METHOD FOR ESTABLISHING
`SECURE COMMUNICATION LINK
`BETWEEN COMPUTERS OF
`VIRTUAL PRIVATE NETWORK
`
`Reexamination Proceeding
`Control No.: 95/001,270
`Filed: December 8, 2009
`
`)
`)
`)
`)
`
`RESPONSE TO OFFICE ACTION IN REEXAMINATION
`
`Mail Stop INTER PARTES REEXAM
`Central Reexamination Unit
`
`Office of Patent Legal Administration
`United States Patent & Trademark Office
`P.O. Box 1450
`
`Alexandria, VA 22313-1450
`
`Sir:
`
`The Patent Owner hereby responds to the Office Action dated January 19, 2010 (“the
`
`Office Action”) in the Reexamination of the above-mentioned patent (“the ‘180 Patent”) having
`
`a period of response set to expire on April 19, 2010 in View of the extension of time granted on
`
`February 25, 2010.
`
`Remarks begin on page 2 of this response.
`
`BST99 l646338—l4,077580_OO90
`Page 1 of 34
`
`V
`
`Apple v. VirnetX
`Trial IPR2015-810
`
`VIRNETX EXHIBIT 2008
`Apple v. VirnetX
`Trial IPR2015-810
`
`Page 1 of 34
`
`

`
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket