`
`
`Commissioner for Patents
`United States Patent and Trademark Ofl'ice
`P.0. Box14so
`Alexandria, VA 22313—1450
`vwwuuspaoigw
`
`DO NOT USE IN PALM PRINTER
`
`(THIRD PARTY REQUESTER'S CORRESPONDENCE ADDRESS)
`
`SIDLEY AUSTIN LLP
`717 NORTH HARWOOD
`SUITE 3400
`DALLAS, TX 75201
`
`3
`
`.
`V1
`
`w
`2;; ~,
`
`_
`
`y‘l‘l,
`”may-..
`
`~
`
`,
`
`I"
`-:
`
`Transmittal of Communication to Third Party Requester
`Inter Partes Reexamination
`
`
`REEXAMlNATION CONTROL NUMBER 95/001 697.
`
`\- CiS 1‘ 00mm
`
`PATENT NUMBER 7490151.
`
`TECHNOLOGY CENTER 3999.
`
`ART UNIT 3992.
`
`Enclosed is a copy of the latest communication from the United States Patent and
`Trademark Office in the above-identified reexamination proceeding. 37 CFR 1.903.
`
`Prior to the filing of a Notice of Appeal, each time the patent owner responds to this
`communication, the third party requester of the inter partes reexamination may once file
`written comments within a period of 30 days from the date of service of the patent owner's
`
`response. This 30-day time period is statutory (35 U.S.C. 314(b)(2)), and, as such, it cannot
`be extended. See also 37 CFR 1.947.
`
`If an ex parte reexamination has been merged with the inter partes reexamination, no
`responsive submission by any ex parte third party requester is permitted.
`
`All correspondence relating to this inter partes reexamination proceeding should be
`directed to the Central Reexamination Unit at the mail, FAX, or hand-carry addresses
`given at the end of the communication enclosed with this transmittal.
`
`PTOL-2070 (Rev.O7—O4)
`
`Petitioner RPX Corporation - Ex. 1055, p. 1
`
`Petitioner RPX Corporation - Ex. 1055, p. 1
`
`

`

`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`UNITED STATES DEPARTMENT OF COMMERCE
`United States Patent and Trademark Office
`Address: COMMISSIONER FOR PATENTS
`PO. Box 1450
`Alexandria, Virginia 22313-1450
`www.usplo.g0v
`
`APPLICATION NO.
`
`FILING DATE
`
`FIRST NAMED INVENTOR
`
`ATTORNEY DOCKET NO.
`
`CONFIRMATION NO.
`
`95/001 ,697
`
`07/25/2011
`
`Edward Colby Munger
`
`41484—80130
`
`2161
`
`.
`EXAMINER
`McDermott Wlll & Emery —
`“W” _
`”63°
`600 13th Street, NW
`YIGDALL, MICHAEL]
`Washington, DC 20005—3096
`ART UNIT
`PAPER NUMBER
`
`3992
`
`MAIL DATE
`
`04/20/2012
`
`DELIVERY MODE
`
`PAPER
`
`Please find below and/0r attached an Office communication concerning this application or proceeding.
`
`The time period for reply, if any, is set in the attached communication.
`
`PTOL—90A (Rev. 04/07)
`
`Petitioner RPX Corporation - Ex. 1055, p. 2
`
`Petitioner RPX Corporation - Ex. 1055, p. 2
`
`

