`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_________________
`
`
`CROWDSTRIKE, INC.,
`Petitioner
`
`v.
`
`TAASERA LICENSING LLC,
`Patent Owner
`_________________
`
`
`Inter Partes Review Case No. IPR2023-01464
`U.S. Patent No. 8,327,441
`
`
`
`
`
`PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NO. 8,327,441
`
`

`

`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`
`TABLE OF CONTENTS
`
`INTRODUCTION ......................................................................................... 1
`I.
`II. GROUNDS FOR STANDING (37 C.F.R. § 42.104(A)) ............................. 1
`III.
`IDENTIFICATION OF CHALLENGE (37 C.F.R. § 42.104(B)) ............. 1
`A.
`CITATION OF PRIOR ART ........................................................................ 1
`B.
`STATUTORY GROUNDS FOR CHALLENGE ............................................... 2
`IV. THE ’441 PATENT ....................................................................................... 2
`A.
`CLAIM OF PRIORITY OF THE ’441 PATENT .............................................. 2
`B. OVERVIEW OF THE ’441 PATENT ............................................................ 2
`C.
`SUMMARY OF THE PROSECUTION HISTORY ............................................ 8
`D.
`LEVEL OF ORDINARY SKILL IN THE ART ................................................ 8
`E.
`CLAIM CONSTRUCTION .......................................................................... 9
`V. HOW THE CLAIMS ARE UNPATENTABLE ......................................... 9
`A. OVERVIEW OF ASSERTED PRIOR ART ................................................... 10
`1. MUNETOH .................................................................................. 10
`2.
`RAJAN ....................................................................................... 12
`B. GROUND 1: CLAIMS 1-7 AND 9 ARE UNPATENTABLE UNDER 35
`U.S.C. § 103(A) AS OBVIOUS IN VIEW OF MUNETOH AND RAJAN ......... 15
`C. MOTIVATION TO COMBINE MUNETOH AND RAJAN .............................. 15
`1.
`CLAIM 1 ..................................................................................... 17
`a)
`[1a.] A method of providing an attestation service
`for an application at runtime executing on a
`computing platform using an attestation server,
`comprising: ..................................................................... 17
`[1b.] receiving, by the attestation server remote
`from the computing platform: ........................................ 20
`[1c.] a runtime execution context indicating
`attributes of the application at runtime, wherein the
`attributes comprise one or more executable file
`binaries of the application and loaded components
`of the application; ........................................................... 21
`[1d.] a security context providing security
`information about the application, wherein the
`security information comprises an execution
`analysis of the one or more executable file binaries
`and the loaded components; ........................................... 23
`
`b)
`
`c)
`
`d)
`
`i
`
`

`

`b)
`
`b)
`
`e)
`
`f)
`
`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`[1e.] generating, by the attestation server, a report
`indicating security risks associated with the
`application based on the received runtime
`execution context and the received security
`context, as an attestation result; and ............................... 26
`[1f.] sending, by the attestation server, the
`attestation result associated with the application. .......... 30
`CLAIM 2 ..................................................................................... 31
`a)
`[2a.] generating, by the attestation server, an
`application artifact as a reference for changes in a
`subsequent execution context; and ................................. 31
`[2b.] sending the generated application artifact
`such that subsequent changes to the runtime
`execution context are tracked based on the
`generated application artifact. ........................................ 33
`CLAIM 3 ..................................................................................... 34
`a)
`[3a.] The method according to claim 2, further
`comprising digitally signing the attestation results: ....... 34
`[3b.] wherein the attributes further comprise
`parent-child process associations of the
`application. ..................................................................... 35
`CLAIM 4 ..................................................................................... 36
`a)
`The method of claim 1, wherein the received
`security context is an introspective security
`context, and wherein the execution analysis is a
`static, dynamic, or virtual analysis of the one or
`more executable file binaries and the loaded
`components. ................................................................... 36
`CLAIM 5 ..................................................................................... 38
`a)
`The method of claim 4, wherein the generating of
`the report indicating security risks associated with
`the application includes generating, by the
`attestation server, one or more security assertions
`that pertain to the received runtime execution
`context and the received introspective security
`context. ........................................................................... 38
`CLAIM 6 ..................................................................................... 39
`a)
`The method according to claim 1, further
`comprising authenticating the application using a
`plurality of collaboration services. ................................. 39
`
`ii
`
`2.
`
`3.
`
`4.
`
`5.
`
`6.
`
`

`

