`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_________________
`
`INTERNATIONAL BUSINESS MACHINES CORPORATION
`Petitioner
`
`v.
`
`INTELLECTUAL VENTURES II LLC
`Patent Owner
`_________________
`
`Case IPR2014-00660
`Patent 5,745,574
`_________________
`
`
`
`SECOND CORRECTED PETITION FOR INTER PARTES REVIEW UNDER 37
`C.F.R. § 42.100
`
`
`
`Intellectual Ventures Exhibit 2006
`IBM v. Intellectual Ventures
`IPR2014-01410
`
`

`

`
`
`I.
`
`TABLE OF CONTENTS
`
`GROUNDS FOR STANDING PURSUANT TO 37 C.F.R.
`§ 42.104(a) ....................................................................................................... 1
`
`II. MANDATORY NOTICES PURSUANT TO 37 C.F.R. § 42.8(a)(1) ............ 1
`
`III.
`
`IV.
`
`A.
`
`B.
`
`C.
`
`D.
`
`37 C.F.R. § 42.8(b)(1): Real Party-In-Interest ...................................... 1
`
`37 C.F.R. § 42.8(b)(2): Related Matters ............................................... 2
`
`37 C.F.R. § 42.8(b)(3): Lead and Back-Up Counsel ............................ 2
`
`37 C.F.R. § 42.8(b)(4): Service Information ......................................... 3
`
`PAYMENT OF FEES PURSUANT TO 37 C.F.R. § 42.103 ......................... 3
`
`IDENTIFICATION OF CHALLENGE PURSUANT TO 37 C.F.R.
`§ 42.104(b) ....................................................................................................... 3
`
`A.
`
`B.
`
`C.
`
`D.
`
`E.
`
`37 C.F.R. § 42.104(b)(1): Claims for Which IPR Is Requested ........... 3
`
`37 C.F.R. § 42.104(b)(2): The Specific Art and Statutory
`Ground(s) on Which the Challenge Is Based ........................................ 3
`
`37 C.F.R. § 42.104(b)(3): Claim Construction ..................................... 5
`
`37 C.F.R. § 42.104(b)(4): How the Claims are Unpatentable .............. 5
`
`37 C.F.R. § 42.104(b)(5): Evidence Supporting Challenge .................. 6
`
`V.
`
`THERE IS A REASONABLE LIKELIHOOD THAT CLAIMS 18-31
`ARE UNPATENTABLE ................................................................................. 6
`
`A. Description of the Alleged Invention of the ’574 Patent ...................... 6
`
`B.
`
`C.
`
`Summary of the Prosecution History of the ’574 Patent ...................... 7
`
`Claim-By-Claim Explanation of Grounds for Unpatentability
`and Claim Charts ................................................................................... 7
`
`Ground 1: Claims 18-31 are anticipated by Kapidzic ........................ 8
`
`Ground 2: Claims 23-25 and 27-28 are anticipated by The PKI
`Report under § 102. Claims 18-22, 26, and 29-31 are
`
`i
`
`

`

`
`
`obvious in view of the various systems disclosed in The
`PKI Report under § 103. ................................................. 25
`
`Ground 3: Claim 18 is anticipated by RFC 1424 under § 102.
`Claims 23-29 are anticipated by RFC 1422 under § 102.
`Claims 19-22 and 30-31 are rendered obvious by RFC
`1422 in view of RFC 1424 under § 103. ........................ 43
`
`VI. CONCLUSION .............................................................................................. 60
`
`
`
`
`
`ii
`
`

`

`
`
`On behalf of International Business Machines Corporation (“IBM”) and in
`
`accordance with 35 U.S.C. § 311 and 37 C.F.R. § 42.100, inter partes review
`
`(“IPR”) is respectfully requested of Claims 18-31 of U.S. Patent No. 5,745,574
`
`(“the ’574 Patent”), attached hereto as Exhibit 1004.
`
`I.
`
`GROUNDS FOR STANDING PURSUANT TO 37 C.F.R. § 42.104(a)
`
`IBM hereby certifies that the ’574 Patent is available for IPR and that IBM
`
`is not barred or estopped from requesting IPR of Claims 18-31 on the grounds
`
`identified herein. Specifically, IBM certifies that (1) IBM is not the owner of the
`
`’574 Patent; (2) IBM (or any real party-in-interest) has not filed a civil action
`
`challenging the validity of any claim of the ’574 Patent; (3) IBM has not been
`
`served with a complaint alleging infringement of the ’574 Patent, and neither has
`
`any real party-in-interest or privy of IBM; (4) the estoppel provisions of 35 U.S.C.
`
`§ 315(e)(1) do not prohibit this IPR; and (5) this Petition is filed after the ’574
`
`Patent was granted.
`
`II. MANDATORY NOTICES PURSUANT TO 37 C.F.R. § 42.8(a)(1)
`Pursuant to 37 C.F.R. § 42.8(a)(1), the mandatory notices identified in 37
`
`C.F.R. § 42.8(b) are provided below as part of this Petition.
`
`A. 37 C.F.R. § 42.8(b)(1): Real Party-In-Interest
`IBM is the real party-in-interest for Petitioner.
`
`
`
`1
`
`

`

`
`
`B. 37 C.F.R. § 42.8(b)(2): Related Matters
`Intellectual Ventures II LLC (“IV”) has asserted the ’574 Patent in seven
`
`separate patent infringement lawsuits pending in various federal district courts,
`
`none of which name IBM as a defendant: (1) Intellectual Ventures II LLC v.
`
`Huntington Bancshares Inc., et al., No. 2:13-cv-00785 (S.D. Ohio); (2) Intellectual
`
`Ventures II LLC v. U.S. Bancorp, et al., No. 0:13-cv-02071 (D. Minn.); (3)
`
`Intellectual Ventures II LLC v. SunTrust Banks, Inc., et al., No. 1:13-cv-02454
`
`(N.D. Ga.); (4) Intellectual Ventures II LLC v. Commerce Bancshares, Inc., et al.,
`
`No. 2:13-cv-04160 (W.D. Mo.); (5) Intellectual Ventures II LLC v. BBVA Compass
`
`Bancshares, Inc., et al., No. 2:13-cv-01106 (N.D. Ala.); (6) Intellectual Ventures II
`
`LLC v. JP Morgan Chase & Co., et al., No. 1:13-cv-03777 (S.D.N.Y.); and (7)
`
`Intellectual Ventures II LLC v. First National Bank of Omaha, No. 8:13-cv-00167
`
`(D. Neb.). These cases may affect, or be affected by, decisions in this proceeding.
`
`C. 37 C.F.R. § 42.8(b)(3): Lead and Back-Up Counsel
`
`Lead Counsel
`Kenneth R. Adamo (Reg. No. 27,299)
`kenneth.adamo@kirkland.com
`Postal and Hand-Delivery Address:
`KIRKLAND & ELLIS LLP
`300 North LaSalle Street
`Chicago, Illinois 60654
`Telephone: (312) 862-2000
`Fax: (312) 862-2200
`
`
`Back-up Counsel
`Alicia L. Shah (Reg. No. 68,080)
`alicia.shah@kirkland.com
`Postal and Hand-Delivery Address:
`KIRKLAND & ELLIS LLP
`300 North LaSalle Street
`Chicago, Illinois 60654
`Telephone: (312) 862-2000
`Fax: (312) 862-2200
`
`
`
`2
`
`

`

`
`
`Pursuant to 37 C.F.R. § 42.10(b), a Power of Attorney accompanies this
`
`Petition.
`
`D. 37 C.F.R. § 42.8(b)(4): Service Information
`Service on Petitioner may be made by e-mail.
`
`III. PAYMENT OF FEES PURSUANT TO 37 C.F.R. § 42.103
`The undersigned authorize the Office to charge the fee set forth in 37 C.F.R.
`
`§ 42.15(a) for this Petition to Deposit Account No. 506092. Review of fourteen
`
`(14) claims is requested, thus no excess claim fees are required. The undersigned
`
`further authorize payment for any additional fees that may be due in connection
`
`with this Petition to be charged to the above-referenced Deposit Account.
`
`IV.
`
`IDENTIFICATION OF CHALLENGE PURSUANT TO 37 C.F.R.
`§ 42.104(b)
`A. 37 C.F.R. § 42.104(b)(1): Claims for Which IPR Is Requested
`IBM requests IPR of Claims 18-31 of the ’574 Patent.
`
`B. 37 C.F.R. § 42.104(b)(2): The Specific Art and Statutory
`Ground(s) on Which the Challenge Is Based
`
`IPR of Claims 18-31 is requested in view of the following references, which
`
`are prior art for the following reasons:
`
`• Nada Kapidzic et al., A Certificate Management System: Structure, Functions
`
`and Protocols (“Kapidzic”). (Ex. 1007.) Kapidzic was published in the
`
`Proceedings of the Symposium on Network and Distributed System Security
`
`
`
`3
`
`

`