`

`
`
`Control No.
`
`Patent Under Reexamination
`
`
`
`OFFICE ACTION IN INTER PARTES
`
`Examiner
`
`.
`
`MUNGER ET AL.
`Art Unit
`
`RESPONSE TIMES ARE SET TO EXPIRE AS FOLLOWS:
`
`For Patent Owner's Response:
`g MONTH(S) from the mailing date of this action. 37 CFR 1.945. EXTENSIONS OF TIME ARE
`GOVERNED BY 37 CFR 1.956.
`For Third Party Requester’s Comments on the Patent Owner Response:
`30 DAYS from the date of service of any patent owner's response. 37 CFR 1.947. NO EXTENSIONS
`OF TIME ARE PERMITTED. 35 U.S.C. 314(b)(2).
`
`All correspondence relating to this inter partes reexamination proceeding should be directed to the Central
`Reexamination Unit at the mail, FAX, or hand—carry addresses given at the end of this Office action.
`
`
`
`This action is not an Action Closing Prosecution under 37 CFR 1.949, nor is it a Right of Appeal Notice under
`37 CFR 1.953.
`
`
`
`
`REEXAMINA TION
`
`
`
`
`
`-- The MAILING DA TE of this communication appears on the cover sheet with the correspondence address. --
`
`
`Responsive to the communication(s) filed by:
`Patent Owner on
`
`
`Third Party(ies) on
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`PART I. THE FOLLOWING ATTACHMENT(S) ARE PART OF THIS ACTION:
`
`1% Notice of References Cited by Examiner, PTO-892
`2.I:I Information Disclosure Citation, PTO/SB/08
`
`3!]
`PART II. SUMMARY OF ACTION:
`
`1a. IXI Claims 1-16 are subject to reexamination.
`1b. I:] Claims
`are not subject to reexamination.
`
`2. E] Claims
`3. El Claims
`4. E] Claims
`
`have been canceled.
`are confirmed. [Unamended patent claims]
`are patentable. [Amended or new claims]
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`5. El Claims fig are rejected.
`
`
`are objected to.
`I:] Claims
`6.
`[:1 are not acceptable.
`E] are acceptable
`7. CI The drawings filed on
`8. E] The drawing correction request filed on
`is:
`[:1 approved. E] disapproved.
`9. El Acknowledgment is made of the claim for priority under 35 U.S.C. 119 (a)-(d). The certified copy has:
`I:] been received.
`E] not been received.
`[I been filed in Application/Control No
`.
`
`10. D Other
`
`
`
`US. Patent and Trademark Office
`PTOL-2054 (08/06)
`
`'
`
`Paper No. 20120323
`
`Petitioner RPX Corporation - Ex. 1055, p. 3
`
`Petitioner RPX Corporation - Ex. 1055, p. 3
`
`

`

`Application/Control Number: 95/001,697 and 95/001,714
`Art Unit: 3992
`
`Page 2
`
`DETAILED ACTION
`
`1.
`
`A first request for inter partes reexamination of claims 1-16 of US. Patent No. 7,490,151
`
`(“the ‘151 patent”) was filed on July 25, 2011 and assigned Control No. 95/001,697 (“the ‘ 1697
`
`proceeding”). An order granting the request was mailed on October 21, 2011.
`
`A second request for inter partes reexamination of claims 1-16 of the ‘151 patent was
`
`filed on August 16, 2011 and assigned Control No. 95/001,714 (“the ‘1714 proceeding”). An
`
`order granting the request was mailed on October 31, 2011.
`
`A decision merging the ‘1697 and ‘1714 proceedings was mailed on March 15, 2012.
`
`Prior Art Cited in the Merged Proceedings
`
`2.
`
`The following patents and printed publications were cited in the ‘1697 and ‘ 1714
`
`proceedings:
`
`Aventail Connect v3.1/v2. 6 Administrator’s Guide, 1999 (“Aventail Connect v3 .1”).
`
`Aventaz'l Connect v3.01/v2.51 Administrator’s Guide, 1999 (“Aventail Connect v3.01”).
`
`Aventail AutoSOCKS v2.1 Administration and User’s Guide, 1997 (“Aventail
`
`AutoSOCKS”).
`
`Wang, “Core Network Architecture Recommendations for Access to Legacy Data
`
`Networks over ADSL,” Broadband Forum Technical Report TR-025, September 1999
`
`(“Wang”)-
`
`U.S. Patent No. 6,496,867 to Beser et al. (“Beser”).
`
`Kent et al., “Security Architecture for the Internet Protocol,” Network Working Group
`
`RFC 2401, November 1998 (“Kent”).
`
`Petitioner RPX Corporation - Ex. 1055, p. 4
`
`Petitioner RPX Corporation - Ex. 1055, p. 4
`
`