`7.
`
`8.
`
`b)
`
`c)
`
`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`CLAIM 7 ..................................................................................... 40
`a)
`The method according to claim 1, further
`comprising controlling a user's transaction with the
`application by applying a set of authorization rules
`in accordance with the attestation results. ...................... 40
`CLAIM 9 ..................................................................................... 41
`a)
`The method according to claim 1, further
`comprising providing confidence metrics in the
`attestation results indicating a level of security risk
`by different classifications such that a restriction
`on a user's transaction with the application are
`applied based on the level of security risk indicated
`by the confidence metrics in the attestation results. ....... 41
`D. GROUND 2: CLAIMS 1-7 AND 9 ARE UNPATENTABLE UNDER 35
`U.S.C. § 103(A) AS OBVIOUS OVER RAJAN IN VIEW OF MUNETOH ........ 42
`E. MOTIVATION TO COMBINE RAJAN AND MUNETOH .............................. 43
`1.
`CLAIM 1 ..................................................................................... 43
`a)
`[1a.] A method of providing an attestation service
`for an application at runtime executing on a
`computing platform using an attestation server,
`comprising: ..................................................................... 43
`[1b.] receiving, by the attestation server remote
`from the computing platform: ........................................ 46
`[1c.] a runtime execution context indicating
`attributes of the application at runtime, wherein the
`attributes comprise one or more executable file
`binaries of the application and loaded components
`of the application; ........................................................... 47
`[1d.] a security context providing security
`information about the application, wherein the
`security information comprises an execution
`analysis of the one or more executable file binaries
`and the loaded components; ........................................... 48
`[1e.] generating, by the attestation server, a report
`indicating security risks associated with the
`application based on the received runtime
`execution context and the received security
`context, as an attestation result; and ............................... 50
`[1f.] sending, by the attestation server, the
`attestation result associated with the application. .......... 52
`
`d)
`
`e)
`
`f)
`
`iii
`
`

`

`b)
`
`b)
`
`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`CLAIM 2 ..................................................................................... 54
`a)
`[2a.] generating, by the attestation server, an
`application artifact as a reference for changes in a
`subsequent execution context; and ................................. 54
`[2b.] sending the generated application artifact
`such that subsequent changes to the runtime
`execution context are tracked based on the
`generated application artifact. ........................................ 55
`CLAIM 3 ..................................................................................... 57
`a)
`[3a.] The method according to claim 2, further
`comprising digitally signing the attestation results: ....... 57
`[3b.] wherein the attributes further comprise
`parent-child process associations of the
`application. ..................................................................... 57
`CLAIM 4 ..................................................................................... 58
`a)
`The method of claim 1, wherein the received
`security context is an introspective security
`context, and wherein the execution analysis is a
`static, dynamic, or virtual analysis of the one or
`more executable file binaries and the loaded
`components. ................................................................... 58
`CLAIM 5 ..................................................................................... 59
`a)
`The method of claim 4, wherein the generating of
`the report indicating security risks associated with
`the application includes generating, by the
`attestation server, one or more security assertions
`that pertain to the received runtime execution
`context and the received introspective security
`context. ........................................................................... 59
`CLAIM 6 ..................................................................................... 59
`a)
`The method according to claim 1, further
`comprising authenticating the application using a
`plurality of collaboration services. ................................. 59
`CLAIM 7 ..................................................................................... 60
`a)
`The method according to claim 1, further
`comprising controlling a user's transaction with the
`application by applying a set of authorization rules
`in accordance with the attestation results. ...................... 60
`CLAIM 9 ..................................................................................... 60
`
`2.
`
`3.
`
`4.
`
`5.
`
`6.
`
`7.
`
`8.
`
`iv
`
`

