Attorney Docket No: 41484—80130
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`in re Inter Perms Reexamination of
`
`)
`
`us. Patent No. ’1’,490:151
`Edmund Colby Munger et a1.
`Issued: February 10, 2089
`For:
`ESTABLISHMENT OF A SECURE.
`COMWICATION LINK BASED
`ON A DOMAIN NAME SERVICE
`
`(ENS) REQUEST
`
`; Controi No.2 95/001,7141901fi97
`;
`3‘0“? Art um“
`3992
`i Exanuner: Michael J, Yrgdaii
`)
`commutation N‘“ 3438’ 2151
`)
`
`COMMENTS BY THIRD PARTY RE UESTER PURSUANT TO 37 ERR.
`
`
`
`
`Mail Stop Inter Partes Reexam
`Commissioner for Patents
`PD. Bax 1458
`
`Alexandria, VA 22313—1450
`
`Sir:
`
`On July 20, 2012, Patent Dimer tiled an overiength reSponse (“Response”) tn: the April 28,
`
`2012 Office action (“Office Action”) and a petition under 37 CPR. § 1.183 seeking waiver of the
`
`page limit for diet response On September 25, 2012, the Office granted Patent Dmer’s petition,
`
`which set the date for a response by the Requester 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. Bewever, any fee required for entry or consideration of this paper may
`
`be debited from Depesit Account No. 184260.
`
`—
`
`—
`
`A table of contents is provided at pages ii to iv. Requester submits the table of
`
`contents is net 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 te the Patent Owner Comments begins on page I.
`
`1
`
`MICROSOFT 1027
`
`1
`
`MICROSOFT 1027
`
`

`