`
`
`and distributed on or before February 16-17, 1995. (Ex. 1006 at 001, 005, 008.)
`
`Kapidzic is prior art under § 102(a). 1
`
`• Shimshon Berkovits, et al., Public Key Infrastructure Study: Final Report (“The
`
`PKI Report”). (Ex. 1008.) The PKI Report was published by the National
`
`Institute of Standard and Technology on April 1, 1994. (Ex. 1008). The PKI
`
`Report is prior art under § 102(b).
`
`• Steve Kent, Request for Comments 1422 (“RFC 1422”). (Ex. 1011). RFC 1422
`
`was published by the Network Working Group of the Internet Engineering Task
`
`Force in February 1993. (Ex. 1009 at 001; Ex. 1010 at 003.) RFC 1422 is prior
`
`art under § 102(b).
`
`• Burton S. Kaliski, Jr., Request for Comments 1424 (“RFC 1424”). (Ex. 1013.)
`
`RFC 1424 was published by the Network Working Group of the Internet
`
`Engineering Task Force in February 1993. (Ex. 1012 at 001; Ex. 1010 at 003.)
`
`RFC 1424 is prior art under §102(b).
`
`
`1 Reference to 35 U.S.C. §§ 102 and 103 throughout this Petition are to the pre-
`
`AIA versions of those provisions, the provisions applicable to the ’574 Patent.
`
`
`
`4
`
`

`

`
`
`Ground
`1
`
`2
`
`Proposed Statutory Rejections for the ’574 Patent
`Claims 18-31 are anticipated by Kapidzic under § 102.
`
`Claims 23-25 and 27-28 are anticipated by The PKI Report under
`
`§ 102. Claims 18-22, 26, and 29-31 are obvious in view of the various
`
`systems disclosed in The PKI Report under § 103.
`
`3
`
`Claim 18 is anticipated by RFC 1424 under § 102. Claims 23-29 are
`
`anticipated by RFC 1422 under § 102. Claims 19-22 and 30-31 are
`
`rendered obvious by RFC 1422 in view of RFC 1424 under § 103.
`
`
`
`C. 37 C.F.R. § 42.104(b)(3): Claim Construction
`A claim in IPR is given the broadest reasonable interpretation in light of the
`
`specification to one having ordinary skill in the art. 37 C.F.R. § 42.100(b). IBM
`
`submits, for purposes of this IPR only, that proper construction of the term
`
`“common” is “shared.” The definition of “common” in 1995 (the time of
`
`invention) was “shared.” (Ex. 1014 at 003.) IBM further contends that the
`
`preambles of the independent claims are non-limiting.
`
`D. 37 C.F.R. § 42.104(b)(4): How the Claims are Unpatentable
`A detailed explanation of how construed Claims 18-31 are unpatentable,
`
`including the identification of where each element is found in the prior art, is
`
`provided in Section V.C.
`
`
`
`5
`
`

`

`
`
`E. 37 C.F.R. § 42.104(b)(5): Evidence Supporting Challenge
`An Appendix of Exhibits identifying all exhibits supporting this Petition,
`
`and assigning them exhibit numbers, is attached. The relevance of the evidence to
`
`the challenge raised, including identifying specific portions of the evidence that
`
`support the challenge, may be found in Section V.C. IBM submits a declaration of
`
`Dr. Matthew Blaze in support of this Petition in accordance with 37 C.F.R. § 1.68.
`
`(Ex. 1001.)
`
`V. THERE IS A REASONABLE LIKELIHOOD THAT CLAIMS 18-31
`ARE UNPATENTABLE
`A. Description of the Alleged Invention of the ’574 Patent
`The ’574 Patent is directed to a public key infrastructure for facilitating
`
`secure and authentic transactions over an unsecure network. (Ex. 1004 at 1:6-8.)
`
`The described public key infrastructure is a certification hierarchy made up of
`
`various entities, with a Policy Registration Authority (PRA) at the root of the
`
`hierarchy. (Ex. 1004 at Fig. 1A, 6:1-11.) The PRA certifies Policy Certification
`
`Authorities (PCA) which, in turn, certify Certification Authorities (CA) which, in
`
`turn, certify other sub-Certification Authorities or users. (Ex. 1004 at Fig. 1, 9:26-
`
`62.) The ’574 patent discloses a method of requesting and issuing public key
`
`certificates within a certification hierarchy. (Ex. 1004 at Fig. 1, 6:47-64.) The ’574
`
`patent is also directed to a method of verifying certificate signatures, validating
`
`
`
`6
`
`