`

`a)
`
`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`The method according to claim 1, further
`comprising providing confidence metrics in the
`attestation results indicating a level of security risk
`by different classifications such that a restriction
`on a user's transaction with the application are
`applied based on the level of security risk indicated
`by the confidence metrics in the attestation results. ....... 60
`VI. NO BASIS FOR DISCRETIONARY DENIAL ....................................... 61
`VII. CONCLUSION ............................................................................................ 63
`VIII. MANDATORY NOTICES (37 C.F.R. § 42.8(A)(1)) ................................ 63
`A.
`REAL PARTY IN INTEREST: .......................................................... 63
`B.
`RELATED MATTERS: ...................................................................... 63
`C.
`LEAD AND BACKUP COUNSEL: ................................................... 65
`D.
`SERVICE INFORMATION: .............................................................. 65
`E.
`PAYMENT OF FEES ......................................................................... 66
`
`
`
`
`
`
`v
`
`

`

`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`TABLE OF AUTHORITIES
`
`Cases
`Advanced Bionics, LLC v. MED-EL Elektromedizinische Gerate GmbH, IPR2019-
`01469, Paper 6 (Feb. 13, 2020) ........................................................................... 62
`Cellco Partnership v. Huawei Device Co., IPR2020-01117, Paper 10 (Feb. 3,
`2021) .................................................................................................................... 63
`Graham v. John Deere Co., 383 U.S. 1 (1966) ................................................. 16, 43
`
`KSR Int’l Co. v. Teleflex, Inc., 550 U.S. 398 (2007) ......................................... 16, 43
`Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc) ......................... 10
`Wellman, Inc. v. Eastman Chem. Co., 642 F.3d 1355 (Fed. Cir. 2011) .................. 10
`Statutes
`35 U.S.C. § 102(b) (pre-AIA) ................................................................................... 2
`35 U.S.C. § 102(e) ..................................................................................................... 9
`35 U.S.C. § 103(a) ................. 3, 11, 16, 32, 35, 37, 39, 40, 41, 43, 54, 58, 59, 60, 61
`35 U.S.C. § 325(d) ............................................................................................ 62, 63
`Regulations
`37 C.F.R. § 42.100(b) .............................................................................................. 10
`37 C.F.R. § 42.104(a) ................................................................................................ 2
`37 C.F.R. § 42.104(b) ................................................................................................ 2
`37 C.F.R. § 42.105 .................................................................................................. 68
`37 C.F.R. § 42.24 .................................................................................................... 67
`37 C.F.R. § 42.6(e) .................................................................................................. 68
`37 C.F.R. § 42.8 ...................................................................................................... 67
`37 C.F.R. § 42.8(a)(1) ............................................................................................. 64
`37 C.F.R. § 42.8(b)(2) ............................................................................................. 64
`37 C.F.R. § 42.8(b)(3) ............................................................................................. 65
`
`
`
`
`
`vi
`
`

`

`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`
`APPENDIX OF EXHIBITS
`
`
`Description
`U.S. Patent No. 8,327,441 to Kumar et al.
`Curriculum Vitae of A.L. Seth Nielson, Ph.D.
`Expert Declaration of Dr. Seth Nielson under 37 C.F.R. § 1.68.
`Prosecution History of ’441 to Kumar et al.
`Seiji Munetoh, Integrity management Infrastructure for Trusted
`Computing, IEICE TRANS. INF. & SYST., Vol. E91-D, No. 5,
`1242-1251, (May 2008).
`Hridesh Rajan, Tisa: Toward Trustworthy Services in a Service-
`Oriented Architecture, IEEE Transactions on Services Computing,
`201-213, (October-December 2008).
`Declaration of Ingrid Hsieh-Yee, Ph.D.
`Steve Anderson, Web Services Trust Language (WS-Trust),
`(February 2005).
`George Moncrief, ezHPC Security Architecture, IEEE Computer
`Society, (2006).
`Taasera Licensing LLC, v. Trend Micro Incorporated, Plaintiff’s
`Disclosure of Asserted Claims and Infringement Contentions
`with ’441 Claim Chart, 2:21-cv-00441-JRG-RSP, (Jul 26, 2022).
`Ajay Surie, Rapid Trust Establishment for Pervasive Computing,
`IEEE Computer Society, 24-30, (2007).
`Minjin Kwon, PROBE: A Process Behavior-based Host Intrusion
`Prevention System, Department of Computer Science and
`Engineering, Korea University, Seoul, (2008).
`United States Judicial Panel on Multidistrict Litigation Transfer
`Order
`In re: Taasera Licensing LLC, Patent Litigation, No. 2”22-MD-
`03042-JRG Eighth Amended Docket Control Order
`In re: Taasera Licensing LLC, Patent Litigation, No. 2:22-MD-
`03042-JRG Dkt. 189 Order on Trend’s Motion to Transfer
`
`Exhibit No.
`1001
`1002
`1003
`1004
`1005
`
`1006
`
`1007
`1008
`
`1009
`
`1010
`
`1011
`
`1012
`
`1013
`
`1014
`
`1015
`
`
`
`
`
`
`vii
`
`

