IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________
`
`Radware, Inc.
`Petitioner
`
`v.
`
`F5 Networks, Inc.
`Patent Owner
`
`____________
`
`Case IPR2017-_________
`Patent 7,472,413
`
`____________________________________
`
`PETITION FOR INTER PARTES REVIEW
`
`UNDER 35 U.S.C. §§311-319 AND 37 C.F.R. §§ 42.1-.80, 42.100 ET SEQ.
`
`
`
`
`
`1
`
`

`
`TABLE OF CONTENTS
`
`Page
`
`INTRODUCTORY STATEMENT .......................................................................... 1
`
`I. MANDATORY NOTICES (37 C.F.R. § 42.8(A)(1)) .................................... 1
`
`A.
`
`B.
`
`Real Parties-in-Interest (37 C.F.R. § 42.8(b)(1)) ................................. 1
`
`Related Matters (37 C.F.R. § 42.8(b)(2)) ............................................. 1
`
`C. Designation of Lead and Back-Up Counsel (37 C.F.R. §
`42.8(b)(3)) ............................................................................................ 2
`
`D. Grounds for Standing (37 C.F.R. § 42.104(a)) .................................... 2
`
`E.
`
`F.
`
`Service Information (37 C.F.R. § 42.8(b)(4)) ...................................... 3
`
`Payment of Fees (37 C.F.R. § 42.103) ................................................. 3
`
`II.
`
`STATEMENT OF THE PRECISE RELIEF REQUESTED AND THE
`REASONS THEREFOR ................................................................................ 3
`
`III. THE ’413 PATENT ........................................................................................ 4
`
`A.
`
`B.
`
`Summary of the ’413 Patent ................................................................. 4
`
`The ’413 Patent’s File History ........................................................... 10
`
`Ex. 107 at 122 ............................................................................................... 11
`
`IV. A PERSON OF ORDINARY SKILL IN THE ART ................................... 11
`
`V.
`
`CLAIM CONSTRUCTION (37 C.F.R. § 42.104(B)(3)) ............................. 11
`
`A.
`
`B.
`
`“Training Mode” ................................................................................ 12
`
`“Security Mode” ................................................................................. 13
`
`VI. PRIOR ART BACKGROUND .................................................................... 14
`
`A.
`
`International Publication No. WO 03/058450 to Raanan et al.
`(“Raanan”) (Ex. 1011) ........................................................................ 14
`
`i
`
`

`
`TABLE OF CONTENTS
`
`Page
`
`
`
`B. U.S. Published Application No. 2003/0051142 A1 to Hidalgo et
`al. (“Hidalgo”) (Ex. 1013) .................................................................. 22
`
`C.
`
` “Sanctums Simple Approach To Security,” by Rapoza J.
`(“Rapoza”) (Ex. 1014) ........................................................................ 27
`
`VII.
`
`IDENTIFICATION OF THE CHALLENGE (37 C.F.R. § 42.104(B)) ...... 29
`
`A.
`
`The ’413 Patent Claims are not Entitled to the Priority Date of
`8/11/2003 ............................................................................................ 30
`
`B. Ground 1: Claim 1-24 are Obvious From Raanan and Hidalgo ....... 31
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`6.
`
`7.
`
`8.
`
`9.
`
`Claim 1 ..................................................................................... 33
`
`Claims 2 and 3 .......................................................................... 50
`
`Claims 4, 9, 14, 18-20, and 22 ................................................. 53
`
`Claims 5 and 11 ........................................................................ 57
`
`Claims 6, 8, 12, 13, and 21 ...................................................... 59
`
`Claims 7 and 15 ........................................................................ 61
`
`Claim 10 ................................................................................... 63
`
`Claims 16 and 17...................................................................... 64
`
`Claims 23 and 24...................................................................... 73
`
`C. Ground 2: Claims 7, 15, 23 and 24 are Obvious From Raanan,
`Hidalgo, and Rapoza .......................................................................... 79
`
`VIII. CONCLUSION ............................................................................................. 81
`
`IX. CERTIFICATION TO WORD COUNT UNDER 37 C.F.R.
`§42.24(D) ...................................................................................................... 82
`
`
`
`ii
`
`

