Attorney Docket No. 41484-80130
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`In re Inter Par-res Reexamination of
`
`)
`
`US. PatentNo_ 7,490,151
`Edmund Colby Monger et al.
`Issued: Febnmy 10, 2009
`For:
`ESTABLISHMENT OF A SECURE
`COMMUNICATION LINK BASED
`ON A DOMAIN NAME SERVICE
`
`(DNS) REQUEST
`
`; Control No.: 95/001,714/001,697
`) Gmp A“ Um“
`3992
`; Exammer: Mlchael J. Yigdall
`) mam“ N04 3423s 2161
`)
`
`COMMENTS BY THIRD PARTY REQUESTER PURSUANT TO 37 C.F.R. § 1.947
`
`Mail Stop Inter Partes Reexam
`Commissioner for Patents
`PO. Box 1450
`
`Alexandria, VA 22313-1450
`
`Sir:
`
`On July 20, 2012, Patent Owner filed an overlength response (“Response”) to the April 20,
`
`2012 Office action (“Office Action”) and a petition under 37 C.F.R. § 1.183 seeking waiver of the
`
`page limit for that response. On September 25, 2012, the Office granted Patent Owner’s petition,
`
`which set the date for a response by the Requestor for 30 days from the date of decision, which fell
`
`on Thursday, October 25, 2012. Third Party Requester believes that no fee is due in connection
`
`with the present response. However, any fee required for entry or consideration of this paper may
`
`be debited from Deposit Account No. 18-1260.
`
`-
`
`-
`
`A table of contents is provided at pages ii to iv. Requester submits the table of
`
`contents is not counted against the page limits applicable to this response. Should
`
`the Office determine otherwise, the Office is requested to disregard the table of
`
`contents.
`
`The response to the Patent Owner Comments begins on page 1.
`
`Petitioner RPX Corporation - Ex. 1066, p. Cover Page
`
`Petitioner RPX Corporation - Ex. 1066, p. Cover Page
`
`