`

`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`
`I.
`
`INTRODUCTION
`CrowdStrike, Inc. (“Petitioner”) petitions for inter partes review of claims 1-
`
`7 and 9 of U.S. Patent No. 8,327,441 (“the ’441 patent,” EX1001).
`
`II. GROUNDS FOR STANDING (37 C.F.R. § 42.104(A))
`Petitioner certifies the ’441 patent is available for inter partes review and
`
`Petitioner is not barred or estopped from requesting an inter partes review
`
`challenging the patent claims on the grounds identified in this Petition.
`
`III.
`
`IDENTIFICATION OF CHALLENGE (37 C.F.R. § 42.104(B))
`A. Citation of Prior Art
`Munetoh, et al. “Integrity Management Infrastructure for Trusted Computing”
`
`IEICE TRANS. INF. & SYST., Vol. E91-D, No. 5, 1242-1251, (May 2008)
`
`(“Munetoh”, EX1005) is prior art under pre-AIA § 102(b) because it was published
`
`and publicly accessible by June 16, 2008, more than one year before the earliest
`
`possible priority date of the ’441 patent. EX1007. Munetoh was not cited or
`
`considered during prosecution of the ’441 patent.
`
`Rajan, et al. “Tisa: Toward Trustworthy Services in a Service-Oriented
`
`Architecture,” IEEE Transactions on Services Computing, 201-213, (October-
`
`December 2008) (“Rajan”, EX1006) is prior art under pre-AIA § 102(b) because it
`
`was published and publicly available no later than March 24, 2009, more than one
`
`1
`
`

`

`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`year before the earliest possible priority date of the ’441 patent. EX1007. Rajan was
`
`not cited or considered during prosecution of the ’441 patent.
`
`B.
`Statutory Grounds for Challenge
`GROUND 1: Claims 1-7 and 9 are unpatentable under 35 U.S.C. § 103(a) as obvious
`
`over Munetoh (EX1005) in view of Rajan (EX1006).
`
`GROUND 2: Claims 1-7 and 9 are unpatentable under 35 U.S.C. § 103(a) as obvious
`
`over Rajan (EX1006) in view of Munetoh (EX1005).
`
`IV. THE ’441 PATENT
`A. Claim of Priority of the ’441 patent
`The ’441 patent issued December 4, 2012, from U.S. Patent Application No.
`
`13/399,065, filed February 17, 2012, which claimed priority to Provisional
`
`Application No. 61/443,854, filed February 17, 2011. EX1001, p.1. Solely for the
`
`purposes of this Petition, the earliest priority date for the ’441 patent is taken to be
`
`February 17, 2011 (the “priority date”), so the Challenged Claims should be
`
`examined under pre-AIA statutes.
`
`B. Overview of the ’441 patent
`The ’441 patent relates to computer security. EX1001, 1:15-18, 5:45-67;
`
`EX1003, ¶71. As background, the patent recognizes that in recent trends in
`
`computing “enterprise software is no longer owned by the customer, but instead the
`
`Information Technology infrastructure can be provided by a third party and the
`
`2
`
`

`

`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`software applications may be sold as service offerings.” Id., 1:20-25. “Security in
`
`such environments may be an emerging challenge.” Id., 5:66-67.
`
`To address such security concerns, the ’441 patent discloses systems and
`
`methods “of providing an attestation service for an application at runtime executing
`
`on a computing platform using an attestation server.” Id., 26:27-29. The application
`
`may be an application targeted for use by a computing platform operated by a user
`
`that may desire an assurance or an attestation that the application is appropriate to
`
`be used. Id., 7:7-12. In an attestation service, “applications may be secured by
`
`signing-on or authenticating applications onto the network using an attestation
`
`process (e.g., via a single factor or multi-factor attestation).” Id., 6:1-4. The patent
`
`discloses a “method, apparatus and/or system to establish user-to-application
`
`connections based on the dynamic attestation of applications” EX1001, 1:41-44.
`
`FIG. 4 reproduced below illustrates the system and methods of the ’441 patent.
`
`3
`
`

`

`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`
`
`
`Referring to FIG. 4, a network 450 may include an instrumented target
`
`platform 400, a runtime monitor 401, an attestation broker or attestation server 402,
`
`collaboration services 403, an interactive user 404, and/or a network access enforcer
`
`405. Id., 14:9-12, 12:64-67.
`
`The specification explains that “[t]he user 404 may establish a physical
`
`connection over network 450 and may initiate an application access request 411 to
`
`commence or initiate a transaction with a target application hosted on the
`
`instrumented target platform 401.” Id., 14:12-16. “Applications running on the
`
`instrumented target platform 400 may be inspected by the runtime monitor 401 for
`
`application execution context and state changes.” Id., 14:17-19.
`
`4
`
`

`

`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`The “runtime monitor may generate a runtime application execution context
`
`(e.g., metadata), which may include, for example, the file hash digests and/or file
`
`attributes for loaded components of the running target application. The running
`
`target application may be registered by the runtime monitor 401 with the attestation
`
`broker 402 via a start notification 406 and the runtime application execution context
`
`(e.g., that may include the metadata) may be sent by the runtime monitor 401 to the
`
`attestation broker 402 via an application execution context change notification 408.”
`
`Id., 14:27-37.
`
`In response, the attestation broker or attestation server 402 “may verify the
`
`authenticity of the running application on the instrumented target platform 400 with
`
`a real time or near real time exchange 409 of the received metadata with one or more
`
`collaboration services 403 and the return of the application security context 410
`
`based on the exchanged metadata.” Id., 14:39-44, 12:64-67.
`
`“A network access enforcer 405 may register or subscribe with the attestation
`
`broker 402 as a web service over a web services protocol interface 412:413 for
`
`notifications (e.g., publications) of application statements or reports (e.g., claims)
`
`for running applications (e.g., all running applications) on a plurality of instrumented
`
`target platforms 400.” Id. 15:5-10. “The network access enforcer 405 may query the
`
`attestation broker 402 for user specific application bindings configured for the
`
`attestation broker 402 to determine authorization controls based on dynamic multi-
`
`5
`
`

`

`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`factor application attestation, and real time (or near real time) confidence metrics
`
`based on the local execution context 408 and assessed security context 410.” Id.,
`
`15:28-34. “[T]he network access enforcer 405…may deny access on an
`
`authenticated user based on the level of concern…as expressed in the user-to-
`
`application policy bindings provisioned for the attestation broker 402.” Id., 15:34-
`
`41.
`
`The Challenged Claims recite a “method of providing an attestation service
`
`for an application at runtime executing on a computing platform using an attestation
`
`server.” Id., 26:27-29.
`
`In the method recited in claim 1, the attestation server receives a runtime
`
`execution context indicating attributes of the application at runtime, and a security
`
`context providing security information about the application. Id., 26:30-39. The
`
`attributes comprise one or more executable file binaries of the application and loaded
`
`components of the application, and the security information comprises an execution
`
`analysis of the one or more executable file binaries and the loaded components. Id.
`
`Based on the received runtime execution context and the received security
`
`context, the attestation server generates as an attestation result. Id., 26:40- 44. The
`
`attestation server then sends the attestation result associated with the application. Id.,
`
`26:44-45. The claim does not identify where the attestation result is sent.
`
`6
`
`

`