`

`Application/Control Number: 95/001,697 and 95/001,714
`Art Unit: 3992
`
`Page 3
`
`BinGO! User’s Guide: Installation and Configuration and Extended Feature Reference,
`
`March 1999 (“BinGO”).
`
`Kiuchi, Takahiro and Shigekoto Kaihara, “C-HTTP — The Development of a Secure,
`
`Closed HTTP-based Network on the Internet,” Proceedings of the SNDSS, 1996 (“Kiuchi”).
`
`US. Patent No. 5,898,830 to Wesinger, Jr. et a1. (“Wesinger”).
`
`US. Patent No. 6,182,141 to Blum et a1. (“Blum”).
`
`US. Patent No. 6,119,234 to Aziz et a1. (“Aziz”).
`
`Edwards, Nigel and Owen Rees, “High Security Web Servers and Gateways,” Computer
`
`Networks and ISDN Systems 29, September 1997, pages 927-938 (“Edwards”).
`
`Martin, David M., “A Framework for Local Anonymity in the Internet,” Technical
`
`Report, Boston University, 21 February 1998 (“Martin”).
`
`Rejections Proposed in the Requests
`
`3.
`
`The following rejections of the claims were proposed in the ‘1697 and ‘ 1714 requests for
`
`
`
`inter partes reexamination:
`
`
`Issue 1: Claims 1-16 are rejected as anticipated under 35 U.S.C. § 102(b) based on
`
`Aventail Connect v3.01 (see the ‘1697 request, pages 21-50 and Ex. C1).
`
`
`Issue 2: Claims 1—16 are rejected as anticipated under 35 U.S.C. § 102(b) based on
`
`Aventail AutoSOCKS (see the ‘1697 request, pages 51-81 and Ex. C2).
`
`
`Issue 3: Claims 1-16 are rejected as anticipated under 35 U.S.C. § 102(a) based on
`
`BinGO (see the ‘1697 request, pages 82-117 and Ex. C3).
`
`
`Issue 4: Claims 1-16 are rejected as obvious under 35 U.S.C. § 103(a) based on Beser in
`
`View of Kent (see the ‘ 1697 request, pages 118-150 and Ex. C4).
`
`PetitiOner RPX Corporation - Ex. 1055, p. 5
`
`Petitioner RPX Corporation - Ex. 1055, p. 5
`
`

`

`Application/Control Number: 95/001,697 and 95/001,714
`Art Unit: 3992
`
`Page 4
`
`
`Issue 5: Claims 1-5, 7—11 and 13-16 are rejected as anticipated under 35 U.S.C. § 102(a)
`
`based on Wang (see the ‘ 1697 request, pages 151—183 and Ex. C5).
`
`
`Issue 6: Claims 6 and 12 are rejected as obvious under 35 U.S.C. § 103(a) based on
`
`Wang in View of Beser (see the ‘1697 request, pages 183-184 and Ex. C5).
`
`
`Issue 7: Claims 1-4, 6-10 and 12-16 are rejected as anticipated under 35 U.S.C. § 102(b)
`
`based on Kiuchi (see the ‘ 1714 request, page 19 and Ex. E-l).
`
`
`Issue 8: Claims 5 and 11 are rejected as obvious under 35 U.S.C. § 103(a) based on
`
`Kiuchi in view of Martin (see the ‘ 1714 request, page 19 and Ex. E-l).
`
`
`Issue 9: Claims 1—4, 6-10 and 12-16 are rejected as anticipated under 35 U.S.C. § 102(e)
`
`based on Wesinger (see the ‘ 1714 request, page 19 and Ex. E—2).
`
`
`Issue 10: Claims 5 and 11 are rejected as obvious under 35 U.S.C. § 103(a) based on
`
`Wesinger in view of Martin (see the ‘ 1714 request, page 19 and Ex. E-2).
`
`
`Issue 11: Claims 1, 7 and 13 are rejected as anticipated under 35 U.S.C. § 102(6) based
`
`on Blum (see the ‘1714 request, page 20 and Ex. E-3).
`
`
`Issue 12: Claims 1-4, 6-10 and 12-16 are rejected as obvious under 35 U.S.C. § 103(a)
`
`based on Aziz in View of Edwards (see the ‘1714 request, page 20 and Ex. E—4).
`
`
`Issue 13: Claims 5 and 11 are rejected as obvious under 35 U.S.C. § 103(a) based on
`
`Aziz in View of Edwards and Martin (see the ‘ 1714 request, page 20 and Ex. E-4).
`
`
`Issue 14: Claims 1-4, 6-10 and 12-16 are rejected as obvious under 35 U.S.C. § 103(a)
`
`based on Kiuchi in View of Edwards (see the ‘ 1714 request, page 20 and Ex. E-5).
`
`
`Issue 15: Claims 5 and 11 are rejected as obvious under 35 U.S.C. § 103(a) based on
`
`Kiuchi in view of Edwards and Martin (see the ‘ 1714 request, page 20 and Ex. E-S).
`
`Petitioner RPX Corporation - Ex. 1055, p. 6
`
`Petitioner RPX Corporation - Ex. 1055, p. 6
`
`

`

