throbber
Trials@uspto.gov
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket