`Tel: 571-272-7822
`
`
`
`Paper 10
`Entered: July 31, 2017
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_______________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_______________
`
`RADWARE INC.,
`Petitioner,
`
`v.
`
`F5 NETWORKS, INC.,
`Patent Owner.
`_______________
`
`Case IPR2017-00653
`Patent 7,472,413 B1
`
`Case IPR2017-00654
`Patent 7,472,413 B1
`_______________
`
`
`Before KRISTEN L. DROESCH, TRENTON A. WARD, and
`DAVID C. McKONE, Administrative Patent Judges.
`
`WARD, Administrative Patent Judge.
`
`
`
`DECISION1
`Denying Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`1 This Decision addresses the same legal and factual issues raised in
`IPR2017-00653 and IPR2017-00654. The same patent is at issue in both
`cases, and many of the arguments made by the parties are the same in both
`cases. Therefore, we issue one Decision to be entered in both cases.
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`
`A. Background
`
`I.
`
`INTRODUCTION
`
`Radware, Inc. (“Petitioner”) filed a Petition requesting an inter partes
`
`review of claims 1–24 of U.S. Patent No. 7,472,413 B1 (Ex. 1001,
`
`“the ’413 patent”) pursuant to 35 U.S.C. §§ 311–319. IPR2017-00653,
`
`Paper 2 (“Pet.”).2 F5 Networks, Inc. (“Patent Owner”) filed a Preliminary
`
`Response. IPR2017-00653, Paper 7 (“Prelim. Resp.”). With authorization
`
`from the Board, Petitioner filed a Reply to Patent Owner’s Preliminary
`
`Response. IPR2017-00653, Paper 9 (“Reply”). Petitioner also filed a
`
`second Petition requesting an inter partes review of claims 1–24 of
`
`the ’413 patent in IPR2017-00654. IPR2017-00654, Paper 2 (“’654 Pet.”).
`
`Patent Owner filed a Preliminary Response to this second Petition.
`
`IPR2017-00654, Paper 7 (“’654 Prelim. Resp.”). Also, with authorization
`
`from the Board, Petitioner filed a Reply to Patent Owner’s Preliminary
`
`Response. IPR2017-00654, Paper 9 (“’654 Reply”). We have statutory
`
`authority under 35 U.S.C. § 314(a), which provides that an inter partes
`
`review may not be instituted “unless . . . there is a reasonable likelihood that
`
`the petitioner would prevail with respect to at least 1 of the claims
`
`challenged in the petition.” See also 37 C.F.R § 42.4(a) (delegating
`
`authority to the Board).
`
`Upon consideration of the Petition, Patent Owner’s Preliminary
`
`Response, Petitioner’s Reply to the Preliminary Response, and the
`
`
`2 For clarity and expediency, we treat IPR2017-00653 as representative of
`IPR2017-00654. Unless indicated otherwise, all citations are to papers and
`exhibits filed in IPR2017-00653.
`
`2
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`associated evidence filed in both IPR2017-00653 and IPR2017-00654, we
`
`conclude Petitioner has failed to demonstrate a reasonable likelihood in
`
`either case that it would prevail with respect to at least one of the challenged
`
`claims. Accordingly, for the reasons that follow, we deny institution of an
`
`inter partes review in both IPR2017-00653 and IPR2017-00654.
`
`B. Related Matters
`
`Petitioner and Patent Owner indicate that Patent Owner asserted the
`
`’413 patent against Petitioner in F5 Networks, Inc. v. Radware, Inc., Case
`
`No. 16-cv-480-RAJ, in the Western District of Washington. Pet. 1; Paper 3,
`
`1. Patent Owner also indicates that U.S. Patent No. 9,003,509 is a
`
`continuation of the ’413 patent. Paper 3, 1.
`
`C. The ’413 Patent
`
`The ’413 patent is titled “Security for WAP Servers” and generally
`
`relates to computing software and systems for managing internet website
`
`and web application security and for preventing website and web application
`
`users from causing harm. Ex. 1001, [54], 1:14–17. The challenged claims
`
`relate to creating a model of an application and using that model to validate
`
`requests from web clients before the request reaches a web application
`
`server. As noted above, Petitioner challenges claims 1–24, of which claims
`
`1, 12, 16, and 23 are independent. Independent claim 1 is representative and
`
`reproduced below:
`
`1. A method of managing a communication over a network,
`comprising:
`
`generating an application model based on interactions with
`an application over the network;
`
`3
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`
`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;
`
`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.
`
`Id. at 17:42–67.
`
`The ’413 patent describes improving the security and control of web
`
`applications by intercepting incoming web client requests that are non-
`
`compliant with the application model before the request reaches the web
`
`application server. Id. at Abstr. Figure 6 of the ’413 patent is reproduced
`
`below.
`
`4
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`
`
`
`Id. at Fig. 6. Figure 6 is a functional block diagram of an embodiment of the
`
`invention operating in security mode. Id. at 8:63–64. As shown above in
`
`Figure 6, web application security system 606 is configured to intercept
`
`incoming messages from network 604 originating from web client 602, as
`
`well as outgoing messages from web application server 616. Id. at 8:64–9:3.
`
`The ’413 patent discloses generating application model 610 using a
`
`“web crawler,” which automatically surveys and processes the target
`
`application. Id. at 3:15–18; see id. at 9:42–10:25. Application model 610
`
`may employ application state information to determine if an incoming HTTP
`
`5
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`request includes data that has been inappropriately altered. Id. at 14:1–4.
`
`Once an application model has been newly generated, system 606 may
`
`operate in a “training mode,” which enables the new model to be tested,
`
`verified, and tuned. Id. at 3:1–6; see id. at 10:27–11:28.
`
`In a “security mode” operation, when web client 602 sends an HTTP
`
`request to the web application, the HTTP request is intercepted by external
`
`gateway 608 of web application security system 606. Id. at 11:30–45. The
`
`incoming request is examined in order to determine whether the request is
`
`compliant with application model 610. Id. at 11:45–50. If the request is
`
`compliant, the request is allowed to continue to web application server 616.
`
`Id. at 11:50–53. Requests that are non-compliant with application model
`
`610 are blocked before reaching server 616. Id. at 11:31–35.
`
`An HTTP response from the web application to web client 602 is
`
`intercepted by internal gateway 614. Id. at 11:53–58. “[N]ames and values
`
`of outbound fields and parameters may be recorded to maintain a record of
`
`the application state.” Id. at 11:58–60. An encrypted state token may be
`
`injected into the HTTP response using a cookie, hidden form field, query
`
`string, or URL path. Id. at 16:30–17:9.
`
`Upon subsequent HTTP requests sent from web client 602 to web
`
`application server 616, the encrypted state token is sent back to server 616
`
`along with the HTTP request. Id. at 3:60–4:1; 16:25–29. Expected values
`
`for hidden fields, associated with client 602’s HTTP request, can be
`
`retrieved using the encrypted state token. Id. at 4:1–3. “If the hidden values
`
`in the incoming submitted HTTP request are not compliant with the hidden
`
`data values retrieved from the application state database, the incoming
`
`6
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`request may be blocked before it reaches the web application server(s).” Id.
`
`at 4:3–7.
`
`D. The Asserted Grounds of Unpatentability
`
`Petitioner challenges the patentability of claims 1–24 of the
`
`’413 patent based on the following grounds:
`
`Reference(s)
`
`Basis
`
`Claim(s)
`Challenged
`1–5, 7–12, 14–
`20, 22, and 23
`
`§ 102 or
`§ 103
`
`IPR
`No.
`’653
`
`Ground
`No.
`1
`
`2
`
`3
`
`Scott (II)3 as evidenced by
`Scott4 or, in the
`alternative, Scott (II) in
`view of Scott
`Scott (II) in view of Scott
`and further in view of
`Monier5
`Scott (II) in view of Scott
`and further in view of
`Rapoza6
`
`§ 103
`
`6 and 12–24
`
`§ 103
`
`7, 15, and 23
`
`
`3 David Scott & Richard Sharp, SPECTRE: A Tool for Inferring, Specifying
`and Enforcing Web-Security Policies (Ex. 1010) (“Scott (II)”).
`
`4 David Scott & Richard Sharp, Abstracting Application-Level Web Security,
`WWW ’02 PROCEEDING OF THE 11TH INTERNATIONAL CONFERENCE ON
`WORLD WIDE WEB, 396–407 (Ex. 1009) (“Scott”).
`
`5 U.S. Patent No. 6,032,196 (Feb. 29, 2000) (Ex. 1017) (“Monier”).
`
`6 Jim Rapoza, Sanctum’s Simple Approach to Security, eWEEK, Vol. 19,
`No. 21, 55–56 (Ex. 1014) (“Rapoza”).
`
`7
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`
`IPR
`No.
`’654
`
`Ground
`No.
`1
`
`2
`
`Raanan7 in view of
`Hidalgo8
`Raanan in view of Hidalgo
`and further in view of
`Rapoza
`
`Reference(s)
`
`Basis
`
`Claim(s)
`Challenged
`1–24
`
`§ 103
`
`§ 103
`
`7, 15, 23, and 24
`
`Pet. 3–4; ’654 Pet. 3.
`
`
`
`II. ANALYSIS
`
`A. Claim Construction
`
`Consistent with the statute and the legislative history of the Leahy-
`
`Smith America Invents Act,9 the Board will interpret claims of an unexpired
`
`patent using the broadest reasonable construction in light of the
`
`Specification of the patent. 37 C.F.R. § 42.100(b); Cuozzo Speed Techs.,
`
`LLC v. Lee, 136 S. Ct. 2131, 2144–46 (2016) (upholding the use of the
`
`broadest reasonable interpretation standard as the claim interpretation
`
`standard to be applied in inter partes reviews). We determine that no
`
`explicit claim construction is required for purposes of this decision.
`
`B. Principles of Law
`
`A claim is unpatentable under 35 U.S.C. § 102 if a single prior art
`
`reference either expressly or inherently discloses every limitation of the
`
`claim. Orion IP, LLC v. Hyundai Motor Am., 605 F.3d 967, 975 (Fed. Cir.
`
`
`7 International Publication No. WO 03/058450 A1 (July 17, 2003) (’654
`Ex. 1011) (“Raanan”).
`
`8 U.S. Published Application No. 2003/0051142 A1 (Mar. 13, 2003) (’654
`Ex. 1013) (“Hidalgo”).
`
`9 Pub. L. No. 112-29, 125 Stat. 284 (2011).
`
`8
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`2010). A claim is unpatentable under 35 U.S.C. § 103(a) if the differences
`
`between the subject matter sought to be patented and the prior art are such
`
`that the subject matter as a whole would have been obvious at the time the
`
`invention was made to a person having ordinary skill in the art to which said
`
`subject matter pertains. KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406
`
`(2007). The question of obviousness is resolved on the basis of underlying
`
`factual determinations, including (1) the scope and content of the prior art;
`
`(2) any differences between the claimed subject matter and the prior art;
`
`(3) the level of skill in the art; and (4) objective evidence of nonobviousness,
`
`i.e., secondary considerations. See Graham v. John Deere Co., 383 U.S. 1,
`
`17–18 (1966).
`
`“In an [inter partes review], the petitioner has the burden from the
`
`onset to show with particularity why the patent it challenges is
`
`unpatentable.” Harmonic Inc. v. Avid Tech., Inc., 815 F.3d 1356, 1363
`
`(Fed. Cir. 2016) (citing 35 U.S.C. § 312(a)(3) (requiring inter partes review
`
`petitions to identify “with particularity . . . the evidence that supports the
`
`grounds for the challenge to each claim”)). This burden never shifts to
`
`Patent Owner. See Dynamic Drinkware, LLC v. Nat’l Graphics, Inc., 800
`
`F.3d 1375, 1378 (Fed. Cir. 2015) (citing Tech. Licensing Corp. v. Videotek,
`
`Inc., 545 F.3d 1316, 1326–27 (Fed. Cir. 2008)) (discussing the burden of
`
`proof in inter partes review). Furthermore, Petitioner cannot satisfy its
`
`burden of proving obviousness by employing “mere conclusory statements.”
`
`In re Magnum Oil Tools Int’l, Ltd., 829 F.3d 1364, 1380 (Fed. Cir. 2016).
`
`Thus, to prevail in an inter partes review, Petitioner must explain how
`
`the proposed combinations of prior art would have rendered the challenged
`
`9
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`claims unpatentable. At this preliminary stage, we determine whether the
`
`information presented in the Petition shows there is a reasonable likelihood
`
`that Petitioner would prevail in establishing that one of the challenged
`
`claims would have been obvious over the proposed combinations of prior
`
`art.
`
`We analyze the challenges presented in each Petition in accordance
`
`with the above-stated principles.
`
`C. Level of Ordinary Skill in the Art
`
`According to Petitioner’s Declarant, Dr. Mohapatra, “a person having
`
`ordinary skill in the art [] at the time of the invention of the ’413 Patent
`
`would have a Bachelor’s 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.”
`
`Ex. 1004 ¶ 18. Patent Owner’s Declarant, Dr. Foster, adopts
`
`Dr. Mohapatra’s formulation. Ex. 2013 ¶ 17.
`
`Based on our review of the ’413 patent, the types of problems and
`
`solutions described in the ’413 patent and cited prior art, and the testimony
`
`of Petitioner’s Declarant and Patent Owner’s Declarant, we adopt, for
`
`purposes of this Decision, Petitioner’s definition of a person of ordinary skill
`
`in the art at the time of the claimed invention. Based on the stated
`
`qualifications of Dr. Mohapatra (Ex. 1004 ¶¶ 4–15) and Dr. Foster (Ex. 2013
`
`¶¶ 3–10), we determine that Petitioner’s Declarant meets the requirements of
`
`this definition and Patent Owner’s Declarant meets the requirements of this
`
`definition. We note that the applied prior art also reflects the appropriate
`
`10
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`level of skill at the time of the claimed invention. See Okajima v.
`
`Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001).
`
`D. ’653 Ground 1: Asserted Anticipation of Claims 1–5, 7–12, 14–20,
`22, and 23 by Scott (II) or Obviousness over Scott (II) and Scott
`
`Petitioner argues that claims 1–5, 7–12, 14–20, 22, and 23 are
`
`anticipated by Scott (II) as evidenced by Scott or, in the alternative, would
`
`have been obvious over Scott (II) and Scott. Pet. 25–60.
`
`1. Overview of Scott (II)
`
`
`
`Scott (II), titled “SPECTRE: A Tool for Inferring, Specifying and
`
`Enforcing Web-Security Policies” and discloses application-level web
`
`security techniques including programming an application-level firewall, or
`
`“security gateway,” with security policies written in Security-Policy
`
`Description Language (SPDL). Ex. 1010, 2, 4 n.3. Scott (II) discloses the
`
`implementation of application-level web security techniques in the form of a
`
`tool known as SPECTRE. Id. at 2. SPECTRE includes an automatic
`
`security-policy inference feature in which it “dynamically analyses the
`
`interactions between a web-application and its clients in order to generate a
`
`simple SPDL policy automatically.” Id. at 4. “[T]he [security policy]
`
`inference engine keeps track of the type of data passed, maintains upper and
`
`lower bounds on the length of data and records whether or not [a] parameter
`
`is always present in requests for a particular URL.” Id.
`
`2. Overview of Scott
`
`Scott is a paper titled “Abstracting Application-Level Web Security”
`
`and addresses the problem of application-level web security holes by
`
`disclosing a specialized Security-Policy Description Language (SPDL) for
`
`programming an application-level firewall, or “security gateway.” Ex. 1009,
`
`11
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`396. “Security policies are written in SPDL and compiled for execution on
`
`the security gateway. The security gateway dynamically analyses and
`
`transforms HTTP requests/responses to enforce the specified policy.” Id. at
`
`396.
`
`Figure 1 of Scott is reproduced below.
`
`
`
`Id. at Fig. 1. As shown above in Figure 1, the security gateway is positioned
`
`between a web-server and client machines. Id. at 398.
`
`
`
`Upon receipt of an HTTP request, “appropriate validation rules and
`
`transformations to apply” are selected. Id. at 401. “If the URL does not
`
`match any of those specified in the security policy then the request is not
`
`propagated to the web-server and an error page is returned to the user.” Id.
`
`Once a valid URL is identified,
`
`the security gateway proceeds to check the names of all
`parameters and cookies passed in the HTTP request. Errors are
`generated if (i) any of the parameters present are not declared in
`
`12
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`
`the SPDL policy; (ii) any of the required parameters are missing;
`or (iii) the cookies present do not precisely match those specified
`in the SPDL specification. Once we are sure that the HTTP
`message contains a valid combination of cookies and GET/POST
`parameters, type and length constraints are checked. If any
`violations occur at this stage then a descriptive error message is
`returned to the client.
`
`Id.
`
`
`
`The security gateway also processes HTTP responses returned from
`
`the web server, and “message authentication codes are generated for form
`
`fields.” Id. at 401–402. “As data is sent to the client, the security gateway
`
`annotates it with MACs; as data is returned from clients the MACs are
`
`checked. In this way we prevent users from modifying data which should
`
`not be changed on the client-side (e.g. security-critical hidden form-fields).”
`
`Id. at 402.
`
`3. Analysis of Alleged Anticipation by Scott (II) and Scott
`
`Petitioner argues that for purposes of its anticipation challenge, the
`
`“Scott and Scott (II) papers (Exs. 1009 and 1010) constitute a single
`
`reference.” Pet. 25 (emphasis added). More particularly, Petitioner argues
`
`that Scott (II) directs a person of ordinary skill in the art to “Scott for details
`
`on the implementation of the security gateway” and “therefore, incorporates
`
`the Scott paper in its entirety.” Id. (citing Ex. 1010, 2 n.3).
`
`“[A]nticipation requires that the four corners of a single, prior art
`
`document describe every element of the claimed invention, either expressly
`
`or inherently, such that a person of ordinary skill in the art could practice the
`
`invention without undue experimentation” but “[m]aterial not explicitly
`
`contained in the single, prior art document may still be considered for
`
`purposes of anticipation if that material is incorporated by reference into the
`
`13
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`document.” Advanced Display Sys., Inc. v. Kent State Univ., 212 F.3d 1272,
`
`1282 (Fed. Cir. 2000) (citations omitted). “To incorporate material by
`
`reference, the host document must identify with detailed particularity what
`
`specific material it incorporates and clearly indicate where that material is
`
`found in the various documents.” Id. (emphasis added). A “mere reference
`
`to another application, or patent, or publication is not an incorporation of
`
`anything therein.” In re De Seversky, 474 F.2d 671, 674 (CCPA 1973).
`
`Petitioner cites to page 2, footnote 3 of Scott (II) as providing the
`
`statement incorporating Scott by reference. Pet. 25. Although not
`
`specifically identified by Petitioner, we note that cited page 2 in Scott (II)
`
`provides the following references to footnote 3: (1) “[i]n a previous work
`
`we propose a framework to alleviate these problems [3].” and (2) “[t]he
`
`details of SPDL are described fully in [3].” Ex. 1010, 2. We further note
`
`that footnote 3 of Scott (II) states:
`
`SCOTT, D. AND SHARP, R. Abstracting application-level web security.
`Tech. Rep. 2001.11, AT&T Laboratories Cambridge, November 2001.
`Also submitted for publication.
`
`Ex. 1010, 4 n.3. Petitioner fails to identify any express statement in
`
`Scott (II) that Scott is “incorporated by reference.” Furthermore, Petitioner
`
`offers only the conclusory statement that Scott (II) incorporates the Scott
`
`paper in its entirety, and Scott (II) fails to identify with detailed particularity
`
`what specific material it incorporates or where the material is found in Scott.
`
`Pet. 25. We determine, based on this record, that the limited statements in
`
`Scott (II) relied upon by the Petitioner amount to a mere reference to Scott,
`
`not an incorporation of anything therein.
`
`14
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`
`Additionally, the reference identified in footnote 3 of Scott (II) as a
`
`2001 document appears to be the same reference identified in Petitioner’s
`
`List of Exhibits as Exhibit 1022. See Pet. 70, List of Exhibits; Ex. 1022.
`
`The Scott reference dated 2001, provided as Exhibit 1022, is a different
`
`document than the Scott reference dated 2002, provided as Exhibit 1009 and
`
`relied upon by Petitioner in its challenges. Compare Ex. 1009, 1, with
`
`Ex. 1022, 1. Petitioner fails to provide any explanation as to the similarities,
`
`or dissimilarities, in Exhibits 1009 and 1022. Furthermore, Petitioner fails
`
`to explain how citation of Exhibit 1022 in Scott (II) amounts to an
`
`incorporation by reference of the entirety of Exhibit 1009. See Pet. 13.
`
`
`
`Based on the foregoing, we are not persuaded that Petitioner
`
`establishes sufficiently that Scott (II) and Scott constitute a single reference
`
`for purposes of its anticipation challenge. Accordingly, we determine that
`
`Petitioner has failed to establish a reasonable likelihood it would prevail in
`
`showing that claims 1–5, 7–12, 14–20, 22, and 23 are anticipated by
`
`Scott (II) as evidenced by Scott.
`
`4. Analysis of Alleged Obviousness over Scott (II) and Scott
`
`In addition to its anticipation argument, Petitioner argues that Scott
`
`and Scott (II) constitute prior art under 35 U.S.C. § 103. Pet. 26. Petitioner
`
`further argues that claims 1–5, 7–12, 14–20, 22, and 23 would have been
`
`obvious over of Scott (II) and Scott. Pet. 27.
`
`With respect to claim 1, Petitioner argues that Scott’s disclosure of a
`
`Security Gateway with a Security Policy for managing communications over
`
`a network teaches the “method of managing a communication over a
`
`network,” recited in claim 1. Pet 27 (citing Ex. 1009, 398).
`
`15
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`
`Claim 1 also requires “examining the response for state data,
`
`including at least a hidden field value within the response.” With respect to
`
`this claim limitation, Petitioner cites Scott’s disclosure that “[t]he security
`
`gateway processes HTTP responses returned from the web-server” and that
`
`“message authentication codes are generated for form fields.” Pet. 33
`
`(quoting Ex. 1009, 401-402). Closer review of the quoted portions of Scott
`
`reveal that Scott discloses that “finally, message authentication codes are
`
`generated for form fields and URL parameters (see Section 3.4.2) if
`
`required.” Ex. 1009, 402. Significantly, we note that although this section
`
`of Scott discloses that message authentication codes are generated “for form
`
`fields,” this passage in Scott does not disclose that a response from the web-
`
`server is “examined for state data, including at least a hidden field value,” as
`
`required by claim 1. See Ex. 1009, 402. In other words, Petitioner has not
`
`established sufficiently that annotating a form with a message authentication
`
`code is equivalent to examining a response for state data, as required by
`
`claim 1.
`
`With respect to the “examining” step of claim 1, Petitioner also cites
`
`Scott’s disclosure that “[a]s a final step in the purchasing transaction, users
`
`are sent an HTML form requesting their surname, credit-card number and its
`
`expiry date. The price and product-ID are stored in hidden form fields on
`
`the form.” Pet. 33 (quoting Ex. 1009, 403). Petitioner offers no explanation
`
`of how this disclosure in Scott teaches the claimed recitation of “examining
`
`the response for state data, including at least a hidden field value within the
`
`response,” as required by claim 1. Closer evaluation of Scott reveals that the
`
`cited passage is provided in a section entitled “Case Study” and follows a
`
`16
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`statement that to “illustrate our methodology we consider . . . the following
`
`scenario.” Ex. 1009, 403. In describing the scenario for the “Case Study,”
`
`Scott further states that “[f]or example, when purchasing a product with
`
`product-ID = 144264, the form sent to the client is as follows”:
`
`
`
`Ex. 1009, 403. Although the disclosed scenario in Scott provides that the
`
`form sent to the client includes hidden fields, including price and productID,
`
`Petitioner fails to identify sufficiently any disclosure in Scott that this form
`
`is a “response” that is examined “for state data, including at least a hidden
`
`field value,” as required by claim 1. The cited disclosure in Scott merely
`
`identifies the contents of an example form to be sent to a client but fails to
`
`disclose examining the response for state data, much less examining the
`
`response for a hidden field value. Accordingly, we are not persuaded the
`
`Petitioner establishes sufficiently that the combination of Scott (II) and Scott
`
`teaches the claim 1 recitation of “examining the response for state data,
`
`including at least a hidden field value.”
`
`Claim 1 also recites “generating an encrypted state token associated
`
`with the stored hidden field value.” Thus, claim 1 requires that the hidden
`
`field value that results from the “examining” step in claim 1 is then relied
`
`upon in the generation of “an encrypted state token.” With respect to this
`
`generating step, Petitioner cites to the disclosure in Scott that the security
`
`gateway annotates the HTML in HTTP responses by annotating it with a
`
`17
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`“Message Authentication Code” (“MAC”). Pet 34 (citing Ex. 1009, 398).
`
`Petitioner contends that the following passage in Scott “discloses that
`
`MACS are associated with ‘hidden form-fields’”:
`
`As data is sent to the client, the security gateway annotates it
`with MACs, as data is returned from clients the MACS are
`checked. In this way we prevent users from modifying data
`which should not be changed on the client side (e.g. security-
`critical hidden form-fields).
`
`Pet. 34 (quoting Ex. 1009, 402) (emphasis added). Claim 1 requires
`
`“examining the response for state data, including at least a hidden field
`
`value,” “storing the hidden field value,” and “generating an encrypted state
`
`token associated with the stored hidden field value.” Although the cited
`
`disclosure in Scott states that the MACs are to be used to “prevent users
`
`from modifying data” including “security-critical hidden form-fields,” this
`
`disclosure does not indicate that the MACs are somehow “associated with
`
`the stored hidden field value” that resulted from examining the state data, as
`
`required by claim 1. See Ex. 1009, 402.
`
`Petitioner further cites to the disclosure in Scott that the “value of
`
`mac(l) is calculated as the MD5-hash [25] of a string containing the values
`
`of l concatenated together along with a time-stamp and a secret,” and that
`
`the “secret is a value which is not known by the client.” Pet. 34–35 (quoting
`
`Ex. 1009, 402). Petitioner fails to provide any explanation as to how the
`
`“secret” disclosed in Scott constitutes the claimed “hidden field value” or
`
`how this disclosure in Scott teaches that the MAC is generated in association
`
`with a stored hidden field value. See Pet. 34–35. Accordingly, we are not
`
`persuaded the Petitioner established sufficiently that the combination of
`
`18
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`Scott (II) and Scott teaches the claim 1 recitation of “generating an
`
`encrypted state token associated with the stored hidden field value.”
`
`The remaining challenged independent claims, claims 12, 16, and 23,
`
`provide similar recitations to those discussed above in claim 1. See claim 12
`
`(“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”),
`
`claim 16 (“embedding within the response a state token within a hidden
`
`form field of the response . . . herein the state token is generated based on
`
`the hidden field value within the response”), and claim 23 (“examining the
`
`response for state data, including at least a hidden field value within the
`
`response; generating an encrypted state token associated with the stored
`
`hidden field value”). Petitioner’s contentions for these limitations of
`
`independent claims 12, 16, and 23 are the same or similar to its contentions
`
`made for claim 1 with respect to the challenge of obviousness over Scott (II)
`
`and Scott. See Pet. 45–47, 49–60. Therefore, we are not persuaded by
`
`Petitioner’s contentions with respect to independent claims 12, 16, and 23
`
`for the same reasons stated above with respect to claim 1. Additionally, we
`
`are not persuaded for the same reasons stated above with respect to the
`
`challenged dependent claims 2–5, 7–11, 14–15, 17–20, and 22 which depend
`
`from these independent claims.
`
`
`
`Accordingly, we determine that Petitioner has failed to establish a
`
`reasonable likelihood it would prevail in showing that claims 1–5, 7–12, 14–
`
`20, 22, and 23 would have been obvious over Scott (II) and Scott.
`
`19
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`
`E. ’653 Ground 2: Asserted Obviousness of Claims 6 and 12–24 over
`Scott (II), Scott, and Monier
`
`1. Overview of Monier
`
`
`
`Monier is U.S. patent titled “System for Adding a New Entry to a
`
`Web Page Table Upon Receiving a Web Page Including a Link to Another
`
`Web Page Not Having a Corresponding Entry in the Web Page Table” and
`
`discloses “web crawlers” as known systems for locating pages on the World
`
`Wide Web. Ex. 1017, [54], 1:53–54. As disclosed by Monier, a web
`
`crawler fetches web pages and analyzes their links to other pages. Id. at
`
`1:64–65. A disk file is created with a distinct entry for every known web
`
`page, each entry indicating whether the corresponding web page has been
`
`processed, in addition to other status information. Id. at 1:61–2:2.
`
`2. Analysis of Alleged Obviousness over Scott (II), Scott, and
`Monier
`
`
`
`Petitioner argues that claims 6 and 12–24 would have been obvious
`
`over Scott (II), Scott, and Monier. Pet. 60–65. Petitioner argues that claims
`
`6, 13, 21, and 24 include a limitation of employing a “web crawler” to
`
`“probe the application” as part of the process of generating an application
`
`model. Pet. 60. Furthermore, Petitioner argues that the Monier patent
`
`describes the operation of web crawlers. Id.
`
`Petitioner does not rely upon Monier for any teachings regarding the
`
`“examining” step and the “generating” step discussed above in the
`
`independent claims; thus, we determine that the addition of Monier fails to
`
`overcome the identified deficiencies in the combination of Scott (II) and
`
`Scott with respect to independent claims 1, 12, 16, and 23, and challenged
`
`claims 6, 13–15, 17–22, and 24 dependent therefrom. Accordingly, based
`
`20
`
`
`
`IPR2017-00653
`IPR2017-00654
`Patent 7,472,413 B1
`
`on the record before us, we determine that Petitioner fails to demonstrate a
`
`reasonable likelihood of prevailing in its challenge that 6 and 12–24 would
`
`have been obvious in view of Scott (II), Scott, and Monier.
`
`F. ’653 Ground 3: Asserted Obviousness of Claims 7