`

`
`
`certificates using certificate revocation lists, updating certificates, and adding new
`
`computers to the hierarchy. (Ex. 1004 at Fig. 1, 6:65-67, 7:1-52.)
`
`B. Summary of the Prosecution History of the ’574 Patent
`The ’025 Application was filed on December 15, 1995. (Ex. 1005 at 002.)
`
`On March 31, 1997, the Examiner rejected all asserted claims of the ’025
`
`Application under 102(e) as anticipated by U.S. 5,497,421. (Ex. 1005 at 134-135.)
`
`On July 31, 1997, the Applicants filed a Request for Reconsideration, and on
`
`September 12, 1997, the Examiner issued a Notice of Allowance for all asserted
`
`claims. (Ex. 1005 at 141-144, 148.) The ’574 Patent issued on April 28, 1998. (Ex.
`
`1004 at 001.)
`
`C. Claim-By-Claim Explanation of Grounds for Unpatentability and
`Claim Charts
`
`IBM provides a detailed discussion of how each asserted prior art reference
`
`invalidates Claims 18-31 of the ’574 Patent. Although IBM includes evidence
`
`showing how the preamble of each independent claim is disclosed by the prior art,
`
`IBM contends that the preambles should not be construed as limiting. Further,
`
`secondary considerations do not support a finding of nonobviousness here. (See
`
`Ex. 1001 at ¶¶ 432–440.) Should IV put forth any allegations regarding secondary
`
`considerations of nonobviousness, IBM asks for the chance to respond.
`
`
`
`7
`
`

`

`
`
`Ground 1:
`Kapidzic teaches a system for managing a certification infrastructure.
`
`Claims 18-31 are anticipated by Kapidzic
`
`Relative to Claim 18, Kapidzic discloses the claimed method of requesting and
`
`issuing a public key certificate. Kapidzic teaches that in a “Certificate Management
`
`System,” a requester sends a “Certificate Signature Request” to a Certification
`
`Authority (CA). The CA issues a “Certificate Signature Reply” that contains the
`
`signed certificate, as described in Claim 18’s preamble. (Ex. 1007 at 005, 008; Ex.
`
`1001 at ¶¶ 69-75.) Kapidzic also teaches that “the CA [requesting computer
`
`process] generat[es] a pair of public and private RSA keys [and then a] self-signed
`
`certificate [data structure] is created from the public key . . . and sent to the parent
`
`CA [authorized computer process] in a Certificate Signature Request,” as recited in
`
`Claim 18.a. (Ex. 1007 at 007-008; Ex. 1001 at ¶¶ 76-80.) Next, Kapidzic discloses
`
`that “the parent CA verifies . . . the request, and . . . the parent CA signs the
`
`certificate and . . . creates a Certificate Signature Reply . . . and sends it back to
`
`the requester,” as recited in Claim 18.b. (Ex. 1007 at 008; Ex. 1001 at ¶¶ 81-83.)
`
`Relative to Claim 23, Kapidzic discloses the claimed method of verifying
`
`signatures. Kapidzic teaches that a requester “verifies the signatures of the
`
`certificates from the message, starting from the PCA’s [Policy Certification
`
`Authority’s] certificate . . . down to its own certificate,” as recited in Claim 23.
`
`(Ex. 1007 at 008; Ex. 1001 at ¶¶ 100-112.)
`
`
`
`8
`
`

`