`
`
`
`INTRODUCTORY STATEMENT
`
`Radware, Inc. (“Petitioner”) in accordance with 35 U.S.C. §§311-319 and 37
`
`C.F.R. §§42.1-.80, 41.100-41.123, respectfully requests inter partes review for
`
`claims 1-24 of U.S. Patent No. 7,472,413 (’413 Patent). Petitioner seeks review
`
`and cancellation of all 24 claims of the ’413 Patent. All claims of the ’413 Patent
`
`are unpatentable as anticipated and/or obvious under 35 U.S.C. § 103. The U.S.
`
`Patent and Trademark Office (USPTO ) assignment records indicate that the ’413
`
`Patent is assigned to F5 Networks, Inc. (“Patent Owner”).
`
`I. MANDATORY NOTICES (37 C.F.R. § 42.8(a)(1))
`
`A. Real Parties-in-Interest (37 C.F.R. § 42.8(b)(1))
`
`The real party-in-interest is Radware Ltd. (“Radware” or “Petitioner”).
`
`Radware is a corporation organized under the laws of New Jersey. Radware is not
`
`barred by operation of estoppel to submit this Petition for inter partes review.
`
`B. Related Matters (37 C.F.R. § 42.8(b)(2))
`
`The ’413 Patent (Ex. 1001) is asserted against Petitioner in pending district
`
`court litigation, F5 Networks, Inc. v. Radware, Inc., United States District Court
`
`for the Western District of Washington, Case No. 16-cv-480-RAJ. The complaint
`
`was filed on April 4, 2016 (Ex. 1002) and served on Petitioner on April 5, 2016
`
`(Ex. 1003). Petitioner is not aware of any pending prosecution or administrative
`
`proceedings concerning the ’413 Patent.
`
`
`
`1
`
`

`
`
`
`C. Designation of Lead and Back-Up Counsel (37 C.F.R. § 42.8(b)(3))
`
`Petitioner provides the following designation of counsel. Please address all
`
`correspondence to lead and back-up counsel.
`
`LEAD COUNSEL
`Fabio E. Marino (Cal. SBN 183825)
`Reg. No. 43,339
`fmarino@mwe.com
`
`McDermott Will & Emery
`275 Middlefield Road, Suite 100
`Menlo Park, CA 94025-4004
`Tel: (650) 815-7605
`
`BACK-UP COUNSEL
`Barrington E. Dyer (Cal. SBN 264762)
`Pro Hac Vice to be requested
`bdyer@mwe.com
`
`McDermott Will & Emery
`275 Middlefield Road, Suite 100
`Menlo Park, CA 94025-4004
`Tel: (650) 815-7612
`
`
`
`D. Grounds for Standing (37 C.F.R. § 42.104(a))
`
`Petitioner certifies that the ’413 Patent is eligible for inter partes review and
`
`further certifies that Petitioner is not barred or otherwise estopped from requesting
`
`inter partes review challenging the identified claims on the grounds in the present
`
`Petition. This Petition is filed within one year of the date Petitioner was served
`
`with a complaint of infringement of the ’413 Patent. A true copy of the Proof of
`
`Service of Summons and Complaint, showing the date of service of April 5, 2016
`
`is included as Ex. 1003. Petitioner has not filed a civil action challenging the
`
`validity of a claim of the ’413 Patent. 35 U.S.C. §315(a).
`
`2
`
`