`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`Claim 2 expands the method to include the attestation result generating an
`
`application artifact as a reference for changes in a subsequent execution context, and
`
`sending the generated application artifact such that subsequent changes to the
`
`runtime execution context are tracked based on the generated application artifact.
`
`Id., 26:46-52. Again, the claim does not identify where the generated application
`
`artifact is sent. The specification explains that “the attestation service may be
`
`configured to generate an artifact based on a runtime local execution context of the
`
`running application instance on the instrumented target platform.” Id., 2:40-43.
`
`Claim 3 adds digitally signing the attestation results and limits the attributes to
`
`further including parent-child process associations of the application. Id., 26:53-56.
`
`Claim 4 clarifies that the received security context is an introspective security
`
`context, and the execution analysis is a static, dynamic, or virtual analysis of the one
`
`or more executable file binaries and the loaded components. Id., 26:53-56. Claim 5
`
`further clarifies that the attestation server generates one or more security assertions
`
`that pertain to the received runtime execution context and the received introspective
`
`security context. Id., 26:63-67.
`
`Claim 6 adds to the method authenticating the application using a plurality of
`
`collaboration services. Id., 27:1-3. Claim 7 adds to the method controlling a user’s
`
`transaction with the application by applying a set of authorization rules in
`
`accordance with the attestation results. Id., 27:4-7.
`
`7
`
`

`

`C.
`Summary of the Prosecution History
`Prosecution of the 13/399,065 application that issued as the ’441 patent began
`
`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`
`with a non-final Office Action on April 27, 2012, in which claims 1-26 were rejected
`
`under 35 U.S.C. § 102(e) as unpatentable under U.S. Patent Publication
`
`2011/0179477 to Starnes. EX1004, pp.111-119. Applicant initiated an Examiner
`
`Interview on June 7, 2012. EX1004, p.107.
`
`After an Examiner Interview, Taasera responded on June 29, 2012, by
`
`amending claims 1, 3-5, 13-19, and 21-26. Of relevance to the Challenged Claims,
`
`independent claim 1 was amended to recite “wherein the attributes comprise one or
`
`more executable file binaries of the application and loaded components of the
`
`application... wherein the security information comprises an execution analysis of
`
`the one or more executable file binaries and the loaded components”.
`
`A Notice of Allowance then issued September 17, 2012, without an
`
`Examiner’s statement of reasons for allowance. Id., pp.44-45.
`
`D. Level of Ordinary Skill in the Art
`As established by the Declaration of Dr. Seth Nielson dated April 6, 2023
`
`(EX1003), a person having ordinary skill in the art (PHOSITA) at the time of the
`
`earliest claimed priority date for the ’948 patent would have had a bachelor’s degree
`
`in computer science, or a related field, or an equivalent technical degree or
`
`equivalent work experience, and an additional one to two years of education or
`
`8
`
`

`

`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`experience in the field of computer security topics. More education can supplement
`
`practical experience and vice versa. EX1003, ¶81.
`
`E. Claim Construction
`In this proceeding, claims are interpreted under the same standard applied by
`
`Article III courts (i.e., the Phillips standard). 37 C.F.R. § 42.100(b); Phillips v. AWH
`
`Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc).
`
`For purposes of this proceeding only, Petitioner proposes that all claim terms
`
`should be given their plain and ordinary meanings and no specific claim
`
`constructions are necessary to apply the asserted prior art to the Challenged Claims.1
`
`See Wellman, Inc. v. Eastman Chem. Co., 642 F.3d 1355, 1361 (Fed. Cir. 2011)
`
`(“[C]laim terms need only be construed to the extent necessary to resolve the
`
`controversy.”).
`
`V. HOW THE CLAIMS ARE UNPATENTABLE
`The following discussion and the accompanying evidence demonstrate that
`
`there is a reasonable likelihood that Petitioner will prevail with respect to the
`
`Challenged Claims.
`
`
`1 Petitioner reserves the right in other proceedings to construe the Challenged Claims
`and pursue indefiniteness theories.
`
`9
`
`