`

`Control No. 95/001,714; 95/001,697
`Comments of the Requester on the Patent Owner Response
`
`TABLE or CONTENTS
`
`I.
`
`11.
`
`t.In...IdIIIIIIII.IIIIIIIIIIIIn.DI.DUII.IIIDIII.IIIIII!IIIIIDIIIDUI.OIIIIIIIIIIIIIIIIIII.III!IOIIIII!IIIIIDUUOOOIIIIIIIIII 1
`
`Response to Patent Owner Contentions on Status of References as PriorArt. 1
`
`III.
`
`The Rejections 0f the Claims Were Proper And Should Be Maintained
`
`3
`
`A. Response to Patent Owner’s Arguments Regarding the Rejection of Claims 1-16
`Under 35 U.S.C. § 102(b) Based on Aveutail Connect v3.01 (Issue No.
`1.
`Independent Claim 1 (Issue No. 1) ........................................................................ ..4
`a. Aventaii Describes “Determining Whether the Intercepted DNS Request
`4
`Corresponds to the Secure Server.”...................... ..
`Independent Claims 7 and 13 (Issue No. 1) ........................................................... ..9
`2.
`3. Dependent Claims 2, 8, and 14 (Issue No. 1) ........................................................ ..9
`4. Dependent Claims 3, 9, and 15 (Issue No. 1) ........................................................11
`5. Dependent Claims 4, 10, and 16 (Issue No. I) ...................................................... 12
`6. Dependent Claims 5 and 11 (Issue No. 1) ........................................................... .. 12
`7. Dependent Claims 6 and 12 (Issue No. 1) ........................................................... .. 13
`
`B. Response to Patent Owner’s Arguments Regarding the Rejection of Claims 1-16
`Based on Avem‘ailAutoSOCKSAdministrator 19 Guide (Issue No.
`14
`
`C. Response to Patent Owner’s Arguments Regarding the Rejection of Claims 1-4, 6-
`8, 10, 12, 13 and 18 Based on Beser in View of Kent (Issue
`14
`8.
`Independent Claim 1 .............................................................................................. 14
`b. Beser and Kent Disclose a DNS Proxy Module that Intercepts DNS Requests Sent
`by a Client...............
`Automatically Initiating an Encrypted
`d. Beser in View of
`Channel Between the Client and the Secure Server When the Request Corresponds
`to a Secure
`19
`
`16
`
`Independent Claim 7 ............................................................................................ ..21
`1.
`Independent Claim 13 .......................................................................................... ..21
`2.
`3. Dependent Claims 2, 8, and 14 ............................................................................ ..22
`4. Dependent Claims 4, 10, and 16 .......................................................................... ..23
`5. Dependent Claims 5 and 11 ................................................................................. .. 24
`6. Dependent Claims 6 and 12 ................................................................................. .. 25
`
`D. R ponse to Patent Owner’s Arguments Regarding the Rejection of Claims 1—16
`Under 35 U.S.C. §102(a) Based on BinGO (Issue
`25
`1. BinGO Expressly Incorporates BinGO EFR ......................................................... 25
`2.
`Independent Claim 1 ............................................................................................ .. 26
`3.
`Independent Claims 7 and 13 .............................................................................. .. 33
`4. Dependent Claims 2, 8, and 14 ............................................................................ .. 34
`5. Dependent Claims 4, 10, and 16 .......................................................................... .. 35
`6. Dependent Claims 5 and 11 ................................................................................. .. 35
`7. Dependent Claims 6 and 12 ................................................................................... 36
`
`E. There are No Secondary Considerations Linked to the Claims
`F. Conclusions
`
`37
`
`ii
`
`Petitioner RPX Corporation - Ex. 1066, p.
`
`ii
`
`Petitioner RPX Corporation - Ex. 1066, p. ii
`
`

`

`Attorney Docket No. 41484-80130
`
`I.
`
`Introduction
`
`For reasons set forth in detail below, Requestor urges the Examiner to maintain the
`
`rejections of claims 1-16 set forth in the Office Action.
`
`II.
`
`Response to Patent Owner Contentions on Status of References as Prior Art.
`
`On pages 4-6 of the Response, Patent Owner asserts there is no evidence that the
`
`Aventail, BinGO, and Kent references are prior art under 35 U.S.C. § 102(a) or (b). The Patent
`
`Owner’s claims border on the frivolous — each contested reference is unquestionably a printed
`
`publication, and only by studied ignorance can Patent Owner assert otherwise. Initially, Patent
`
`Owner misstates Requestor’s burden to provide affirmative evidence with the Request proving
`
`the cited publications were publicly disseminated. In reality, all that is required is that Requester
`
`represent that the reference was published. In fact, 37 C.F.R. § 11.18 (the regulation patent
`
`owner cites) states precisely this — it provides that the submission of a paper by a party is a
`
`certification that “[t]o the best of the party’s knowledge, information and belief, formed afler an
`
`inquiry reasonable under the circumstances... [t]he allegations and other factual contentions
`
`have evidentiary support or, if specifically so identified, are likely to have evidentiary support
`
`after a reasonable opportunity for fiirther investigation or discovery.” 37 CFR 11.18(b)(2)(iii).
`
`Thus, no authority supports Patent Owner’s contention that Requestor was required to include
`
`affirmative evidence of dissemination of these printed publications.
`
`Regardless, each ofAvenrail, BinGO, and Kent was publicly disseminated prior to
`
`February 15, 2000.1 A reference is publicly accessible if it was “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.” Kyocera Wireless Corp. v. Int'l Trade Comm "n,
`
`545 F.3d 1340, 1350 (2008) (internal quotations omitted).
`
`The Avem‘ail publications2 were publicly distributed with deployments of Aventail
`
`products no later than Auggt 9, 1999. Submitted with the Request were three separate
`
`declarations, each of which established that the Aventail publications were available no later than
`
`August 8, 1999. Patent Owner contends that there is no corroborative evidence of dissemination,
`
`1
`
`Patent Owner did not contest Requester’s assertions that the effective filing date of the
`
`'151 patent is no earlier than February 15, 2000, as set forth on page 9 of the Request.
`
`Patent Owner did not difi'erentiate its challenges to the Aventail publications, but simply
`2
`contests all three together. Requester accordingly responds in the same manner.
`
`Petitioner RPX Corporation - Ex. 1066, p. 1
`
`Petitioner RPX Corporation - Ex. 1066, p. 1
`
`

`

`Control No. 95/001,714; 95/001 ,697
`Comments of the Requestor on the Patent Owner Response
`
`but that statement ignores the fact that the declarations corroborate each other. Indeed, there is a
`
`remarkable degree of consistency between the statements of Mssrs. Hopen, Fratto, and Chester,
`
`which conclusively establish the circumstances of the public distribution of the Aventail
`
`documents well before the effective filing date of the ’ 151 patent.
`
`Patent Owner next asserts that BinGO was not publicly distributed? Patent Owner is
`
`incorrect — BinGO was published and distributed publicly no later than March 30 1999. The
`
`BinGO documents bear markings indicating they were published well before the filing date of
`
`the '135 patent. Bingo UG, for example, bears a March 1999 copyright date, while Bingo EFR
`
`was published one month earlier. Patent Owner contests these dates, asserting they are “merely
`
`evidence of creation, not of publication or dissemination” and that “Without more, this
`
`unsupported assertion of the alleged copyright date of the document as the publication date does
`
`not meet the ‘publication’ standard required for a document to be relied upon as prior art.”
`
`Response at 7-8. The “more” that Patent Owner seeks is readily available on the Internet. As
`
`documented by the Internet Archive (aka, “the Wayback Machine”), the company that published
`
`BinGO, in fact, distributed the BinGO documents on the Internet. See http:
`
`/iweb.archive.org/web/19990417093944/http:/iwww.bintec.de/eflplbingo.html. Exhibit A
`
`provides an aflidavit from the Office Manager of the Internet Archive, who testified that the
`
`numbers evidenced in the “Bingo” URL indicate that both Bingo U6 and BinGO EFR were
`
`publicly available on the Internet no later than April 17, 1999. Furthermore, the archived
`
`webpage itself indicates that it was “last modified on Tuesday, March 30, 1999" — consistent
`
`with the copyright date on the Bingo UG publications. Section 2128 of the M.P.E.P states that
`
`“[a]n electronic publication, including an on—line database or Internet publicatiop, is considered
`
`to be a ‘printed publication’ within the meaning of 35 U.S.C. 102(a) and (b) provided the
`
`publication was accessible to persons concerned with the art to which the document relates.”
`
`Thus, the evidence conclusively establishes that BinGO was publicly distributed no later than
`
`
`March 30 1999.
`
`Next, Patent Owner challenges the status of several Request for Comment (RFC)
`
`publications cited in the Request, claiming that “the record is devoid of evidence that any of
`
`BinGO consists of the BinGO User Guide (“Bingo UG ”) and the BinGO Extended
`3
`Fearw'e Release (“BinGO EFR”), which is expressly incorporated by reference in the BinGO
`UG.
`
`Petitioner RPX Corporation - Ex. 1066, p. 2
`
`Petitioner RPX Corporation - Ex. 1066, p. 2
`
`

`

`Control No. 95I001,714; 95/001 ,697
`Comments of the Requester on the Patent Owner Response
`
`these references are . . . printed publications as of" each publication date listed on each RFC.
`
`This is a frivolous challenge. As anyone working in the field of network communications would
`
`know, RFC documents are published and disseminated to the relevant public by the Internet
`
`Engineering Task Force (IETF) pursuant to a transparent and well-known process. Under these
`
`well-known procedures, RFCs are self-authenticating printed publications — each contains
`
`verifiable information documenting the date of its public distribution. Specifically: (i) each
`
`number assigned to an RFC is unique and is not “re—used” if the subject matter in an RFC is
`
`revised or updated, (ii) the date each RFC is distributed to the public is listed the front page of
`
`the RFC, (iii) RFCs are distributed to the public over the Internet, via numerous protocols, (iv)
`
`each RFC is announced via an email distribution list on the date it is released to the public, and
`
`(v) RFCs are maintained in numerous archives publicly accessible via the Internet.
`
`Id at 1[1 8-
`
`22. Indeed, Patent Owner cites several RFCs as publications in the ’151 disclosure.‘1 Given this,
`
`it is remarkable that Patent Owner can even suggest that RFCs are not publicly disseminated.
`
`The evidence, thus, establishes that Avenrail, BinGO, and Kent are each printed publications
`
`applicable as prior art to the ’ 1 51 patent claims.
`
`III.
`
`The Rejections 0f the Claims Were Proper And Should Be Maintained
`
`Claims are given “their broadest reasonable interpretation, consistent with the
`
`specification, in reexamination proceedings.” In re Trans Texas Holding Corp, 498 F.3d 1290,
`
`1298 (Fed. Cir. 2007). In determining that meaning “it is improper to ‘confin[e] the claims to
`
`th[e] embodiments’ found in the specification.” Id. at 1299 (quoting Phillips v. AWHCorp, 415
`
`F.3d 1303, 1323 (Fed. Cir. 2005) (en banc)). While “the specification [should be used] to
`
`interpret the meaning of a claim,” the PTO cannot “importfl limitations from the specification
`
`into the claim.” Id. “A patentee may act as its own lexicographer and assign to a term a unique
`
`definition that is different from its ordinary and customary meaning; however, a patentee must
`
`clearly express that intent in the written description.” Helmsderfer v. Bobrici’c Washroom Equip,
`
`Inc., 52'? F.3d 1379, 1381 (Fed. Cir. 2008) (emphasis added). No such express definitions of key
`
`claim terms is provided in the ’ 151 patent. Thus, these terms must be given their broadest
`
`reasonable interpretation in these reexamination proceedings.
`
`4
`
`See, e.g., '151 Patent at 3.
`
`Petitioner RPX Corporation - Ex. 1066, p. 3
`
`Petitioner RPX Corporation - Ex. 1066, p. 3
`
`

`

`Control No. 95f001,714; 95/001,697
`Comments ofthe Requestor on the Patent Owner Response
`
`A.
`
`Response to Patent Owner’s Arguments Regarding the Rejection of Claims
`1-16 Under 35 U.S.C. § 102(b) Based on Aviean Connect v3. 01 (Issue No. 1)
`
`1.
`
`Independent Claim 1 (Issue No. 1)
`
`As explained in the Request, Aventail v.3. 01 (“Avenrail ”) describes a system which
`
`intercepts DNS requests sent by a client, and if that request specifies a secure destination,
`
`automatically authenticates the client and establishes an encrypted channel between the client
`
`and a secure destination. See, e.g., Request at 21-26. Consequently, the Office properly found
`
`that Avem‘ail describes a system that anticipates claim 1. 0A at 6-7. In response, Patent Owner
`
`asserts Aventail does not teach a system that: (1) “disclose[s] ‘determining whether the
`
`intercepted DNS request corresponds to a secure server”; or (2) “disclose[s] ‘When the
`
`intercepted DNS request corresponds to the secure server, automatically initiating an encrypted
`
`channel between the client and the secure server.” Response at 7. Each assertion is incorrect.
`
`:1.
`
`Avean Describes “Determining Whether the Intercepted DNS
`Request Corresponds to the Secure Server.”
`
`The Examiner correctly found that Avenrail discloses a system that “determin[es] whether
`
`the intercepted DNS request correSponds to a secure server.” In response, Patent Owner asserts
`
`that “whether or not a hostname is flagged by creating a false DNS entry does not indicate
`
`whether the alleged DNS request corresponds to a secure server, as false DNS entries may result
`
`even if a redirection rules is not matched.” Response at 8. Patent Owner seems to believe that
`
`the capacity of the Aventail systems to be configured to not only handle secure and insecure
`
`destinations at the client, but in one implementation, to route all DNS requests for resolution at a
`
`remote server, somehow suggests Aventail does not automatically establish authenticated and
`
`secure connections when it determines that a DNS request specifies a secure destination. Patent
`
`
`Owner ignores two critical points. First, in the implementation Patent Owner does not discuss
`
`Aventail plainly shows that the Aventail Connect client will, if it determines a request matches a
`
`redirection rule because it is specifies a secure destination, automatically establish a VPN
`
`between the client computer and the secure destination. Second, Patent Owner fails to point out
`
`where all DNS requests are proxied for resolution to a remote server, that server still will
`
`evaluate the DNS request, and if it specifies a secure destination, will establish a VPN between
`
`Petitioner RPX Corporation - Ex. 1066, p. 4
`
`Petitioner RPX Corporation - Ex. 1066, p. 4
`
`

`

`Control No. 95/001,714; 95/001 ,697
`Comments of the Requestor on the Patent Owner ResPOnse
`
`the client computer and the secure destination. Patent Owner’s focus on the mechanics of how
`
`the Aventail systems process DNS requests, thus, is a red herring.
`
`Patent Owner next asserts that the Request “fai1[s] to explain why matching a hostname
`
`to a redirection rule to ‘re-direct a request’ is the same as determining whether a DNS request
`
`corresponds to a secure server.” Response at 8. Yet, the Request explained that the
`
`specification of the ’ 151 patent discloses that the claimed “determin[ation]” of whether a DNS
`
`request corresponds to a secure server may be “by reference to an internal table.” Request at 22
`
`(citing ’151 patent at col.37, 11.60-66). As demonstrated above, the “determin[ation]” in Aventail
`
`occurs in virtually the same way — comparing the destination to entries in a lookup table.
`
`Moreover, Patent Owner’s assertion presumes the claims restrict how this determination is to be
`
`made — but the plain language used in the claims imposes no such restrictions.
`
`Patent Owner also contends that the Request does not show that any particular
`
`component “correSponds to a secure server.” Response at 8. Patent Owner is incorrect —
`
`Aventail expressly teaches that when Aventail Connect “receives a connection request, it
`
`determines whether or not the connection needs to be redirech [to an Aventail ExtraNet Server
`
`and/or encrypted (in SSL]).” Request at 25 (citing Aventail Connect v3. 01 at 10). The Request
`
`also explains that the Aventail ExtraNet Server would “automatically establish an encrypted
`
`tunnel to the secure destination computer (Le, a secure server), provided the client successfully
`
`authenticated with the Extranet Server.” Request at 24. The Aventail Extranet Server is a
`
`“secure server” within the broadest reasonable construction of the claim 1.
`
`b.
`
`Aventail Describes “When the Intercepted DNS Request
`Corresponds to the Secure Server, Automatically Initiating an
`Encrypted Channel Between the Client and the Secure
`Server.”
`
`The Examiner correctly found that Aventail discloses a system that “automatically
`
`initiat[es] an encrypted channel between the client and the secure server .
`
`.
`
`. when the intercepted
`
`DNS Request corresponds to the secure server.” In response, Patent Owner contends that
`
`“proxying a connection into a private network based on a ‘security policy’ or server
`
`‘configuration’” does not “include[] automatically initiating an encrypted channel when an
`
`intercepted DNS request corresponds to the secure server.” Response at 9. Patent Owner is
`
`again incorrect.
`
`Petitioner RPX Corporation - Ex. 1066, p. 5
`
`Petitioner RPX Corporation - Ex. 1066, p. 5
`
`

`

`Control No. 95/001,714; 95/001,697
`Comments of the Requester on the Patent Owner Response
`
`As explained in the Request, the Aventail system worked by automatically authenticating
`
`and encrypting communications between a client computer rtmning Aventail Connect and a
`
`secure private network resource via the Aventail Extranet Server. Request at 25—26; Fratto 1|124-
`
`31. In particular, Aventail Connect worked with applications that communicate via TCP/IP—
`
`such as Web browsers—and was implemented using the existing WinSOCk functionality in client
`
`computers running Windows. Fratto 1|57. Thus, Aventail Connect necessarily acted on DNS
`
`requests containing, for example, either hoslnames or IP addresses, Fratto 1[94 (“[Aventail
`
`Connect] executes a Domain Name System (DNS) lookup to convert the hostname into an
`
`Internet Protocol (I?) address”), and evaluated such requests to determine if the request was
`
`seeking access to a destination that required authentication and encryption, such as a secure
`
`website, or access to a non-secure destination, such as a public website on the Internet. Fratto
`
`{[94.
`
`Patent Owner asserts that Aventail shows that the “alleged TCP handshake is results from
`
`the ‘routable IP address,’ not that it is related to the false DNS entry or the alleged DNS
`
`request. . ..” Patent Owner is plainly incorrect. Aventaii explains that the 1? address of the
`
`Extranet Server is used as the destination for DNS requests specifying a secure destination —
`
`Aventail also explains that the fake DNS entry is simply used to enable Aventail Connect to
`
`fimction within OS-based TCP handling procedures. Similarly, Avem‘ail shows that the “routable
`
`address” of a non-secure destination is provided through a conventional DNS lookup — which
`
`happens when the request is passed back to the TCP/IP handling procedures of the client
`
`operating system. Request at 25-26.
`
`The Request also explained that “if an encryption module is enabled and selected by the
`
`SOCKS server, Aventail Connect encrypts the data on its way to the server . . ." Request at 26
`
`(citing Aventail Connect v. 3. 0] at 12). In other words, if Aventail Connect determined that a
`
`DNS request contained a hostname specifying a secure destination, it would automatically and
`
`transparently handle authentication of the user to the private network and automatically
`
`encrypt/decrypt the communications between the client computer, the secure server, and the
`
`private network resource. Request at 25-26. Specifically, Avem‘ail exmssly shows that an
`
`encrypted channel is automatically established between a client computer running an Aventail
`
`client and a secure destination computer after it is determined that the connection guest has
`
`smified a secure resource (i.e., the destination computer) on a private network. If it does, the
`
`Petitioner RPX Corporation - Ex. 1066, p. 6
`
`Petitioner RPX Corporation - Ex. 1066, p. 6
`
`

`

`Control No. 95!001,714; 95/001,697
`Comments of the Requestor on the Patent Owner Response
`
`client computer running the Aventail client automatically performs the authentication of the
`
`client with the Aventail Extranet Server, which, if successful, results in the automatic
`
`establishment of an encrypted channel with the destination specified in the DNS request. The
`
`encrypted channel facilitates the transport of encrypted network trafic between the client and
`
`secure destination over the Internet, and the Aventail client automatically encrypts outgoing
`
`traffic and decrypts incoming traffic from the secure destination. Request at 25-26. By contrast,
`
`if the DNS request specifies a non-secure destination, the request is passed to the local operating
`
`system to handle DNS resolution and establishment of the connection. Request at 26. These are
`
`not, as Patent Owner asserts, “unconnected features and embodiments” ofAventail (Response at
`
`9-10) — they are the sequence of events literally and plainly described in Aventail.
`
`Indeed, Patent Owner’s remarkable contention that Aventai! “does not teach any link
`
`between the alleged DNS request and the encryption, much less that encryption is automatically
`
`initiated when an ‘intercepted DNS request corresponds to a secure server’” is plainly refuted by
`
`the literal explanations in Aventail. See Avem‘ail Connect v3.0] at 1 (“Aventail Connect is a
`
`proxy client, but when used with SSL it provides the ability to encrypt inbound or outbound
`
`information”); Id at 7 (“Aventail Connect does not require administrators to manually establish
`
`an encrypted timnel; Aventail Connect can establish an encrypted tunnel automatically.”); Id at
`
`42 (“Aventail can establish an encrypted tunnel automatically. . .”). Indeed, page 12 ofAventail
`
`explains that “step 3” of the process
`
`when Aventail Connect determines that a secure
`
`destination is specified in the DNS request is to “transmit and receive data.” In that step, Aventail
`
`states that “[i]f 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.” Id.
`
`Patent Owner next contends that the Request fails to show “that evaluating a connection
`
`request for the presence of a false DNS entry discloses determining that a DNS request
`
`corresponds to a secure server.” As noted above, the redirection rules used by Aventail Connect
`
`dictate if a destination Specifies a secure destination; the false DNS entry is simply a flag used by
`
`Aventail Connect to handle a request determined to specify the secure destination.
`
`Next, Patent Owner asserts that Aventail “does not disclose that the creation of a false
`
`DNS entry automatically initiates a connection, much less an encrypted channe .” Response at
`
`10. Patent Owner again erroneously focuses on the mechanism used to implement the processes
`
`Petitioner RPX Corporation - Ex. 1066, p. 7
`
`Petitioner RPX Corporation - Ex. 1066, p. 7
`
`

`

`Control No. 95/001,714; 95/001,697
`Comments of the Requestor on the Patent Owner Response
`
`described in Aventaz'l. As explained in the Request, the Aventail Connect client would determine
`
`if a connection request was seeking access to a secure resource or not. If it was, and it contained
`
`a domain name, the Aventail Connect client would create a “false” DNS entry would be used to
`
`flag that connection request as requiring handling according to the policies enforced by the
`
`Aventail ExtraNet Server. Request at 22-25. These policies include, for example, evaluating the
`
`requests to determine if the request was seeking access to a destination that required
`
`authentication and encryption, such as a secure website, or access to a non-secure destination,
`
`such as a public website on the Internet. Request at 25. Obviously, the flag entered by Aventail
`
`Connect is simply information — Aventail shows that the Aventail Connect client, working with
`
`the ExtraNet Server, caused actions based on evaluation of that information.
`
`Patent Owner also asserts that “the Request improperly mixes and matches the various
`
`separate embodiments ofAventail v3.01 by pointing to the inbound access embodiment . .
`
`. and
`
`then turning to the outbound embodiment.” Response at 10-11. Patent Owner is incorrect, as it
`
`wrongly asserts that Aventail discloses two distinct embodiments related to outbound and
`
`inbound access. InAvenraii, the characterization of “outbound” and “inbound” access is simply
`
`a function of perspective. Indeed, Avem‘ail describes an end-to-end system that contemplates
`
`outbound requests from a client computer for access to a secure destination—from the
`
`perspective of the secure destination, that request and the encrypted channel that follows would,
`
`obviously, be described as an inbound connection. The communications are also plainly bi-
`
`directional. Moreover, the claims do not employ the terms “inboun ” or “outboun ” much less
`
`restrict the sequence of steps that comprise the claimed “data processing device.”
`
`Patent Owner also criticizes the Request for relying on multiple sections ofAventail to
`
`demonstrate that the claims are anticipated. In particular, Patent Owner complains that it does
`
`not understand how “different embodiments and fimctionalities .
`
`.
`
`. separated by over sixty
`
`pages, can be combined to disclose” the above claim requirement. Response at 11. Patent
`
`Owner’s assertion is frivolous. The vaIiOUS sections and passages of Aventail cited in the
`
`Request simply provide varying degrees of detail in the description of the features and operation
`
`of the Aventail systems. The fact that those sections are, like any other technical publication,
`
`separated into different sections or found on different pages ofthe document is irrelevant.
`
`Consequently, the Examiner’s determination that claim 1 is anticipated by Aventail was proper
`
`and should be maintained.
`
`Petitioner RPX Corporation - Ex. 1066, p. 8
`
`Petitioner RPX Corporation - Ex. 1066, p. 8
`
`

`

`Control No. 95i001,714; 95/001,697
`Comments ofthe Requestor on the Patent Owner Response
`
`2.
`
`Independent Claims 7 and 13 (Issue No. 1)
`
`The Examiner correctly found that Aventail describes a system that anticipates claims 7
`
`and 13. In response to the rejection of claim 7, Patent Owner asserts no response distinct from
`
`its resPonse to the rejection of claim 1. Response at 11. Because the Examiner’s rejection of
`
`claim 1 was proper, its rejection of claim 7 based Avem‘ail also was proper and should be
`
`maintained.
`
`In response to the rejection of claim 13, Patent Owner contends that the Request has
`
`“ignore[d]” the difference in claim language between claims 1 and 13. Patent Owner is
`
`incorrect. The only distinction identified by Patent Owner is that claim 13 recites “automatically
`
`creag'g a secure channel,” while claim 1 recites “automatically
`
`g an encrypted channe .”
`
`Response at 11. The Request plainly identified this distinction, explaining that “claim 13 is
`
`directed to subject matter similar to that recited in claim 1.” Request at 42. Patent Owner
`
`identifies no issue of consequence tied to the different phrases. This is logical because there is
`
`none — the difference between “creating a secure channel” and “initiating an encrypted channel”
`
`is immaterial to the Examiner’s determination that Avenraii describes a system that anticipates
`
`claim 13. In fact, as the Examiner recognized, “[i]nitiating an encrypted channel” in claim 1 is
`
`simply a narrower limitation than claim 13’s “creating a secure channel.” See ’504 ACP at 33
`
`(explaining that a secure communication link does not require encryption). Because Aventar'l
`
`describes this element of claim 1 it necessarily describes a broader form of this element in claim
`
`13. Consequently, the Examiner’s rejection of claim 13 based on Aventar'l was proper and
`
`should be maintained.
`
`3.
`
`Dependent Claims 2, 8, and 14 (Issue No. 1)
`
`The Examiner correctly found that Aventar'l describes a system that anticipates claims 2, 8
`
`and 14. In response to the rejection of the claims, Patent Owner contends that Aventaii does not
`
`disclose the element of “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.” Response at 12. Patent Owner misunderstands the Request and teachings ofAvem‘ail.
`
`As explained in the Request, a client computer running Aventail Connect would have to
`
`successfully authenticate before being given access to a secure destination. Request at 27-28.
`
`In particular, Aventail explains that:
`
`Petitioner RPX Corporation - Ex. 1066, p. 9
`
`Petitioner RPX Corporation - Ex. 1066, p. 9
`
`

`

`Control No. 95/001,714; 95/001,697
`Comments ofthe Requester on the Patent Owner Response
`
`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 p_olir_:y, the Aventail ExtraNet
`Server will mxy user traffic into the private network but only those resources
`allowed.” (emphasis added)
`
`Aventail Connect v. 3. 01 at 72-73. Patent Owner does not address this passage —which
`
`was expressly noted by the Examiner—because it plainly shows the embodiment referenced in
`
`these claims.
`
`Patent Owner elects instead to present a convoluted and confiised discussion of different
`
`aspects of the Aventail process. In particular, Patent Owner conflates the various distinct
`
`processes that occur when Aventail Connect acts on a request. For example, Patent Owner
`
`intermingles the steps taken when a DNS request contains an IP address with those where the
`
`DNS request contains a host name. Similarly, Patent Owner confuses the steps taken by
`
`Aventail Connect when the client determines a requested destination is secure versus when it is
`
`insecure. Patent Owner then presents a mangled conclusion from its incorrect reading of
`
`Aventail, asserting first that a “routable address” only is obtained when the Aventail C