`
`
`
`E.
`
`Service Information (37 C.F.R. § 42.8(b)(4))
`
`Papers concerning this matter should be addressed to the lead and back-up
`
`counsel at the address provided above. Petitioner consents to electronic service by
`
`email at: IPdocketMWE@MWE.com, fmarino@mwe.com and bdyer@mwe.com.
`
`F.
`
`Payment of Fees (37 C.F.R. § 42.103)
`
`The Patent and Trademark Office is hereby authorized to charge Deposit
`
`Account No. 505907 for the fee set in 37 C.F.R. § 42.15(a) for this Petition for
`
`inter partes review, and for any additional fees that may be due as a result of the
`
`submission of this Petition.
`
`II.
`
`STATEMENT OF THE PRECISE RELIEF REQUESTED AND THE
`REASONS THEREFOR
`Radware requests inter partes review and cancellation of claims 1-24 of U.S.
`
`Patent No. 7,472,413 (Ex. 1001) based on 35 U.S.C. § 103 for the reasons stated
`
`herein. This Petition establishes a reasonable likelihood that the Petitioner will
`
`prevail in establishing that the challenged claims are unpatentable. The following
`
`chart summarizes the individual grounds, including the statutory basis and the prior
`
`art relied upon for each ground.
`
`Ground
`No.
`1
`
`2
`
`35 USC
`
`Claims
`
`Prior Art Reference(s)
`
`§ 103
`
`§ 103
`
`1-24
`
`Raanan-2002 in view of Hidalgo-2002
`
`7, 15, 23, 24 Raanan-2002 in view of Hidalgo-2001, and
`further in view Of Rapoza-2002
`
`3
`
`

`
`
`
`None of the prior art references were made of record during prosecution of
`
`the ’413 Patent and were, therefore, not considered by the examiner.
`
`III. THE ’413 PATENT
`
`A.
`
`Summary of the ’413 Patent
`
`The ’413 Patent is directed to improving the security of web applications
`
`and addressing vulnerabilities inherent in client-server interactions. It discloses a
`
`web application security system that enables validation of a request from a web
`
`client before the request reaches a web application server. Ex. 1001 at 3:40-59,
`
`2:47-49. Validation is determined on a comparison of the request with a model of
`
`the web application and/or on the presence of valid encrypted token. Id. at 3:40-
`
`59, 2:47-49. This ensures the client request has not been modified in order to gain
`
`access to a restricted part of the server or to induce an unintended response from
`
`the server. Id. at 3:40-59, 2:47-49.
`
`The system consists of a “security server” in between the client and the web
`
`application that contains a model of the web application. This enables the security
`
`system to intercept client requests and server responses like a firewall or gateway
`
`would. Id. at 2:65-3:1, 13:3-5. Figure 1 below is a network diagram of the claimed
`
`system and method for managing communications over a network. Id. at 1:61-62.
`
`4
`
`

`
`
`
`
`
`Alternatively, the alleged invention may take the form of an “entirely software
`
`embodiment” requiring no special hardware (Id. at 2:35-39), or may be deployed
`
`as part of an integrated network device. Id. at 4:43-54.
`
`There are four main features of the security system: (1) generating a model
`
`of web application; (2) intercepting an HTTP request from a client and checking
`
`whether it complies with the application model; (3) intercepting an HTTP response
`
`from the application and inserting an encrypted token therein; and (4) intercepting
`
`a subsequent HTTP request and checking its validity based on the encrypted token.
`
`See, e.g., Claim 1.
`
`5
`
`

`
`
`
`The first feature involves initial generation and testing of the application
`
`model based on interactions with an application over a network (e.g. client HTTP
`
`requests and application server HTTP responses). Id. at 2:65-3:8; 3:15-25.
`
`The second feature verifies whether an HTTP request complies with the
`
`application model. Id. at 3:26-39. If it complies, the request is passed to the
`
`application server. But if the request does not comply, it is blocked and additional
`
`steps may be taken. Id. at 11:31-37.
`
`The third feature inserts an encrypted “state” token into an HTTP response
`
`before it is sent to the client. Id. at 16:25-17:9. The token prevents a client from
`
`modifying fields in a subsequent HTTP request, and provides a means to verify
`
`that the fields in a subsequent HTTP request have not been improperly modified.
`
`Id. at 14:1-4.
`
`Finally, the fourth feature checks whether a subsequent request from the
`
`client contains the encrypted state token inserted into the HTTP response. Id. at
`
`16:25-29. If the encrypted token is present and the request compliant with the data
`
`associated with the token, the request forwarded to the server. If, however, the
`
`token is missing, or the data in the request is not compliant with the data associated
`
`with token, the request is blocked, and other corrective measure may be taken. Id.
`
`at 3:55-59.
`
`Claim 1 is of the ’413 Patent is representative of the purported invention:
`
`6
`
`

`
`
`
`1[b]
`
`1[a] A method of managing a communication over a network,
`comprising:
`generating an application model based on interactions with an
`application over the network;
`intercepting a request to the application from a client to the
`application residing on a server over the network;
`comparing the request to the application model;
`
`1[c]
`
`1[d]
`
`if the request is compliant with the application model,
`forwarding the request to the application;
`receiving a response to the request;
`
`examining the response for state data, including at least a
`hidden field value within the response;
`storing the hidden field value;
`
`generating an encrypted state token associated with the
`stored hidden field value;
`inserting the encrypted state token into the response,
`wherein the encrypted state token and response is sent to the
`client within a hidden form field of the response, if the
`response includes a form; within a query string of the
`response, if the response includes a link; or within a
`Uniform Resource Locator (URL) path within the response,
`if the response includes a URL; and
`allowing a subsequent request from the client to be forwarded
`to the application if the subsequent request includes the
`encrypted state token.
`
`1[e]
`
`1[f]
`
`1[g]
`
`1[h]
`
`1[i]
`
`1[j]
`
`1[k]
`
`
`
`7
`
`
`
`Feature 1
`
`Feature 2
`
`Feature 3
`
`
`Feature 4
`
`

`
`
`
`To begin, the patent discloses generating an “application model.” The
`
`application model represents valid “links” and allowable input and output
`
`parameters for the underlying web application. Id. at 7:4-12; 10:14-25.
`
`The application model may be generated automatically using, for example,
`
`standard “web crawlers, and similar applications, to probe a target application.” Id.
`
`at 2:66-3:1. The model may also be tuned manually by an administrator. Id. at 3:3-
`
`6; Fig. 7. HTTP requests are monitored and recorded, as well as HTTP responses.
`
`Id. at 3:18-21. As each web page is probed “an application model representing
`
`valid interconnections and allowable input and output parameters may be
`
`developed.” Id. at 3:21-25.
`
`When the application model is in active operation, “HTTP requests from
`
`users are intercepted and compared against the application model.” Id. at 3:26-28.
`
`For example, the application model may check whether a link in the request is
`
`allowable in order to prevent the user from “jumping” around within the
`
`application. Id. at 13:11-14.
`
`Alternatively, or in addition, the application model may verify that
`
`“application state data” sent to the web application server has not been
`
`inappropriately modified by a client. Id. at 2:55-58. Application “state data” or
`
`“state information” includes, but is not limited to, “form fields,” “values of the
`
`hidden fields,” “cookie values, session values, user-agent identification strings, and
`
`the like.” Id. at 10:59-65. Figure 4C, shown below gives examples of form fields
`8
`
`