`
`
`Relative to Claim 28, Kapidzic discloses the claimed method of validating
`
`certificates. Kapidzic teaches that “[f]or every certificate being verified, the verifier
`
`must check the certificate against the current CRL [Certificate Revocation List] of
`
`the same issuer,” as recited in Claim 28. (Ex. 1007 at 010; Ex. 1001 at ¶¶ 129-138.)
`
`Relative to Claim 30, Kapidzic discloses the claimed method of updating a
`
`certificate. Kapidzic teaches that “[w]hen a new key pair is generated by some CA
`
`[Certification Authority], the same procedure is followed as in the original
`
`certification,” as recited in Claim 30. (Ex. 1007 at 009; Ex. 1001 at ¶¶ 143-163.)
`
`Relative to Claim 31, Kapidzic discloses the claimed method of adding a
`
`new computer process. Kapidzic teaches that “[t]he PCA [Policy Certification
`
`Authority] is established first, after which the CAs [Certification Authorities] at the
`
`next level of the certification hierarchy can be registered and certified by the PCA.
`
`The process iterates down to the UCAs [User Certification Authorities], which
`
`register and certify users at the bottom of the certification hierarchy,” as recited in
`
`Claim 31. (Ex. 1007 at 007; Ex. 1001 at ¶¶ 164-184.)
`
`The claim chart below demonstrates how Kapidzic discloses all elements
`
`of Claims 18-31, in combination, as claimed.
`
`’574 Patent Claim
`[18] In a certification
`system for secure
`communications
`containing computer
`
`Kapidzic
`Kapidzic discloses in a certification system for secure
`communications containing computer processes
`arranged in a certification infrastructure (e.g., the
`Certificate Management System), a method of
`
`
`
`9
`
`

`

`
`
`’574 Patent Claim
`processes arranged in a
`certification
`infrastructure, a method
`of requesting and issuing
`a public key certificate,
`comprising:
`
`a. at a requesting
`computer process,
`generating a data
`structure containing the
`data items required for a
`public key certificate,
`including a public key,
`self-signing the data
`structure and sending the
`signed data structure as a
`certificate signature
`request to a computer
`process authorized as an
`issuing certification
`authority,
`
`Kapidzic
`requesting (e.g., the Certificate Signature Request) and
`issuing a public key certificate (e.g., the Certificate
`Signature Reply).
`
`“The Certificate Management System (CMS) is a
`networked system for generation, distribution, storage
`and verification of certificates for use in a variety of
`security enhanced applications.” (Ex. 1007 at
`005.)“Certification starts with the CA’s [Certification
`Authority’s] generation of a pair of public and private
`RSA keys. A self-signed certificate is created from the
`public key and the CA’s DN [Distinguished Name],
`and sent to the parent CA in a Certificate Signature
`Request.” (Ex. 1007 at 007-008.)
`
`“The parent CA . . . creates a Certificate Signature
`Reply that contains the signed certificate . . . and sends
`it back to the requester.” (Ex. 1007 at 008.)
`
`(See Ex. 1001, Blaze Decl. at ¶¶ 69-75.)
`Kapidzic discloses, at a requesting computer process
`(e.g., the Certification Authority that sends the
`Certificate Signature Request), generating a data
`structure containing the data items required for a
`public key certificate, including a public key (e.g., the
`self-signed certificate) self-signing the data structure
`and sending the signed data structure as a certificate
`signature request (e.g., the Certificate Signature
`Request) to a computer process authorized as an
`issuing certification authority (e.g., the parent CA).
`
`“Certification starts with the CA’s generation of a pair
`of public and private RSA keys. A self-signed
`certificate is created from the public key and the CA's
`DN, and sent to the parent CA in a Certificate
`Signature Request.” (Ex. 1007 at 007-008.)
`
`(See Ex. 1001, Blaze Decl. at ¶¶ 76-80.)
`
`
`
`10
`
`

`