`Application/Control Number: 95/001,697 and 95/001,714
`Art Unit: 3992
`'
`
`Page 5
`
`'
`
`
`Issue 16: Claims 1-4, 6-10 and 12-16 are rejected as obvious under 35 U.S.C. § 103(a)
`
`based on Wesinger in view of Edwards (see the ‘ 1714 request, page 21 and Ex. E-6).
`
`Issue 17: Claims 5 and 11 are rejected as obvious under 35 U.S.C. § 103(a) based on
`
`Wesinger in view of Edwards and Martin (see the ‘1714 request, page 21 and Ex. E—6).
`
`Statutory Basisfor Rejections
`
`4.
`
`The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form
`
`the basis for the rejections under this section made in this Office action:
`
`A person shall be entitled to a patent unless —
`
`(a) the invention was known or used by others in this country, or patented or
`described in a printed publication in this or a foreign country, before the
`invention thereof by the applicant for a patent.
`
`(b) the invention was patented or described in a printed publication in this or a
`foreign c0untry or in public use or on sale in this country, more than one year
`prior to the date of application for patent in the United States.
`
`(e) the invention was described in (1) an application for patent, published
`under section 122(b), by another filed in the United States before the
`invention by the applicant for patent or (2) a patent granted on an application
`for patent by another filed in the United States before the invention by the
`applicant for patent, except that an international application filed under the
`treaty defined in section 351(a) shall have the effects for purposes of this
`subsection of an application filed in the United States only if the international
`application designated the United States and was published under Article
`21(2) of such treaty in the English language.
`
`5.
`
`The following is a quotation of 35 U.S.C. § 103(a) which forms the basis for all
`
`obviousness rejections set forth in this Office action:
`
`(a) A patent may not be obtained though the invention is not identically
`disclosed or described as set forth in section 102 of this title, if the differences
`between the subject matter sought to be patented and the prior art are such that
`the subject matter as a whole would have been obvious at the time the
`
`Petitioner RPX Corporation - Ex. 1055, p. 7
`
`Petitioner RPX Corporation - Ex. 1055, p. 7
`
`

`