`
`
`
`426 (highlighted) to be sent in an HTTP Request 422 intended for the URI
`
`‘http://www.abank.com/transfer.html’.
`
`
`
`If the request complies with the application model, it is forwarded to the web
`
`application server. Id., Fig. 14 (blocks 1402, 1404). The web application server
`
`then formulates and transmits a response back to the client. Id., Fig. 14 (block
`
`1406). But before the response reaches the client, it is intercepted by the
`
`application model, which then identifies state information such as hidden form
`
`values. Id. at 15:47-52, Fig. 14 (block 1408).
`
`The security system at this point creates an encrypted “identifying token”
`
`associated with the state information sent from the server to a client, and inserts it
`
`in the HTTP response so that the state information may later be retrieved and
`
`verified. Id. at 3:60-65, 15:53-60. For example, the token may be inserted as a
`
`hidden form filed. Id. at 16:43-47. The response is then forwarded to the client
`
`9
`
`

`
`
`
`with the encrypted token. Id. at 16:21-23. Subsequent requests from the client are
`
`intercepted by the security system and are verified for token. Id. at 16:25-29.
`
` A fulsome summary of the ’413 Patent is provided in expert declaration of
`
`Dr. Mohapatra (Ex. 1004, “Mohapatra Decl.”) at paragraphs 34-63.
`
`B.
`
`The ’413 Patent’s File History
`
`The ’413 Patent issued on December 30, 2008, from Patent Application No.
`
`10/915,951 (Ex. 1007, “’413 Prosecution History”), filed on August 11, 2004.
`
`Though in prosecution for a little more than four years, the ’413 Patent issued after
`
`two Office Actions.
`
`In the first Office Action, the Examiner rejected all the claims on the basis
`
`that, among other reasons, that the term “application model” was not well defined
`
`within the specification, and therefore did not satisfy the requirements of 35 U.S.C
`
`§ 112. Ex. 1007 at 79-80. The Applicant responded that “it is readily apparent to
`
`one of ordinary skill in the art, that an application model is ‘a model’ of
`
`characteristics of a target application (e.g., Applicant’s specification, page 4, lines
`
`19-20), including its allowed navigation paths, valid interconnections, allowable
`
`input and output parameters, and rules and constraints for the application being
`
`modeled.” Ex. 1007 at 106. Based on this representation, the Applicant traversed
`
`the Examiner’s objection under Section 112.
`
`10
`
`