`
`
`’574 Patent Claim
`b. at said computer
`process authorized as an
`issuing certification
`authority, verifying the
`authenticity of said
`request, and if authentic,
`certifying and returning
`the data structure in a
`certificate signature reply.
`
`[19] The method of claim
`18, further comprising:
`storing the received
`signed certificate at said
`requesting computer
`process.
`
`Kapidzic
`Kapidzic discloses at said computer process
`authorized as an issuing certification authority (e.g.,
`the parent CA), verifying the authenticity of said
`request (e.g., verifying the integrity of the request and
`signature of self-signed certificate), and if authentic
`(e.g., if all checks verify successfully), certifying
`(e.g., the parent CA signs the certificate) and
`returning the data structure in a certificate signature
`reply (e.g., the parent CA creates a Certificate
`Signature Reply that contains the signed certificate . . .
`and sends it back to the requester).
`
`“The parent CA receives the Certificate Signature
`Request. It verifies the identity of the requester
`according to whatever procedures are defined in the
`PCA’s security policy.” (Ex. 1007 at 008.)
`
`“Furthermore, the parent CA verifies the integrity of
`the request, and the signature of the self-signed
`certificate contained in the request.” (Ex. 1007 at
`008.)
`
`“If all the checks verify successfully, the parent CA
`signs the certificate and stores a copy of it locally.
`The parent CA then creates a Certificate Signature
`Reply that contains the signed certificate . . . and
`sends it back to the requester.” (Ex. 1007 at 008.)
`
`(See Ex. 1001, Blaze Decl. at ¶¶ 81-83.)
`Kapidzic discloses the method of claim 18, further
`comprising: storing the received signed certificate at
`said requesting computer process (e.g., the CA that
`originated the request stores the certificates from the
`Certificate Signature Reply in the local database).
`
`“The CA that originated the request receives the
`Certificate Signature Reply. It verifies the signatures
`of the certificates from the message, starting from the
`
`
`
`11
`
`

`

`
`
`’574 Patent Claim
`
`[20] The method of claim
`18, further comprising:
`storing the received
`signed certificate or copy
`of a signed certificate at a
`common certificate
`repository.
`
`[21] The method of claim
`18 performed when
`adding a new entity to a
`certification
`infrastructure, which
`entity may be [a] policy
`certification authority,
`certification authority,
`application or end-user.
`
`
`
`Kapidzic
`PCA’s certificate, which is read from the configuration
`file, down to its own certificate. If successful it stores
`them in the local database.” (Ex. 1007 at 008.)
`
`(See Ex. 1001, Blaze Decl. at ¶¶ 84-86.)
`Kapidzic discloses the method of claim 18, further
`comprising: storing the received signed certificate or
`copy of a signed certificate at a common certificate
`repository (e.g., the responsibility for storage and
`distribution is with the X.500 directories).
`
`“The responsibility for storage and distribution of
`certificates is deferred to X.500 directories...” (Ex.
`1007 at 005.)
`
`(See Ex. 1001, Blaze Decl. at ¶¶ 87-90.)
`Kapidzic discloses the method of claim 18 performed
`when adding a new entity to a certification
`infrastructure, which entity may be a policy
`certification authority, certification authority (e.g.,
`CAs [Certification Authorities] at the next level of the
`certification hierarchy can be registered and certified
`by the PCA) application or end-user (e.g., the
`registration and certification process iterates down to
`the UCAs [User Certification Authorities], which
`register and certify users at the bottom of the
`certification hierarchy).
`
`“The certification hierarchy is established top-down,
`starting with the PCA.” (Ex. 1007 at 007.)
`
`“The PCA is established first, after which the CAs at
`the next level of the certification hierarchy can be
`registered and certified by the PCA. The process
`iterates down to the UCAs, which register and certify
`users at the bottom of the certification hierarchy.” (Ex.
`1007 at 007.)
`
`
`12
`
`

`