`Control No. 951001.714; 95/001,69?
`Comments of the Requester on the Patent Owner Response
`
`TABLE on CONTENTS
`
`.
`Introduction "... ............................
`
`......................
`
`.....................................................,1
`
`Response to Patent Owner Contentions on Status of References as Prior Art............... 1
`
`I.
`
`11.
`
`III.
`
`The Rejections Of the Claims. Were Proper And Should Be Maintained ....................... 3
`
`A. Response to Patent Owner’s Arguments Regarding the Rejection of Claims 146
`Under 35 [1.8.11 § 102(k) Based nnAventaiI Canned v3.01 (Issue No. I} ................ 4
`1.
`Independent Claim 1 (Issue No. l) .......................................................................... 4
`a. Aventnil Describes “Determining Whether the Intercepted DNS Request
`Cnrresponds to the Secure Server.” ............................................................................ 4
`Independent Claims 7 and 13 {issue No. 1) ............................................................. 9
`2.
`3. Dependent Claims 2, 8, and 14(lssue No. l) .......................................................... 9
`4. Dependent Claims 3, 9, and 15 (Issue No. I) ........................................................ ll
`5. Dependent Claims 4, 10, and 16 (Issue No. l) ...................................................... 12
`6. Dependent Claims 5 and ll (Issue No. l) ............................................................. 12
`7. Dependent Claims 6 and 12 (Issue No. l) ............................................................. 13
`
`Respnnse to Patent Owner’s Arguments Regarding the Rejection of Claims; 1-16
`Based onAventailAumSOCILS’Adminis’tmtar’s Guidn (Issue No.2) 14
`
`Response to Patent Owner’s Arguments Regarding the Rejection of Claims 1-4, EL
`8, 10, 12, 13 and 18 Based an Reset in View of Kent (Issue 4). ................................ 14
`8.
`Independent Claim 1 .............................................................................................. 14
`b.
`Bayer and Ken: Disclose a DNS Proxy Module that Intercepts DNS Requests Sent
`byaClient...
`..16
`83rer in View dfKent,RendersObvions Automatically Initiating anEncrypted
`Channel BeWeen the Client and the Secure Server When the Request Conesgnnds
`to a Secure Server ..................................................................................................... 19
`
`d.
`
`Independent Claim 7" .............................................................................................. 2l
`l.
`Independent Claim l3 ........................................................................................... .21
`2.
`3. Dependent Claims 2, 8, and 14 .............................................................................. 22.
`4. Dependent Claims 4, 10, and 16 ............................................................................ 23
`5. Dependent Claims 5 and ll ................................................................................... 24
`6. Dependent Claims 6 and 12 ................................................................................... 25
`
`Response to Patent Owner’5 Arguments Regarding the Rejection of Claims 1-16
`Under 35 U.SC §162(a) Based an BinGO (Issue 3)................................................. 25
`l. BinGO Expressly Ineorporateg BinGO EFR ......................................................... 25
`2.
`Independent Claim 1 .............................................................................................. 26
`3.
`lndependent Claims 7 and 13 ................................................................................ 33
`4. Dependent Claims 2, 8, and 14 .............................................................................. 34
`5. Dependent Claims 4, 10, and 16 ............................................................................ 35
`6. Bependent Claims 5 and ll ................................................................................... 35
`7. Dependent Claims 6 and 12 ................................................................................... 36
`
`'31?”
`
`There are No Secondary Considerations Linked to the Claims ............................. 36
`Conclusions . ................................................................................................................. 37
`
`ii
`
`2
`
`

`

`Attorney Docket No. 41484-80130
`
`I.
`
`Introduction
`
`For reasons set forth in detail below, Requester urges the Examiner to maintain the
`
`rejections of claims 1-16 set forth in the Office Action.
`
`11.
`
`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 {18.0. § l02(a) or (b). The Patent
`
`Owner’s claims border on the frivolous e each contested reference is unquestionably a printed
`
`publication, and only by studied ignorance can Patent Owner assert otherwise, Initially, Patent
`
`Owner misstates Requestoris 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 (SEER. § 11.18 (the regulation patent
`
`owner cites) states precisely this «a it provides that the submission of a paper by a party is a
`
`certification that “[t]o the bed of the party’s knowledge, information and belief, formed after an
`
`inquiry reasonable under the circumstances... [t]he allegations and other factual contentions
`
`have cvidentiary support or, if specifically so identified, are likely to have evidentiary support
`
`after a reasonable opportunity for further investigation or discovery." 3’? CFR ll.lS(b)(2)(iii).
`
`Thus, no authority supports Patent Owner’s contention that Requester was required to include
`
`affirmative evidence of dissemination of these printed publications.
`
`Regardless, each ofAventaz‘l, 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.” Kyocem Wireless Corp. v. for? Trade Comm ”:2,
`
`545 F.3d 1340, 1350 (2008) (intemal quotations omitted).
`
`The Aventaz‘l publications2 were publicly distributed with deployments of Aventail
`
`products no later than August 9, 1999. Submitted with the Request were three separate
`
`declarations, each of which established that the Aventoil publications were available no later than
`
`August 8, 1999. Patent Owner contends that there is no corroborative evidence of dissemination,
`
`‘
`
`Patent Gunter 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 Gunter did not differentiate its challenges to the Aventail publications, but simply
`2
`contests all three together. Requester accordingly responds in the same manner.
`
`3
`
`

`

`Control No. 95/00l,?14; 95/001,697
`Comments of the Requester 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 Aventaii
`
`documents well before the effective filing date cf’thc ’ l 51 patent.
`
`Patent Ovmer next asserts that BinGO was not publicly distributed.3 Patent Owner is
`
`incorrect e BinGO was published and distributed publicly no later than March 30 I999. The
`
`BirIGO documents bear markings indicating they were published well before the filing date of
`
`the ’135 patent. Bingo US, 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 cepyright 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:
`
`fiwebarchivecrg/webll 9990417093944mb}::l/uwbintecde/eftpibingc.htrnl. Exhibit A
`
`provides an affidavit 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 1?: 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 lutemet publication, is considered
`
`to be a ‘printed publication’ within the meaning of 35 ’U.S.C. 102(a) and (13) 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
`
`BMW consists of the BinGG fiber Guide (“Bingo UG”) and the BiaGO Extended
`3
`Feomre Release (“BinGO EFR”), which is expressly incorporated by reference in the BinGO
`UG.
`
`4
`
`

`

`Control No. 95/001,714; 951001,697
`Comments of the Requester on the Patent Owner Response
`
`these references are . . . printed publications as oi“ each publication date listed on each RFC.
`
`This is a frivolous challenge. As anyone working in the field of Ironwork 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 1118-
`
`22. Indeed, Patent Owner cites several RFCs as publications in the ’15 l disclosure.4 Given this,
`
`it is remarkable that Patent Owner can even suggest that RFCs are not publicly disseminated.
`
`The evidence, thus, establishes that Aventaii, BinGO, and Kent are each printed publications
`
`applicable as prior art to the ’ l 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 ‘conlin[e] the claims to
`
`th[e] embodiments’ found in the specification.” Id. at 1299 (quoting Phillips v. AWH Corp, 415
`
`F.3d 1303, 1323 (Fed. Cir. 2005) (an bane». While “the specification [should be used] to
`
`interpret the meaning of a claim,” the PTO cannot “importfl limitations from the specification
`
`into the claim.” 1d. “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. Bobrick Washroom Equip”
`
`Inc, 527 F.3d 1379, 1381 (Fed. Cir. 2008) (emphasis added). No such express definitions of key
`
`claim terms is provided in the ’ lSl patent. Thus, these terms must be given their broadest
`
`reasonable interpretation in these reexamination proceedings.
`
`See, e.g., ’lSl Patent at 3.
`
`5
`
`

`

`Control No. 951081514; 95/001,697
`Comments of the Requester on the Patent Owner Response
`
`A».
`
`Response to Patent Owner’s Arguments Regarding the Reiection of Claims
`1416 Under 35 [3.3.0 § 132m) Based on Aventnil Connect v3.01 (Issue No. l)
`
`1.
`
`Independent Claim 1 (Issue No. 1)
`
`As explained in the Request; Avenrotl v.31?! {“Aventail ”) 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 encn’pted channel between the client
`
`and a secure destination. See, eg, Request at 2l«26. Consequently, the Office properly found
`
`that Aventuil describes a system that anticipates claim 1. DA at 6-7. In response, Patent aner
`
`asserts Aventcii does not teach a system that: (l) “disclose[s} ‘determining whether the
`
`intercepted DNS request corresponds to a secure server”; or (2) “disclose[s] ‘when the
`
`intercepted ENS 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.
`
`a.
`
`Aveatail Describes “Determining Whether the Intercepted DNS
`Request Corresponds to the Secure Server.”
`
`The Examiner correctly found that Aventaii discloses a system that “determln{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 ENS request corresponds to a secure server, as false ENS entries may result
`
`even if a redirection rules is not matched.” Response at 3. 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 Aventatl 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,
`
`Aventaz‘i 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
`
`beaveen 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 ENS request, and if it specifies a secure destination will establish a VPN hemecn
`
`6
`
`

`

`Control No. 951001,? l 4; 95f001,697
`Comments of the Requester 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 “fail [s] to esplain why matching a hostname
`
`to a redirection ruie to ‘resdirect 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 “deterrnin[ation]” of whether a DNS
`
`request corresponds to a secure server may be “by reference to an internal table.” Request at 22
`
`(citing ’“ l 51 patent at coi.37, 11.60-66). As demonstrated above, the “tletermin{ation]” in Avenruil
`
`occurs in Virtually the same way « comparing the destination to entries in a lockup 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 aner also contends that the Request does not show that any particular
`
`component “corresponds to a secure server." Response at 8. Patent Owner is incorrect «-
`
`Aventoii expressly teaches that when Aventaii Connect “receives a connection request. it
`
`determines whether or not the connection needs to be redirected [to an Aventaii ExtraNet Server
`
`andfor encrypted (in SSL]).” Request at 25 (citing Avenraz‘l Connect v3. 01 at l0). The Request
`
`also explains that the Aventaii ExtraNet Server would “automatically establish an encrypted
`
`tunnel to the secure destination computer (ie, a secure server}, provided the client successfully
`
`authenticated with the Extranet Server.” Request at 24. The Aventaii Extranet Server is a
`
`“secure server” within the broadest reasonable construction of the claim 1.
`
`b.
`
`Aventaif Describes “When the Interceptor! DNS Request
`Corresponds to the Secure Server, Automatically Initiating an
`Encrypted Channel Between the Client and the Secure
`Server.”
`
`The Examiner correctly found that Avenraiz' 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
`
`‘nroxying a connection into a private network based on a ‘seeurity policy’ or server
`
`‘oontigurationm does not “inciudefl automatically initiating an encrypted channei when an
`
`intercepted DNS request corresponds to the secure server.” Response at 9. Patent Owner is
`
`again incorrect.
`
`7
`
`

`

`Control No. 95/001,? 1 4; 95f001,697
`Comments of the Requester on the Patent Owner Response
`
`As explained in the Request, the Aventail system worked by automatically authenticating
`
`and encrypting conununications between a client computer running 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/le
`
`such as Web browsersmand was implemented using the existing WhiSock functionality in client
`
`computers running Windows. Fratto 1157. Thus, Aventail Connect necessarily acted on DNS
`
`requests containing, for example, either hostnarnes or IP addresses, Fratto 1194 (“[Avcntail
`
`Connect] executes a Domain Name System (DNS) lookup to convert the hostname into an
`
`Internet Protocol (1?) 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 lnternet. Franc
`
`$94.
`
`Patent Owner asserts that Aventail shows that the “alleged TCP handshake is results from
`
`the ‘routable lP address,’ not that it is related to the false DNS entry or the alleged DNS
`
`request“ ..” Patent Owner is plainl}r incorrect. Avenmii' explains that the IP address of the
`
`Extranet Server is used as the destination for DNS requests specifying a secure destination m
`
`Aventnil also explains that the fake DNS entry is simply used to enable Aventail Connect to
`
`fimction within OS—‘oased TCP handling procedures. Similarly, Aventaii shows that the “routahle
`
`address” of a nonasecure destination is provided through a conventional DNS lookup «a which
`
`happens when the request is passed back to the TCPz’lP 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, Avcntail Connect encrypts the data on its way to the server ..." Request at 26
`
`(citing Aventoi! Connect v. 3. 0} at 12). In other words, if Aventail Connect determined that a
`
`DNS request contained a hosmame 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, Avcnmil expressly shows that an
`
`encrypted channel is automatically established between a client computer running an Aventail
`
`client and a secure destination computer alter it is determined that the connection roguest has
`
`specified a secure resource (i.e., the destination computer) on a private network. If it does, the
`
`8
`
`

`

`Control No. 93001314; 95/001,697
`Comments of the Requester on the Patent Gamer Response
`
`client computer ruruting the Aventail client automatically performs the authentication of the
`
`client with the Aventail Extraoet 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 trafiic 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,
`
`it‘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
`
`940) m they are the sequence of events literally and plainly described in Avenroil.
`
`Indeed, Patent Owner’s remarkable contention that Aventail “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 Aventait’. See Avenues? Connect v3. 01 at l (“Aventail Connect is a
`
`proxy client, but when used with SSL it provides the ability to encrypt inbound or outbound
`
`information”); Id. at 7 (“Avean Connect does not require administrators to manually establish
`
`an encrypted tunnel; Aventail Connect can establish an encrypted tunnel automatically”); Id at
`
`42 (“Aventail can establish an encrypted tunnel automatically. . 3’).
`
`indeed, page 12 of Aventail
`
`explains that “step 3” of the process initiated 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 Aventnil “does not disclose that the creation of a false
`
`DNS entry automatically initiates a connection, much less an encrypted channel.” Response at
`
`10. Patent Gunter again erroneously focuses on the mechanism used to implement the processes
`
`9
`
`

`

`Control No. 95/001,714; 95/001,697
`Comments of the Requester on the Patent Owner Response
`
`described in Aventaii. 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 ‘Talse” DNS entry would be used to
`
`flag that connection request as requiring handling according to the policies enforced by the
`
`Aventaii ExtraNet Server. Request at 22—25. These policies include, for example, evaluating the
`
`requests to determine if the reg uest was seeking access to a destination that required
`
`authentication and encgggtjon, 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 Aveutail
`
`Connect is simply information ~Aventaii 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 ofAverzraiI v3.01 by pointing to the inbound access embodiment .
`33
`then turning to the outbound embodiment. Response at 10—11. Patent Gunter is incorrect, as it
`
`. and
`
`.
`
`wrongly asserts that Aromas"! discloses two distinct embodiments related to outbound and
`
`inbound access. In Avcntaii, the characterization of “outbound” and “inbound” access is simply
`
`a function of perspective. Indeed, Aventaii describes an endsto-end system that contemplates
`
`outbound requests from a client computer for access to a secure destinationmii'om 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 “inbound” 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 of Avenrail to
`
`demonstrate that the claims are anticipated. In particular, Patent Duster complains that it does
`
`not understand how “different embodiments and functionalities .
`
`.
`
`. separated by over sixty
`
`pages, can be combined to disclose” the above claim requirement. Response at l 1. Patent
`
`Owner’s assertion is fiivolous. The various 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 of the document is irrelevant.
`
`Consequently, the Examiner’s determination that claim 1 is anticipated by Aventoil was proper
`
`and should be maintained.
`
`10
`
`10
`
`

`

`Control No. 95/00 1 ,7 l 4; 95mm ,697
`Comments of the Requester on the Patent Dimer Response
`
`2.
`
`Independent Claims 7 and 13 (Issue No. l)
`
`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 ll. Because the Examiner’s rejection of
`
`claim I was proper, its rejection of claim 7 based Atlanta?! 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
`
`creating a secure channel,” while claim 1 recites “automatically initiating an encrypted channe .”
`
`Response at ll. 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 e the difference between “creating a secure channel” and “initiating an encrypted channel”
`
`is immaterial to the Examiner’s determination that Avent'ail describes a system that anticipates
`
`claim 13. In fact, as the Examiner recognized, “[ilnitiating an encrypted channel” in claim I is
`
`simply a narrower lhnitation than claim 13’s “creating a secure channel.” See ’504 AC}? at 33
`
`(explaining that a secure communication link does not require encryption). Because Avenrail
`
`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 Aventail was proper and
`
`should he maintained.
`
`3.
`
`Dependent Claims 2, 8, and 14 (Issue No. l)
`
`The Examiner correctly found that Avenrail describes a system that anticipates claims 2, 8
`
`and 14. in response to the rejection of the claims, Patent Owner contends that Aventnii 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 Gamer misunderstands the Request and teachings ofAvenraiZ.
`
`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, Aventoii explains that:
`
`11
`
`11
`
`

`

`Control No. 95/001,714; 95f0tll,697
`Comments of the 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 fom'ard traffic destined for the private internal network to the Aventail
`ExtraNet Server.
`'lhen, based on the security: policy, the Aventail Emmet
`Server will proxy; user traffic into the private network but only those resources
`allowed.” (emphasis added)
`
`Aventoii Connect v.3. 01 at 72-?3. Patent Owner does not address this passage “which
`
`was expressly noted by the Examinermbecause it plainly shows the embodiment referenced in
`
`these claims.
`
`Patent Owner elects instead to present a convoluted and confined discussion of different
`
`aspects of the Aventaii process. In particular, Patent Owner conflates the various distinct
`
`processes that occur when Aventail Connect acts on a request. For example, Patent Owner
`
`intenningles the steps taken when a DNS request contains an ll’ 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 “ro'utablc address” only is obtained when the Aventail Connect
`
`client does not create a false DNS entry flag, and then that a “proxy connection” occurs “only
`
`alter authentication and encryption have already been established. ”
`
`Instead of attempting to unravel this hopelessly confused and inaccurate description of
`
`Aventaz’l, the Examiner need only re_ad Aversion, which clearly explains that if the Ave-mail
`
`Connect client determines a request is specifying a secure destination (i.c., e