`
`
`
`In the second Office Action, the Examiner took Official Notice that using a
`
`web crawler to automate a web process was old and well-known to persons of skill
`
`in the art:
`
`Official Notice is taken that using a web crawler to
`retrieve information about data fields is old and well
`known (see McGeachie [0053], for example), and it
`would have been obvious to one of ordinary skill in the
`art at the time of applicant's invention to employing a
`web crawler given the benefit of well known efficient
`automatic retrieving mechanism.
`
`Ex. 107 at 122. Applicant did not contest this factual finding by the Examiner.
`
`IV. A PERSON OF ORDINARY SKILL IN THE ART
`
`With respect to the ’413 Patent, Dr. Mohapatra confirms that a person of
`
`ordinary skill in the art (“POSITA”) would have a Bachelors or Master’s degree in
`
`computer science or computer engineering or in a related field, as well as about
`
`two years of experience in design and deployment of Internet networking
`
`technology. Mohapatra Decl. ¶ 18.
`
`V. CLAIM CONSTRUCTION (37 C.F.R. § 42.104(b)(3))
`
`Because the ’413 Patent has not yet expired, each claim is given “its
`
`broadest reasonable construction in light of the specification of the patent in which
`
`it appears” to one of ordinary skill in the art. 37 C.F.R. § 42.100(b). Under the
`
`broadest reasonable interpretation standard, “the claims must be interpreted as
`
`11
`
`

`
`
`
`broadly as their terms reasonably allow. . . . This means that the words of the claim
`
`must be given their plain meaning unless the plain meaning is inconsistent with the
`
`specification.” MPEP § 2111.01 (citing cases); see also In re Am. Acad. Of Sci.
`
`Tech Ctr., 367 F.3d 1359, 1369 (Fed. Cir. 2004) (“[T]he Board is required to use a
`
`different standard for construing claims than that used by district courts.”)
`
`(citations omitted).
`
`Radware’s proposed constructions are offered to comply with 37 C.F.R. §
`
`42.100(b) for this Petition only and do not necessarily reflect the claim
`
`constructions that may be proposed by Radware or adopted by the court in any
`
`district court litigation, where a different standard applies. Radware contends that
`
`all claim terms for which a construction is not specifically proposed should be
`
`interpreted according to their plain meaning.
`
`A.
`
`“Training Mode”
`
`To train an application model, “[it] can be operated in a training mode,
`
`which enables the new model to be tested and verified. Ex. 1001 at 3:1-3; 4:22-24.
`
`Claims 7, 15, and 23, in which “training mode” appears, specify that requests are
`
`evaluated for compliance, forwarded to the application regardless of compliance,
`
`and then used for modifying the application model. Id. This is consistent with the
`
`specification which states that “in ‘training mode,’ the invention may continue to
`
`monitor incoming and outgoing requests; however, it might not block non-
`
`compliant requests.” Id. at 4:24-29. Instead, non-compliant requests are
`12
`
`

`
`
`
`“recorded” so that an administrator may later review the non-compliant requests to
`
`verify the accuracy of the model, and—if necessary—correct for mistakes. Id. at
`
`4:30-42, 10:33-40.
`
`In addition, the Applicant stated during prosecution that “the term ‘a training
`
`mode” as used in claims 7, [15], and amended claim [23]…is well defined within
`
`the specification such that one of ordinary skill in the art would understand…the
`
`invention can be operated in a training mode, which enables the new model to be
`
`tested and verified.” Ex. 1007 at 1071. Thus, the broadest reasonable construction
`
`of “training mode,” as recited in claims 7, 15, and 23, is “a mode which enables the
`
`new application model to be tested and verified.” Mohapatra Decl. ¶ 70.
`
`B.
`
`“Security Mode”
`
`In addition to a “training mode,” Claim 23 also recites a “security mode,”
`
`which functions differently than the “training mode.” The main difference
`
`between the two modes is that the “training mode” forwards non-compliant
`
`requests to the application whereas the “security mode” blocks non-compliant
`
`requests. The specification confirms this difference: “In contrast to operating in
`
`secure mode, the invention, while operating in training mode, may allow non-
`
`compliant requests to pass-through to the web application unmodified.” Ex. 1001
`
`at 4:26-29. The specification also succinctly states that the “Security mode enables
`
`
`1 Claims 18 and 27 were later renumbered as claims 15 and 23. See Ex. 1007 at
`194.
`
`13
`
`

`
`
`
`the detection, recording, and blocking of non-compliant requests.” Id. at 11:30-37
`
`(emphasis added). Therefore, the broadest reasonable construction of the term
`
`“security mode,” as recited in claim 23, should be “a mode enabling the detection,
`
`recording, and blocking of non-compliant requests.” Mohapatra Decl. ¶ 73.
`
`VI. PRIOR ART BACKGROUND
`
`A.
`
`International Publication No. WO 03/058450 to Raanan et al.
`(“Raanan”) (Ex. 1011)
`
`The Raanan publication is a PCT titled “Method and System For Dynamic
`
`Refinement of Security Policies.” Ex. 1011. Like the ’413 Patent, Raanan is
`
`directed to improving the security of web applications and vulnerabilities inherent
`
`in client-server interactions. Raanan is prior art under 35 U.S.C. § 102(e) (Pre-
`
`AIA) because it has a publication date of July 17, 2003, and a priority date of
`
`December 31, 2001. Id.
`
`14
`
`

`
`
`
`
`
`Raanan teaches a network computer security system that solves the problem
`
`of clients attempting to illegally interact with the web application through “hidden
`
`field manipulation, parameter tampering, stealth commanding, and other methods.”
`
`Id. at 2:24-3:1. The system comprises an “application security 150 layer which
`
`includes a dynamic policy recognition engine 160” (id. at 6:9-10), that “generate[s]
`
`dynamic security policies and rules to identify and permit legal requests that a
`
`client may make of a server-based online application”. Id. at 4:17-19. In
`
`particular, “[t]he dynamic policy recognition engine, 160 analyzes requests, in
`
`accordance with a set of rules, or actions turned away and perhaps even those
`
`allowed by the application security layer and refines the security layer to reduce
`
`false negatives.” Id. at 6:10-13.
`
`15
`
`

`
`
`
`Raanan further teaches using an “automatic [web] crawler” to “create a large
`
`rule set of legal requests [from clients to web application servers that] can be
`
`accurately, safely, and automatically determined in a short period of time.” Id. at
`
`14:1-7. The set of legal requests are referred to as “the security policy rule set” for
`
`the application. Id. at 10:8-20. “The security policy rule set identifies a set of legal
`
`actions that the user may potentially take and accordingly pass as a request from
`
`the network client sending the request to the online application.” Id. at 10:9-11;
`
`Fig. 2.
`
`Raanan also teaches the security policy rule set can be refined either
`
`automatically or manually based on the error-logs/collections of transaction
`
`
`
`16
`
`