`Application/Control Number: 95/001,697 and 95/001,7l4
`
`Page 6
`
`Art Unit: 3992
`
`invention was made to a person having ordinary skill in the art to which said
`subject matter pertains. Patentability shall not be negatived by the manner in
`which the invention was made.
`
`Rejections Adopted
`
`6.
`
`
`Issue 1: The rejection of claims 1-16 as anticipated under 35 U.S.C. § 102(b) based on
`
`Aventail Connect v3.01 is ADOPTED essentially as proposed in the request (see the ‘ 1697
`
`request, pages 21-50 and Ex. Cl) and is set forth' below.
`
`
`Claim 1
`
`A data processing device, comprising
`memory storing a domain name
`server (DNS) proxy module that
`intercepts DNS requests sent by a
`client and, for each intercepted DNS
`request, performs the steps of:
`
`Aventail Connect v3.01 teaches a computer system
`comprising a proxy module that intercepts network
`traffic to and from a client application (see, e. g., page 7,
`“Aventail Connect is the client component of the
`Aventail ExtraNet Center.
`You can use Aventail
`
`Connect as a simple proxy client for managed outbound
`access, and for secure inbound access. When you run
`Aventail Connect on your system, it automatically
`routes appropriate network traffic from a WinSock
`application to an extranet (SOCKS) server, or through
`successive servers.
`Aventail Connect is designed to
`run transparently on each workstation, without adding
`overhead to the user’s desktop”). The intercepted
`network traffic includes DNS requests sent from the
`client application (see, e. g., page 1 1, “The application
`does a DNS lookup to convert the hostname to an IP
`address. If the application already knows the IP address,
`this entire step is skipped. Otherwise, Aventail Connect
`does the following: ....”).
`
`(i) determining whether the
`intercepted DNS request corresponds
`to a secure server;
`
`Aventail Connect v3.01 teaches determining whether to
`redirect and/or encrypt a connection (see, e. g., page 10,
`“When the Aventail Connect LSP receives a connection
`
`request, it determines whether or not the connection
`needs to be redirected (to an Aventail ExtraNet Server)
`and/or encrypted (in SSL).”). The determination is
`based on rules in a configuration file (see, e. g., page 9,
`“Aventail Connect can change data (compressing it or
`
`Petitioner RPX Corporation - Ex. 1055, p. 8
`
`
`
`Petitioner RPX Corporation - Ex. 1055, p. 8
`
`

`

`Application/Control Number: 95/001,697 and 95/001,714
`Art Unit: 3992
`
`Page 7
`
`(ii) when the intercepted DNS request
`does not correspond to a secure
`server, forwarding the DNS request to
`a DNS function that returns an IP
`
`address of a nonsecure computer, and
`
`(iii) when the intercepted DNS
`request corresponds to a secure
`server, automatically initiating an
`encrypted channel between the client
`and the secure server.
`
`encrypting it, for example) before routing it to the
`TCP/IP stack for transport over the network. The
`routing is determined by the rules described in the
`configuration file”). Aventail Connect v3.01 further
`teaches determining whether the DNS request
`corresponds to a rule fora secure server (see, e.g., pages
`11-12, “If the destination hostname matches a
`redirection rule domain name (i.e., the host is part of a
`domain we are proxying traffic to) then Aventail
`Connect creates a false DNS entry (HOSTENT) that it
`can recognize during the connection request. Aventail
`Connect will forward the hostname to the extranet
`(SOCKS) server in step 2 and the SOCKS server
`performs the hostname resolution”).
`
`Aventail Connect v3.01 teaches forwarding the
`intercepted DNS request to a standard DNS function
`when the query does not correspond to a rule for a
`secure server (see, e. g., page 11, “If the hostname
`matches a local domain string or does not match a
`redirection rule, Aventail Connect passes the name
`resolution query through to the TCP/IP stack on the
`local workstation. The TCP/1P stack performs the
`lookup as if Aventail Connect were not running”).
`
`Aventail Connect V3.01 teaches automatically
`establishing an encrypted tunnel (see, e.g., page 7,
`“Aventail Connect can establish an encrypted tunnel
`automatically”), and further teaches establishing an
`encrypted connection when the intercepted DNS request
`corresponds to a rule for a secure server (see, e.g., page
`12, “If the request contains a false DNS entry (from step
`1), it will be proxied. When the SOCKS negotiation
`is completed, Aventail Connect notifies the application.
`From the application’s point of View, the entire SOCKS
`negotiation, including the authentication negotiation, is
`merely the TCP handshaking.
`If an encryption
`module is enabled and selected by the SOCKS server,
`Aventail Connect encrypts the data on its way to the
`server on behalf of the application. If data is being
`returned, Aventail Connect decrypts it so that the
`application sees cleartext data”).
`
`Petitioner RPX Corporation - Ex. 1055, p. 9
`
`Petitioner RPX Corporation - Ex. 1055, p. 9
`
`

`

`Application/Control Number: 95/001,697 and 95/001,714
`
`Page 8
`
`Art Unit: 3992
`
`
`Claim 2
`
`The data processing device of claim
`1, wherein step (iii) comprises the
`steps of:
`
`(a) determining whether the client is
`authorized to access the secure server;
`and
`
`(b) when the client is authorized to
`access the secure server, sending a
`request to the secure server to
`establish an encrypted channel
`between the secure server and the
`client.
`
`Aventail Connect v3.01 teaches determining whether the
`client application is authorized to access the secure
`server (see, e. g., page 12, “When the connection is
`completed, Aventail Connect begins the SOCKS
`negotiation. It sends the list of authentication methods
`enabled in the configuration file. Once the server selects
`an authentication method, Aventail Connect executes the
`specified authentication processing,” and see, e.g., page
`~73, “User authentication and encryption on the Aventail
`ExtraNet Server require all users to use Aventail
`Connect to authenticate and encrypt their sessions before
`any connection to the internal private network(s). For
`this example, the Aventail ExtraNet Server encrypts all
`sessions with SSL.”).
`
`Aventail Connect v3.01 teaches establishing the
`encrypted connection if the client application is
`authorized to access the secure server (see, e.g., pages
`72-73, “The mobile user workstations connected to the
`public Internet are the client workstations, onto which,
`Aventail Connect will be deployed. Due to the routing
`restrictions described above, these clients will have no
`network access beyond the Aventail ExtraNet Server
`unless they are running Aventail Connect. Depending
`on the security policy and the Aventail ExtraNet Server
`configuration, Aventail Connect will automatically
`proxy their allowed application traffic into the private
`network. In this situation, Aventail Connect will
`forward traffic destined for the private internal network
`to the Aventail ExtraNet Server. Then, based on the
`security policy, the Aventail ExtraNet Server will proxy
`mobile user traffic into the private network but only to
`those resources allowed”).
`I
`
`
`Claim 3
`
`The data processing device of claim
`2, wherein step (iii) further comprises
`the step of:
`
`Aventail Connect v3.01 implicitly teaches returning a
`host unknown error message when the client application
`is not authorized to access the secure server.
`
`(c) when the client is not authorized
`
`Specifically, Aventail Connect v3.01 describes the use
`of the SOCKS version 5 and DNS protocols (see, e. g.,
`
`Petitioner RPX Corporation - Ex. 1055, p. 10
`
`Petitioner RPX Corporation - Ex. 1055, p. 10
`
`

`

`Application/Control Number: 95/001 ,697 and 95/001,714
`Art Unit: 3992
`
`Page 9
`
`to access the secure server, returning
`a host unknown error message to the
`client.
`
`
`Claim 4
`
`The data processing device of claim
`3, wherein the client comprises a web
`browser into which a user enters a
`
`URL resulting in the DNS request.
`
`
`Claim 5
`
`The data processing device of claim
`1, wherein automatically initiating the
`encrypted channel between the client
`and the secure sewer comprises
`establishing an IF address hopping
`scheme between the client and the
`secure server.
`
`page 7, “Aventail Connect automates the
`‘socksification’ of Transmission Control
`Protocol/Internet Protocol (TC—P/IP) client applications,
`making it simple for workstations to take advantage of
`the SOCKS v5 protocol,” and see, e.g., page 11, “The
`application does a DNS lookup to convert the hostname
`to an IP address. If the application already knows the IP
`address, this entire step is skipped. Otherwise, Aventail
`Connect does the following: ....”). Returning a host
`unknown error message when the client application is
`not authorized to access the secure server is inherent to
`these protocols (see the ‘ 1697 request, pages 28-29 and
`Ex. C1 at pages 10-13).
`
`Aventail Connect v3.01 teaches that the client
`application sending the DNS request comprises a Web
`browser (see, e. g., page 65, “When users need to access
`Web pages behind an Aventail ExtraNet Server, you
`must properly configure the Web browser.
`There are
`two approaches to configuring Aventail Connect for use
`with a Web browser,” and see, e.g., page 8, “Windows
`TCP/IP networking applications (such as telnet, e-mail,
`Web browsers, and ftp) use WinSock (Windows
`Sockets) to gain access to networks or the lntemet.
`The application executes a Domain Name System
`(DNS)_lookup to convert the hostname into an Internet
`Protocol (IP) address”).
`
`Aventail Connect V3.01 teaches establishing IP address
`hopping schemes between the client application and the
`secure server in the form of Aventail MultiProxy and
`proxy chaining (see, e. g., page 59, “The Aventail
`MultiProxy feature allows Aventail Connect to traverse
`multiple firewalls by making connections through
`successive proxy servers. Aventail Connect makes a
`connection with each proxy server individually. Each
`proxy server forms a link in a chain that connects
`Aventail Connect to the final destination,” and see, e. g.,
`
`Petitioner RPX Corporation - Ex. 1055, p. 11
`
`Petitioner RPX Corporation - Ex. 1055, p. 11
`
`

`

`Application/Control Number: 95/001,697 and 95/001,714
`Art Unit: 3992
`
`Page 10
`
`
`Claim 6
`
`The data processing device of claim
`1, wherein automatically initiating the
`encrypted channel between the client
`and the secure server avoids sending
`a true IP address of the secure server
`
`to the client.
`
`
`Claim 7
`
`A computer readable medium storing
`a domain name server (DNS) proxy
`module comprised of computer
`readable instructions that, when
`executed, cause a data processing
`device to perform the steps of:
`
`(i) intercepting a DNS request sent by
`a client;
`
`page 63, “Proxy chaining is an Aventail ExtraNet Server
`feature. With proxy chaining, Aventail ExtraNet
`Servers forward connections for certain destinations to
`
`other proxy servers”).
`
`Aventail Connect v3.01 implicitly teaches avoiding
`sending a true IP address of the secure server to the
`client application because the encrypted connection is
`routed through a proxy (see, e.g., page 72, “Therefore,
`no direct'network connections between the public LAN
`and the private LAN can be created without being
`securely proxied through the Aventail ExtraNet Server,”
`and see the ‘1697 request, pages 31-32 and Ex. C1 at
`pages 15-16).
`
`Aventail Connect v3.01 teaches a computer system
`comprising a proxy module that intercepts network
`traffic to and from a client application (see, e.g., page 7,
`“Aventail Connect is the client component of the
`Aventail ExtraNet Center. ... You can use Aventail
`Connect as a simple proxy client for managed outbound
`access, and for secure inbound access. When you run
`Aventail Connect on your system, it automatically
`routes appropriate network traffic from a WinSock
`application to an extranet (SOCKS) server, or through
`successive servers.
`Aventail Connect is designed to
`run transparently on each workstation, without adding
`overhead to the user’s desktop”). The intercepted
`network traffic includes DNS requests sent from the
`client application (see, e. g., page 11, “The application
`does a DNS lookup to convert the hostname to an IP
`address. If the application already knows the IP address,
`this entire step is skipped. Otherwise, Aventail Connect
`does the following: ....”).
`
`(ii) determining whether the
`intercepted DNS request corresponds
`to a secure server;
`
`Aventail Connect v3.01 teaches determining whether to
`redirect and/or encrypt a connection (see, e.g., page 10,
`“When the Aventail Connect LSP receives a connection
`
`Petitioner RPX Corporation - Ex. 1055, p. 12
`
`Petitioner RPX Corporation - Ex. 1055, p. 12
`
`

`

`Application/Control Number: 95/001,697 and 95/001,714
`Art Unit: 3992
`
`‘
`
`Page 11
`
`request, it determines Whether or not the connection
`needs to be redirected (to an Aventail ExtraNet Server)
`and/or encrypted (in SSL).”). The determination is
`based on rules in a configuration file (see, e.g., page 9,
`“Aventail Connect can change‘data (Compressing it or
`encrypting it, for example) before routing it to the
`TCP/IP stack for transport over the network. The
`routing is determined by the rule's described in the
`configuration file”). Aventail Connect v3.01 further
`teaches determining whether the DNS request
`corresponds to a rule for a secure server (see, e. g., pages ‘
`11-12, “If the destination hostname matches a
`redirection rule domain name (i.e., the host is part of a
`domain we are proxying traffic to) then Aventail
`Connect creates a false DNS entry (HOSTENT) that it
`can recognize during the connection request. Aventail
`Connect will forward the hostname to the extranet
`(SOCKS) server in step 2 and the SOCKS server
`performs the hostname resolution”).
`
`Aventail Connect V3.01 teaches forwarding the
`intercepted DNS request to a standard DNS fimction
`when the query does not correspond to a rule for a
`secure server (see, e.g., page 11, “If the hostname
`matches a local domain string or does not match a
`redirection rule, Aventail Connect passes the name
`resolution query through to the TCP/IP stack on the
`local workstation. The TCP/1P stack performs the
`lookup as if Aventail Connect were not running”).
`
`Aventail Connect v3 .01 teaches automatically
`establishing an encrypted tunnel (see, e. g., page 7,
`“Aventail Connect can establish an encrypted tunnel
`automatically”), and further teaches establishing an
`encrypted connection when the intercepted DNS request
`corresponds to a rule for a secure server (see, e. g., page
`12, “If the request contains a false DNS entry (fr0m step
`1), it will be proxied. When the SOCKS negotiation
`is completed, Aventail Connect notifies the application.
`From the application’s point of View, the entire SOCKS
`negotiation, including the authentication negotiation, is
`merely the TCP handshaking.
`If an encryption
`module is enabled and selected by the SOCKS server,
`Aventail Connect encrypts the'data on its way to the
`
`Petitioner RPX Corporation - Ex. 1055, p. 13
`
`(iii) when the intercepted DNS
`request does not correspond to a
`secure server, forwarding the DNS
`request to a DNS function that returns
`an IP address of a nonsecure
`
`computer; and
`
`(iv) when the intercepted DNS
`request corresponds to a secure
`server, automatically initiating an
`encrypted channel between the client
`and the secure server.
`
`Petitioner RPX Corporation - Ex. 1055, p. 13
`
`

`

`Application/Control Number: 95/001,697 and 95/001,714
`Art Unit: 3992
`
`Page 12
`
`server on behalf of the application. If data is being
`returned, Aventail Connect decrypts it so that the
`application sees cleartext data”).
`
`
`Claim 8
`
`The computer readable medium of
`claim 7, wherein step (iv) comprises
`the steps of
`
`(a) determining whether the client is
`authorized to access the secure server,
`and
`
`(b) when the client is authorized to
`access the secure server, sending a
`request to the secure sewer to
`establish an encrypted channel
`between the secure sewer and the
`client.
`
`
`
`Aventail Connect v3.01 teaches determining whether the
`client application is authorized to access the secure
`server (see, e.g., page 12, “When the connection is
`completed, Aventail Connect begins the SOCKS
`negotiation. It sends the list of authentication methods
`enabled in the configuration file. Once the server selects
`an authentication method, Aventail Connect executes the
`specified authentication processing,” and see, e.g., page
`73, “User authentication and encryption on the Aventail
`ExtraNet Server require all users to use Aventail
`Connect to authenticate and encrypt their sessions before
`any connection to the internal private network(s). For
`this example, the Aventail ExtraNet Server encrypts all
`sessions with SSL.”).
`
`Aventail Connect v3.01 teaches establishing the
`encrypted connection if the client application is
`authorized to access the secure server (see, e.g., pages
`72—73, “The mobile user workstations connected to the
`public Internet are the client workstations, onto which,
`Aventail Connect will be deployed. Due to the routing
`restrictions described above, these clients will have no
`network access beyond the Aventail ExtraNet Server .
`unless they are running Aventail Connect. Depending
`on the security policy and the Aventail ExtraNet Server
`configuration, Aventail Connect will automatically
`proxy their allowed application traffic into the private
`network. In this situation, Aventail Connect will
`forward traffic destined for the private internal network
`to the Aventail ExtraNet Server. Then, based on the
`security policy, the Aventail ExtraNet Server will proxy
`mobile user traffic into the private network but only to
`those resources allowed”).
`
`Petitioner RPX Corporation - Ex. 1055, p. 14
`
`
`
`Petitioner RPX Corporation - Ex. 1055, p. 14
`
`

`

`Application/Control Number: 95/001,697 and 95/001,714
`Art Unit: 3992
`
`Page 13
`
`
`Claim 9
`
`The computer readable medium of
`claim 8, wherein step (iv) further
`comprises the step of:
`
`(c) when the client is not authorized
`to access the secure server, returning
`a host unknown error message to the
`client.
`
`Claim 10
`
`The computer readable medium of
`claim 9, wherein the client comprises
`a web browser into which a user
`
`enters a URL resulting in the DNS
`request.
`
`Aventail Connect v3.01 implicitly teaches returning a
`host unknown error message when the client application
`is not authorized to access the secure server.
`Specifically, Aventail Connect v3.01 describes the use
`of the SOCKS version 5 and DNS protocols (see, e.g.,
`page 7, “Aventail Connect automates the
`‘socksification’ of Transmission Control
`Protocol/Internet Protocol (TCP/IP) client applications,
`making it simple for workstations to take advantage of
`the SOCKS v5 protocol,” and see, e.g., page 11, “The
`application does a DNS lookup to convert the hostname
`to an IP address. If the application already knows the IP
`address, this entire step is skipped. Otherwise, Aventail
`Connect does the following: ....”). Returning a host
`unknown error message when the client application is
`not authorized to access the secure server is inherent to
`these protocols (see the ‘ 1697 request, pages 38-40 and
`Ex. C1 at pages 26-29).
`
`Aventail Connect v3.01 teaches that the client
`application sending the DNS request comprises a Web
`browser (see, e.g., page 65, “When users need to access
`Web pages behind an Aventail ExtraNet Server, you
`must properly configure the Web browser.
`There are
`two approaches to configuringAventail Connect for use
`with a Web browser,” and see, e. g., page 8, “Windows
`TCP/IP networking applications (such as telnet, e—mail,
`Web browsers, and ftp) use WinSock (Windows
`Sockets) to gain access to networks or the Internet.
`The application executes a Domain Name System
`(DNS) lookup to convert the hostname into an Internet
`Protocol (IP) address”).
`
`Claim 11
`
`The computer readable medium of
`claim 7, wherein automatically
`initiating the encrypted channel
`
`Aventail Connect v3.01 teaches establishing IP address
`hopping schemes between the client application and the
`secure server in the form of Aventail MultiProxy and
`
`Petitioner RPX Corporation - Ex. 1055, p. 15
`
`Petitioner RPX Corporation - Ex. 1055, p. 15
`
`

`

`Application/Control Number: 95/001,697 and 95/001,714
`Art Unit: 3992
`
`Page 14
`
`between the client and the secure
`
`sewer comprises establishing an IP
`address hopping scheme between the
`client and the secure server.
`
`Claim 12
`
`The computer readable medium of
`claim 7, wherein automatically
`initiating the encrypted channel
`between the client and the secure
`
`server avoids sending a true IP
`address of the secure server to the
`client.
`
`Claim 13
`
`A computer readable medium storing
`a domain name server (DNS) module
`comprised of computer readable
`instructions that, when executed,
`cause a data processing device to
`perform the steps of:
`
`
`
`proxy chaining (see, e.g., page 59, “The Av