`
`
`’574 Patent Claim
`
`[22] The method of claim
`18, performed upon
`expiration of an existing
`certificate, where the new
`certificate may contain
`either the existing or a
`new public key.
`
`[23] In a global network
`with secure
`communications
`containing computer
`processes arranged in a
`certification
`infrastructure, a method
`of verifying a signed data
`structure sent from a
`sender to a receiver,
`comprising:
`
`
`
`Kapidzic
`“The process of certifying a new CA involves
`communication between it and its parent. This
`communication consists of two messages: Certificate
`Signature Request and Certificate Signature Reply.”
`(Ex. 1007 at 007 (footnote omitted).)
`
`(See Ex. 1001, Blaze Decl. at ¶¶ 91-94.)
`Kapidzic discloses the method of claim 18, performed
`upon expiration of an existing certificate (e.g., when a
`current pair of keys expires after the end of their
`period of validity), where the new certificate may
`contain either the existing or a new public key (e.g., a
`new key pair is generated by the CA, and the same
`certification procedure is followed for the new key
`pair as in the original certification).
`
`“At any time following a CA's initial registration it is
`possible for that CA to change its public and secret
`key pair. It can happen either when a current pair of
`keys expires after the end of their period of validity…”
`(Ex. 1007 at 009.)
`
`“When a new key pair is generated by some CA, the
`same procedure is followed as in the original
`certification.” (Ex. 1007 at 009-010.)
`
`(See Ex. 1001, Blaze Decl. at ¶¶ 95-99.)
`Kapidzic discloses in a global network with secure
`communications containing computer processes
`arranged in a certification infrastructure (e.g., the
`Certificate Management System), a method of
`verifying a signed data structure sent from a sender to
`a receiver (e.g., the verification procedure is the same
`as for the Certificate Signature Reply).
`
`“The Certificate Management System (CMS) is a
`networked system for generation, distribution, storage
`and verification of certificates for use in a variety of
`13
`
`

`

`
`
`’574 Patent Claim
`
`a. obtaining a public key
`certificate for every
`computer process in the
`infrastructure between the
`sender and a common
`point of trust in the
`infrastructure and,
`
`b. verifying the
`authenticity of signatures
`iteratively, beginning
`with the common point of
`trust.
`
`
`
`Kapidzic
`security enhanced applications.” (Ex. 1007 at 005.)
`
`“The verification procedure is the same as for the
`Certificate Signature Reply.” (Ex. 1007 at 008).
`
`(See Ex. 1001, Blaze Decl. at ¶¶ 100-105.)
`Kapidzic discloses obtaining a public key certificate
`for every computer process in the infrastructure
`between the sender and a common point of trust in the
`infrastructure (e.g. the Certificate Reply contains the
`requested certificate as well as all the certificates in
`the certificate verification path, up to the top of the
`hierarchy).
`
`“The Policy Certification Authority (PCA) is the root
`of the hierarchy, which makes it the common point of
`trust for verification of all certificates in the system.”
`(Ex. 1007 at 006.)
`
`“The UCA, upon receiving the Certificate Request,
`indexes the local database for the requested certificate,
`which it returns to the requester in a Certificate
`Reply.” (Ex. 1007 at 008.)
`
`“[T]he Certificate Reply . . . contains the requested
`certificate as well as all the certificates in the
`certificate verification path, up to the top of the
`hierarchy.” (Ex. 1007 at 008.)
`
`(See Ex. 1001, Blaze Decl. at ¶¶ 106-109.)
`Kapidzic discloses verifying the authenticity of
`signatures iteratively, beginning with the common
`point of trust (e.g., the requesting Certification
`Authority verifies the signatures of the certificates
`from the Certificate Signature Reply, starting from the
`Policy Certification Authority’s certificate down to its
`own certificate).
`
`
`14
`
`

`

`Kapidzic
`“The Policy Certification Authority (PCA) is the root
`of the hierarchy, which makes it the common point of
`trust for verification of all certificates in the system.”
`(Ex. 1007 at 006.)
`
`“The CA that originated the request receives the
`Certificate Signature Reply. It verifies the signatures
`of the certificates from the message, starting from the
`PCA's certificate, which is read from the configuration
`file, down to its own certificate. (Ex. 1007 at 008.)
`
`(See Ex. 1001, Blaze Decl. at ¶¶ 110-112.)
`Kapidzic discloses the method of verifying of claim 23
`in which a public key certificate for every computer
`process in the infrastructure between the sender and a
`common point of trust is also verified against all
`relevant certificate revocation lists (e.g. for every
`certificate being verified, the verifier must check the
`certificate against the current Certificate Revocation
`List of the same issuer).
`
`“For every certificate being verified, the verifier must
`check the certificate against the current CRL of the
`same issuer. If the CRL is not available locally it must
`be retrieved from the PCA.” (Ex. 1007 at 010.)
`
`(See Ex. 1001, Blaze Decl. at ¶¶ 113-116.)
`Kapidzic discloses the method of verifying of claim 23
`in which a public key certificate of a sender may also
`be verified by a direct inquiry to the certification
`authority which issued that certificate (e.g., the process
`of retrieving a user’s certificate for verification
`involves communication between a certificate
`requester and the UCA [User Certification Authority]
`which issued that certificate).
`
`“The process of retrieving a user’s certificate involves
`communication between a certificate requester and the
`15
`
`
`
`’574 Patent Claim
`
`[24] The method of
`verifying of claim 23 in
`which a public key
`certificate for every
`computer process in the
`infrastructure between the
`sender and a common
`point of trust is also
`verified against all
`relevant certificate
`revocation lists.
`
`[25] The method of
`verifying of claim 23 in
`which a public key
`certificate of a sender
`may also be verified by a
`direct inquiry to the
`certification authority
`which issued that
`certificate.
`
`
`
`
`
`

`

`
`
`’574 Patent Claim
`
`Kapidzic
`UCA which issued that certificate, or else by
`communication directly between the certificate
`requester and the certificate owner. In either case it is
`by means of two messages: Certificate Request and
`Certificate Reply.” (Ex. 1007 at 008.)
`
`“The case when the certificate is requested from the
`UCA is shown in Figure 3. The CMS UA [User
`Agent] sends a Certificate Request, which contains
`either the owner’s DN or the owner’s address.” (Ex.
`1007 at 008.)
`
`
`“The UCA, upon receiving the Certificate Request,
`indexes the local database for the requested certificate,
`which it returns to the requester in a Certificate
`Reply.” (Ex. 1007 at 008.)
`
`“[T]he Certificate Reply . . . contains the requested
`certificate as well as all the certificates in the
`certificate verification path, up to the top of the
`hierarchy. The verification procedure is the same as
`for the Certificate Signature Reply.” (Ex. 1007 at 008.)
`
`(See Ex. 1001, Blaze Decl. at ¶¶ 117-120.)
`Kapidzic discloses the method of verifying of claim 23
`in which a public key certificate for every computer
`process in the infrastructure between the sender and a
`common point of trust may be obtained from
`
`16
`
`[26] The method of
`verifying of claim 23 in
`which a public key
`certificate for every
`
`
`
`

`