`
`
`
`requests. Id. at 4:4-21; 14:1-14. To automatically refine the rule set of legal
`
`requests, Raanan discloses grouping log entries by common characteristics and
`
`analyzing the resulting groups to amend the policy rule set. Id. at Abstract.
`
`Moreover, when the automatic web crawler is “run as a trusted client, none of
`
`whose requests are rejected by the rule set.” Id. at 14:2-3. To manually refine the
`
`rule set, Raanan discloses Rules Manager 290. “The rule manager is a user
`
`interface application that allows the user to adjust, for example, the various
`
`heuristics and parameters used to dynamically create or refine rules for the security
`
`policy rule set, the ability to identify and separate rules created manually from
`
`those created dynamically, and other similar administrative features.” Id. at 14:1-
`
`12.
`
`
`
`17
`
`

`
`
`
`Next, Raanan discloses intercepting HTTP requests made by the network
`
`clients to the application server. Id. at 10:3-7, Figs. 1, 3 (step 310). After a request
`
`is intercepted, “it is filtered according to the security policy rule set” Id. at 10:8-9,
`
`Fig. 3 (step 320). “If a request is identified as legal according to the security
`
`policy rule set, then the request is passed to the online application for processing.”
`
`Id. at 10:14-15. “If the request does not match any of the rules contained in the
`
`security policy rule set, however, then the request will be treated as an illegal
`
`request and it will be denied.” Id. at 10:15-17. In addition, information from an
`
`illegal request is extracted and used to create and error log entry and made
`
`available for use in the dynamic refinement process. Id. at 10:17-19, Fig. 4.
`
`After a request is forwarded to the application, Raanan teaches receiving a
`
`response to the request from the application. Id., Figs. 1, 2.
`
`Raanan also incorporates U.S. Patent No. 6,311,278 (Ex. 1012, “’278
`
`Patent”) in its entirety:
`
`This application is related to United States Patent No.
`6,311,278,
`titled METHOD AND SYSTEM FOR
`EXTRACTING
`APPLICATION
`PROTOCOL
`CHARACTERISTICS, filed July 1, 1999, issued October
`30, 2001, which is hereby incorporated herein by
`reference in its entirety.
`
`18
`
`

`
`
`
`Id. at 1:14-17. Because Raanan provides improvements over the ’278 Patent by
`
`teaching an automatic refinement of the security policies (Ex. 1011 at 4:1-13), a
`
`POSITA reading Raanan would therefore understand that he or she should also
`
`review the ’278 Patent for further information and discussion about the disclosed
`
`“Method and System For Dynamic Refinement of Security Policies.” Mohapatra
`
`Decl. ¶ 115. In addition, the named inventor of the Raanan PCT is also a named
`
`inventor of the ’278 patent.
`
`Although the ’278 Patent was previously considered by the Patent Office,
`
`the Raanan PCT—which improves on the ’278 patent—was not. As a result,
`
`Raanan is not cumulative of ’278 Patent and the Patent Office never had the
`
`benefit of considering the improvements made in the Raanan PCT. Id. ¶ 116.
`
`Ex. 1012 (’278 Patent) Fig. 2A (annotated).
`
`
`
`19
`
`

`
`
`
`
`
`Id. Fig. 2 (annotated).
`
`Raanan through, incorporation of the ’278 Patent, teaches “a dynamic
`
`security algorithm and system that extracts the security policy out of outgoing web
`
`pages leaving the application server and being sent to the network client such as
`
`the requesting Internet browser.” Ex. 1011 at 4:1-4; Ex. 1012 at Abstract. As
`
`shown in figures 2A and 2 above, gateway 14a with a “protocol extraction module
`
`18 intercepts server messages,” and “check[s] for forms, fields, fixed fields, hidden
`
`fields, menu options, DOM components, etc.” Ex. 1012 at 4:46-47; 5:61-63; Figs.
`
`2A, 2, and 3. “[F]or all hidden fields identified, the [protocol] database [16] will
`
`be updated as to their nature and that the client may not change their content.” Id.
`
`at 5:63-67; Fig. 4
`
`20
`
`

`
`
`
`
`
`Once the gateway receives a client request, it compares each link, data,
`
`command, or other action in the request with the corresponding entities now stored
`
`in the protocol database 16. Id. at 6:7-10; Fig. 4 (steps 80 and 82). If no
`
`disallowed actions are in the request, the request is transmitted to the server. Id. at
`
`6:10-11. Otherwise, the entire request is denied. Id. at 6:11-14; Fig. 4 (step 86).
`
`21
`
`

`
`
`
`B. U.S. Published Application No. 2003/0051142 A1 to Hidalgo et al.
`(“Hidalgo”) (Ex. 1013)
`
`Hidalgo is a published patent application titled “Firewalls for Providing
`
`Security in HTTP Networks and Applications.” Hidalgo is prior art under 35
`
`U.S.C. § 102(e) because it has a publication date of March 13, 2003, and a filing
`
`date of May 16, 2001.
`
`The Hidalgo patent publication, like the Raanan PCT and the ’413 Patent, is
`
`directed to improving the security of web applications and vulnerabilities inherent
`
`in client-server interactions. Specifically, Hidalgo discusses a security system for
`
`preventing attacks involving “vulnerable sample applications, content server
`
`implementation problems, cookie poisoning, input validation, hidden field
`
`tampering, buffer overflows, cross-site scripting, and back door attacks.” Ex. 1013
`
`¶¶ 14, 59-67. To solve “hidden field tampering,” Hidalgo discloses inserting an
`
`encrypted signature with hidden field values:
`
`22
`
`

`
`
`
`Hidden field tampering is yet another example of an
`application of the invention. Applications store session
`information on “hidden” form fields. These fields are not
`displayed to an end user but are accessible in the HTML
`page source code or in the URL bar of the browser so
`they are easily modified by a malicious user. The systems
`and methods protect modification of these fields by using
`the content signatures so they can't be modified and if
`they are modified an alert is logged and the attack
`blocked.
`
`Id. at ¶ 63(emphasis added).
`
`The signature is encrypted and sent to a client along with
`the content of the page. When a client later sends a
`request, the system checks the signature associated with
`that request with the contents of the request itself.
`
`Id. Abstract (emphasis added).
`
`Hidalgo teaches a web application security system for analyzing responses
`
`sent from a server and inserting encrypted signatures to send to the client along
`
`with the contents of the response. Id. Figure 4 below shows the security system 20
`
`interposed between a server 26, and various clients 24a-e. The security system
`
`may be a physically separate device or co-resident with the application server 26
`
`(as a security module of an integrated device). Id. at ¶¶ 69-73.
`
`23
`
`

`
`
`
`
`
`“When the [security] system 20 detects that a form is being sent to the
`
`remote user, the system 20 intercepts the response from the server 26.” Id. at 159.
`
`“[T]he system analyses the content that is being sent to the client 24.” The
`
`analyzed content includes state data (e.g., name, count, price, action, file) in hidden
`
`field values like as follows:
`
`24
`
`

`
`
`
`Id. ¶ 159.
`
`
`
`Next, the system abstracts the content and generates an encrypted signature
`
`from that abstraction. Id. at ¶ 77; Figs. 5(A) and 6(A). This encrypted signature
`
`allows for detection and avoidance of form field manipulation. Id. at 159.
`
`Because the encrypted signature is an abstraction of the content, content such as
`
`hidden field values are stored with the encrypted signature. Mohapatra Decl. ¶
`
`123. The abstraction may include a description of each argument, including name,
`
`value, size, and if the field is optional or required. Id. at 161; Figs 5(A) and 6(A).
`
`The analysis and abstraction of the form for this example is shown below in table
`
`2.
`
`25
`
`

`
`
`
`
`
`
`
`Id. at ¶ 161. It includes hidden fields such as “name” and “price,” their values
`
`(“Apples” and “100”), and whether these fields are optional. This abstraction is
`
`serialized, encrypted, and embedded inside the form of a hidden tag called
`
`“HIVEDATA”. Id. at ¶ 161; Figs. 5(A) and 6(A). An example of the HIVEDATA
`
`tag is as follows:
`
`Id. at ¶ 162.
`
`
`
`When the client sends the encrypted signature with anot