`

`A. Overview of Asserted Prior Art
`Petitioner submits that claims 1-7 and 9 of the ’441 patent are invalid as
`
`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`
`unpatentable under 35 U.S.C. § 103(a) in view of the combination of Munetoh and
`
`Rajan.
`
`1. Munetoh
`Munetoh is directed towards an integrity management infrastructure for
`
`trusted computing based on a standard published by the Trusted Computing Group
`
`(TCG). EX1003, ¶¶83-84; EX1005, p.1. In Munetoh, a chain of trust is used to check
`
`the security and authenticity of various hardware and software components.
`
`EX1005, p.1; EX1003, ¶¶84, 89-91. In addition to managing the integrity of
`
`components on a device, Munetoh describes infrastructure for confirming and
`
`attesting to parties requesting the service can confirm trust in the service. EX1005,
`
`pp.4-5; EX1003, ¶¶86-87,91. Specifically, Munetoh provides an
`
`integrity
`
`management model that includes a remote verifier that provides platform trust
`
`services (PTS). EX1005, p.4, Fig.-1; EX1003, ¶¶87,93. Information about the
`
`trustworthiness of a platform is collected and monitored by a client (agent) installed
`
`on the platform. EX1005, pp.5-6. The system is illustrated in Figure 1 of Munetoh
`
`which is reproduced below.
`
`10
`
`

`

`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`
`
`
`The platform trust services at the remote verifier includes a finite state
`
`machine that records the change of states on a platform received in an integrity
`
`measurement log (IML). Id. The applications running on the server being analyzed
`
`for trust may also be measured and attested by the remote verifier by analyzing the
`
`behavior and integrity of software components that are loaded and executed.
`
`EX1005, pp.3-6. Specifically, hash values are measured for binary images of
`
`software components and these components are verified to ensure they are known
`
`and intact. EX1005, pp.2-3. Therefore, a user (relying party) requesting application
`
`services may be provided by the platform with an attestation (validation result)
`
`generated by the remote verifier. EX1005, p.4; EX1003, ¶¶86-87.
`
`11
`
`

`

`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`Informationally, the remote verifier serves as an information clearinghouse
`
`and analyzer, including receiving reference manifest from third parties that
`
`developed the hardware and software to be attested, receiving a policy that needs to
`
`be met for the relying party, receiving a platform configuration register (PCR) that
`
`is an immutable record of integrity for an application and its components, and
`
`receiving vulnerability data for applications to be analyzed on the platform. EX1005,
`
`pp.3-4,7-8. The PCR data and the IML may be combined in an integrity report which
`
`can also include security policy information. The IR is then compared to the relying
`
`party’s requested security policy to see if the security of the platform meets the
`
`policy, and the relying party is informed of the result in a validation result. EX1005,
`
`pp.4-5; EX1003, ¶¶88,92-93.
`
`2.
`Rajan
`Rajan is directed toward providing trustworthy services in a service-oriented
`
`architecture based on a standard published by the Trusted Computing Group (TCG).
`
`EX1006, p.2; EX1003, ¶¶95,101. This architecture is shown in Fig. 1:
`
`12
`
`

`

`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`
`
`
`EX1006, Fig. 1.
`
`This architecture of Rajan includes components for client, provider, and
`
`broker. Id. Among other things, Rajan discloses “an extension of the traditional
`
`notion of a service-oriented architecture that allows clients, brokers, and providers
`
`to negotiate and validate the integrity of a requirements monitor.” Id., p.1.
`
`Rajan describes several different hashes, keys and certificates that are used to
`
`sign various hardware and software components of server providing services.
`
`EX1006, pp.3,5. Rajan proposes adding a trust negotiation and verification interface
`
`to facilitate negotiation of the desired level of trust between the components.
`
`13
`
`

`

`Petition for Inter Partes Review
`U.S. Patent No. 8,327,441
`EX1006, p.4. Further, a requirem