`
`
`’574 Patent Claim
`computer process in the
`infrastructure between the
`sender and a common
`point of trust may be
`obtained from respective
`individual computer
`processes.
`
`Kapidzic
`respective individual computer processes (e.g., the
`process of retrieving a user’s certificate involves
`communication directly between the certificate
`requester and the certificate owner).
`
`“The requester can send the Certificate Request
`directly to the owner, and ask him/her for his/her
`current certificate, as show in Figure 4.” (Ex. 1007 at
`009.)
`
`
`
`
`“The owner replies with the Certificate Reply, which
`contains the owner’s own certificate and the full
`certificate verification path.” (Ex. 1007 at 009.)
`
`(See Ex. 1001, Blaze Decl. at ¶¶ 121-124.)
`Kapidzic discloses the method of verifying of claim 23
`in which a public key certificate for every computer
`process in the infrastructure may also be obtained from
`a common repository (e.g., from an X.500 directory).
`
`“The responsibility for storage and distribution of
`certificates is deferred to X.500 directories.” (Ex. 1007
`at 005.)
`
`(See Ex. 1001, Blaze Decl. at ¶¶ 125-128.)
`Kapidzic discloses in a certification system for secure
`communications containing computer processes
`arranged in a certification infrastructure (e.g., the
`Certificate Management System), a method of
`17
`
`[27] The method of
`verifying of claim 23 in
`which a public key
`certificate for every
`computer process in the
`infrastructure may also be
`obtained from a common
`repository.
`
`[28] In a certification
`system for secure
`communications
`containing computer
`
`
`
`

`

`
`
`’574 Patent Claim
`processes arranged in a
`certification
`infrastructure, a method
`of validating public key
`certificates comprising:
`
`using the certificate
`revocation lists of each
`computer process
`between a computer
`process or user whose
`certificate is being
`validated and a point of
`trust in common with the
`computer process or user
`which is validating the
`certificate to ensure the
`certificates being used in
`the validation process do
`not appear on any
`certificate revocation list.
`
`Kapidzic
`validating public key certificates (e.g., the certificate
`verification process includes a check that the
`otherwise seemingly valid certificate has not been
`revoked).
`
`“The Certificate Management System (CMS) is a
`networked system for generation, distribution, storage
`and verification of certificates for use in a variety of
`security enhanced applications.” (Ex. 1007 at 005.)
`
`“The certificate verification process must therefore
`include a check that the otherwise seemingly valid
`certificate has not been revoked.” (Ex. 1007 at 010.)
`
`(See Ex. 1001, Blaze Decl. at ¶¶ 129-134.)
`Kapidzic discloses using the certificate revocation lists
`of each computer process between a computer process
`or user whose certificate is being validated (e.g., the
`parent Certification Authority) and a point of trust in
`common (e.g., the Policy Certification Authority) with
`the computer process or user which is validating the
`certificate (e.g.,