Trials@uspto.gov
`Tel: 571-272-7822
`
`Paper 19
`Entered: Oct. 20, 2014
`
`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.
`
`Cases IPR2014-00660
`Patent 5,745,574
`
`
`
`
`
`
`
`
`
`Before KRISTEN L. DROESCH, JENNIFER S. BISK, and
`JUSTIN BUSCH, Administrative Patent Judges.
`
`BUSCH, Administrative Patent Judge.
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`INTRODUCTION
`
`A. Background
`International Business Machines Corporation (“IBM” or “Petitioner”)
`filed a second corrected Petition to institute an inter partes review (Paper 13,
`“Pet.”) of claims 18–31 (the “challenged claims”) of U.S. Patent No.
`5,745,574 (Ex. 1004, “the ’574 patent”). Intellectual Ventures II LLC
`
`Intellectual Ventures Exhibit 2002
`IBM v. Intellectual Ventures
`IPR2014-01410
`
`
`Tel: 571-272-7822
`
`Paper 19
`Entered: Oct. 20, 2014
`
`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.
`
`Cases IPR2014-00660
`Patent 5,745,574
`
`
`
`
`
`
`
`
`
`Before KRISTEN L. DROESCH, JENNIFER S. BISK, and
`JUSTIN BUSCH, Administrative Patent Judges.
`
`BUSCH, Administrative Patent Judge.
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`INTRODUCTION
`
`A. Background
`International Business Machines Corporation (“IBM” or “Petitioner”)
`filed a second corrected Petition to institute an inter partes review (Paper 13,
`“Pet.”) of claims 18–31 (the “challenged claims”) of U.S. Patent No.
`5,745,574 (Ex. 1004, “the ’574 patent”). Intellectual Ventures II LLC
`
`Intellectual Ventures Exhibit 2002
`IBM v. Intellectual Ventures
`IPR2014-01410
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`(“Intellectual Ventures” or “Patent Owner”) filed a Preliminary Response
`(“Prelim. Resp.”) on July 23, 2014. Paper 14.
`We have jurisdiction under 35 U.S.C. § 314. The standard for
`instituting an inter partes review is set forth in 35 U.S.C. § 314(a), which
`provides that an inter partes review may not be instituted “unless the
`Director determines . . . there is a reasonable likelihood that the petitioner
`would prevail with respect to at least 1 of the claims challenged in the
`petition.”
`After considering the Petition and Preliminary Response, we
`determine that IBM has established a reasonable likelihood of prevailing on
`at least one ground on all of the challenged claims. Accordingly, we
`institute an inter partes review of claims 18–31.
`
`B. Related Proceedings
`IBM indicates the ’574 patent is at issue in several district court
`proceedings involving numerous parties, none of which name IBM as a
`defendant. Pet. 2; Paper 16, 2–3. Petitioners also indicate that the ’574
`patent is the subject of a co-pending petition for inter partes review
`(IPR2014-00724) and a co-pending petition for a covered business method
`patent review (CBM2014-00160). Paper 16, 3.
`
`C. The ’574 Patent
`The ’574 patent relates to public key encryption (PKE), which is used
`for securing and authenticating transmissions over unsecure networks. Ex.
`1004, 1:6–8, 1:10–2:9. To use PKE for authenticating transmissions, a
`transmitted message is encrypted with a sender’s private encryption key (a
`key known only to the sender) that can only be decrypted by the sender’s
`public encryption key (freely available), ensuring that the message was sent
`
`2
`
`
`
`
`
`IPR22014-006660
`
`
`Patennt 5,745,5774
`
`autommatically pprovide thee certificattions requirred for a puublic key ssystem[, a]]
`
`Id. at 1:57
`
`
`by thhe sender.
`
`
`7–65. A puublic key iinfrastructuure (PKI),
`with a
`
`
`
`
`
`
`
`hieraarchical syystem of enncrypting ppublic loweer nodes’ ppublic keyss, allows
`
`
`
`
`
`
`
`for aa common point of truust betweeen two partties who wwish to commmunicate
`
`
`
`
`
`
`withh each other. Id. at 3:16–39. Thhe ’574 patatent explaiins that somme of the
`
`conventio
`
`probblems with
`
`
`
`
`nal PKE syystems incclude that ssuch systemms do not
`
`
`
`
`
`
`
`havee a “consisttent publicc key infrasstructure wwhich can aactually annd
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`hieraarchical arrrangementt of certifyiing authoriities whichh can crosss policy
`way for
`
`
`
`
`
`
`certiifying authhority bounndaries[, orr a conveniient and traansparent]
`” Id. at
`
`
`
`
`
`
`permmitting secuure transacctions to crross organiizational booundaries.”
`
`
`
`
`
`4:41–51. The ’574 patennt purports to “providd[e] a full,
`
`correct, coonsistent
`
`
`
`
`
`
`
` secure and vvery generral securityy infrastruccture whichh will suppport global
`
`
`
`
`electtronic transsactions accross organnizational,
`
`
`political aand policy ccertifying
`
`
`
`authority bounndaries.” Idd. at 4:55––59.
`
`a PKI
`
`
`
`The challlenged claaims recite various prrocesses ussed within
`
`
`
`
`
`
`
`
`
`systeem to request, issue, and updatee public keey certificaates, add noodes or
`
`
`
`
`entitties (described as “coomputer proocesses” inn the ’574
`the
`
`patent) to
` received.
`
`
`
`
`
`
`hieraarchy, and verify andd validate ccertificates
`
`
`
`patennt is reprodduced beloow:
`
` Figure 4 oof the ’5744
`
`
`
`3
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`Figure 4 depicts a logical representation of a portion of a hierarchical PKI
`and one way in which that infrastructure may be used to verify transactions.
`Ex. 1004, 8:17–29. As can be seen in Figure 4, a hierarchy includes
`certification authorities (CAs) CA1–CA4 and users U1,U2. Id. at Fig. 4. Not
`depicted in Figure 4 above the certification authorities is a policy certifying
`authority (PCA), “which defines a particular set of certification policies
`[and] set the standards for their particular certification sub-hierarchies.” Id.
`at 9:26–30. Each of the CAs follows the policies set by the PCA they fall
`under and can then certify CAs underneath them “in a hierarchical fashion
`until ultimately the end users are certified at the bottom of the hierarchy.”
`Id. at 9:37–42.
`In order for U2 to be added to the hierarchy and obtain a public key
`certificate, which will allow U2 to send communications that can be verified
`and validated by a recipient, U2 would send an application for registration to
`the PCA. Ex. 1004, 13:65–67. Any other node would follow the same
`procedure in order to participate in the PKI and obtain certificates so that
`CAs may certify other nodes and so that users may send communications
`that can be verified and validated by a recipient. The PCA may accept or
`reject the application for registration. Id. at 14:1–7. If the PCA accepts the
`application, the new node is added to a network map certification
`infrastructure database and the node performs steps to obtain a certificate.
`Id. at 15:59–67.
`A CA or user obtains a certificate by generating new public and
`private keys, generating a certificate including the newly generated public
`key and any other information required by the policies established by the
`PCA, self-signing the certificate, and sending the certificate in a message to
`
`4
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`the issuing CA (the CA above it in the hierarchy) to request a signature from
`that CA. Ex. 1004, 14:24–34, 15:4–9. The CA uses policies established by
`the PCA to authenticate the request. Id. at 14:35–41. If authenticated, the
`CA signs the certificate, stores a copy and/or sends a copy to a certificate
`repository, and issues the certificate by sending the signed certificate back to
`the CA or user in a reply message. Id. at 14:47–52.
`When a node’s certificate expires, the node follows a similar process
`of generating new keys and requesting issuance of a new certificate from its
`issuing CA. If the issuing CA determines that the requesting node is an
`already-existing node, the issuing CA also marks the node’s old certificate
`as revoked and adds it to a certificate revocation list (CRL). Ex. 1004,
`14:43–47.
`The requesting node authenticates the reply message received from
`the issuing CA by comparing the public key in the signed certificate with the
`public key that corresponds to the private key used for signing the message
`sent from the node to the issuing CA. Ex. 1004, 14:54–60, 15:10–22. If the
`keys match, the node stores the signed certificate. Id. at 14:54–63. If the
`node is a CA with subordinate nodes to which it issued signed certificates,
`the CA must update those certificates. Id. at 15:22–25. The CA sends re-
`signed certificates to each of its subordinate nodes (if any), which results in
`each subordinate node iteratively receiving a new signed certificate and
`determining whether that node has subordinate nodes for which it needs to
`reissue certificates. Id. at 15:44–58.
`Once a node receives a signed certificate from its issuing CA, other
`nodes in the PKI may verify and validate the certificate. Ex. 1004, 1:57–65,
`3:22–39, 6:65–7:20, 11:66–12:43. Referring back to Figure 4, U1 may
`
`5
`
`
`
`IPR2014-00660
`Patent 5,745,574
`receive a signed message from user U2. Id. at 12:1–2, Figure 4. U2 may
`send a certificate with the signed message or, in cases where U2 does not
`send a certificate, U1 may request the certificate from U2. Id. at 12:7–13. U1
`may also request a certificate from CA2 and CA3. Id. at 12:12–13.
`Certificates may be obtained from the owner of the certificate, the CA that
`issued the certificate, or from a common repository. Id. at 13:32–35. Each
`node may store a certificate for itself and every CA above that user to the
`highest level node (e.g., PCA or a Policy Registration Authority (PRA),
`which is above a PCA in the PKI hierarchy) such that U1 already has a
`certificate for CA1. Id. at 12:2–6. Thus, as seen in Figure 4, node CA1 is the
`lowest point in the hierarchy in common between U1 and U2 and is known as
`the common point of trust between U1 and U2. Id. at 12:41–43, Figure 4.
`Upon receiving a response to a request for a certificate from a node
`(U2, CA2, and CA3), U1 extracts, verifies, and stores the certificate. Ex.
`1004, 12:17–20. U1 may then authenticate the received certificates starting
`at the top of the hierarchy. Id. at 12:22–42. U1 already has a known valid
`certificate for CA1 and uses CA1’s public key to authenticate CA2’s
`certificate that was issued by CA1. Id. at 12:22–27. The process is iterated
`using CA2’s public key to authenticate CA3’s certificate, then using CA3’s
`public key to authenticate U2’s certificate. Id. at 12:27–39.
`For reliable certification, U1 should also obtain a CRL to ensure that
`each certificate has not been revoked. Ex. 1004, 12:65–67. U1 can send a
`request to CA1, CA2, and CA3 for the CRL list maintained by each CA. Id.
`at 12:67–13:3, 13:14–24.
`
`6
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`D. Illustrative Claims
`Of the challenged claims in the ’574 patent, claims 18, 23, 28, 30, and
`31 are independent. Claims 18, 23, 28, 30, and 31 are each directed to
`method steps for implementing portions of the entire process of using PKE
`to certify secure communications. Therefore, claims 18, 23, 28, 30, and 31
`are illustrative and recite:
`18.
`In a certification system for secure communications
`containing computer 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, and
`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.
`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:
`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.
`28.
`In a certification system for secure communications
`containing computer processes arranged in a certification
`infrastructure, a method of validating public key certificates,
`comprising:
`
`7
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`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.
`30.
`In a computer system for secure communications
`containing computer processes arranged in a certification
`infrastructure, a method of updating certificates, comprising:
`a. at a first computer process, which possesses a certificates to be
`updated, updating the current certificate by
`a.1. receiving a new signed certificate from a computer process
`which is authorized to issue the new signed certificate,
`a.2. revoking the current certificate previously used for
`verification of certificates of subordinate computer
`processes,
`a.3. issuing new certificates to all subordinate computer
`processes for which certificates had been previously signed
`by the first computer process and copying to all subordinate
`computer processes the new certificate to be used for
`verification of new subordinate certificates, and
`b. iteratively performing the distribution of the new certificate to
`all subsequent subordinate computer processes, until all
`computer processes subordinate in the infrastructure to said first
`computer process have the new certificates.
`31.
`In a certification system for secure communications
`containing computer processes arranged in a certification
`infrastructure, a method of adding a new computer process to the
`infrastructure, comprising:
`a. adding a new component to a representation of a certification
`infrastructure at a location indicative of where the said
`computer process is to be added,
`b. creating entries in a certificate storage database at least at both
`said new computer process and at the computer process
`authorized to certify the said new process,
`
`8
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`c. obtaining a signed certificate for the said new computer process
`from said computer process authorized to certify the new
`process and storing it at the said new computer process.
`Ex. 1004, 19:4761, 20:816, 20:3242, 20:4667, 21:114.
`
`Exhibit[s]
`1006, 1007
`(“Kapidzic”)
`
`1008
`(“PKI Report”)
`
`E. The Evidence of Record
`IBM relies upon the following prior art references as its basis for
`challenging claims 18–31 of the ’574 patent.1
`
`Reference[s] Patents/Printed Publications
`Kapidzic
`Nada Kapidzic & Alan
`Davidson, A Certificate
`Management System: Structure,
`Functions and Protocols, Proc.
`of the Symposium on Network
`and Distributed System Security,
`IEEE Computer Society Press,
`153–160 (Feb. 16–17, 1995)
`Shimshon Berkovits et al.,
`Public Key Infrastructure Study:
`Final Report, MITRE Report on
`NIST Request for Study on
`Policy and Legal Issues Related
`to the Operation and
`Management of the PKI (April 1,
`1994)
`Steve Kent, Request for
`Comments 1422: Privacy
`Enhancement for Internet
`Electronic Mail: Part II:
`Certificate-Based Key
`Management, Network Working
`Group of the Internet
`Engineering Task Force (IETF)
`
`PKI Report
`
`RFC 1422
`
`1009, 1010, 1011
`(“RFC 1422”)
`
`
`1 IBM also proffers the declaration of Dr. Matthew Blaze. See Ex. 1001.
`
`9
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`RFC 1424
`
`(1993)
`Burton S. Kaliski, Jr., Request
`for Comments 1424: Privacy
`Enhancement for Internet
`Electronic Mail: Part IV: Key
`Certification and Related
`Services, Network Working
`Group of the Internet
`Engineering Task Force (IETF)
`(1993)
`
`1012, 1013
`(“RFC 1424”)
`
`F. The Asserted Grounds of Unpatentability
`IBM contends that the challenged claims are unpatentable under
`35 U.S.C. §§ 102 and/or 103 based on the following grounds (Pet. 3–5):
`Statutory Ground
`Reference
`Challenged Claims
`§ 102(a)
`Kapidzic
`18–31
`§ 102(b)
`PKI Report
`23–25, 27, 28
`§ 103
`PKI Report
`18–22, 26, 29–31
`§ 102(b)
`RFC 1424
`18
`§ 102(b)
`RFC 1422
`23–29
`§ 103
`RFC 1422 and RFC 1424 19–22, 30, 31
`
`ANALYSIS
`
`A. Claim Construction
`In an inter partes review, claim terms are given their broadest
`reasonable interpretation in light of the specification in which they appear
`and the understanding of others skilled in the relevant art. See 37 C.F.R.
`§ 42.300(b). Applying that standard, we interpret the claim terms of the
`’574 patent according to their ordinary and customary meaning in the
`context of the patent’s written description. See In re Translogic Tech., Inc.,
`504 F.3d 1249, 1257 (Fed. Cir. 2007) (quoting Philllips v. AWH Corp.,
`415 F.3d 1303, 1312 (Fed. Cir. 2005) (en banc)). We do not find it
`
`10
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`necessary, for purposes of this decision, to construe explicitly any term at
`this time.
`
`B. The Asserted Grounds
`1. Anticipation of Claims 18–31 by Kapidzic
`IBM challenges claims 18–31 as anticipated by Kapidzic, supported
`by a chart showing where Kapidzic allegedly discloses each limitation. Pet.
`8–25. Intellectual Ventures elects not to present argument addressing
`whether Kapidzic discloses the subject matter of the challenged claims at
`this time. Prelim. Resp. 1–2 n.1, 14–15.
`a. Kapidzic (Ex. 10072)
`Kapidzic is one paper in a collection of papers, which were the subject
`of a symposium on network and distributed system security. Ex. 1007, 2;
`Ex. 10063, 1. Kapidzic discloses a “Certificate Management System
`(CMS)[, which] is a networked system for generation, distribution, storage
`and verification of certificates for use in a variety of security enhanced
`applications.” Ex. 1007, 5.
`
`
`2 We cite to the exhibit page numbers of Ex. 1007, rather than its original
`pagination.
`3 We cite to the exhibit page numbers of Ex. 1006, rather than its original
`pagination.
`
`11
`
`
`
`
`
`IPR22014-006660
`
`
`Patennt 5,745,5774
`
`
`
`ow: oduced belozic is reproFigure 1 of Kapidz
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Figuure 1 depictts a logicall representtation of a hhierarchy wwithin a puublic key
`
`
`
`infraastructure oof the CMSS disclosedd by Kapiddzic. Id. att 6. As cann be seen
`
`
`
`
`nt,
`
`
`
`
`
`
`fromm comparinng Figure 11 of Kapidzzic to Figuure 4 of thee ’574 paten
`
`
`
`
`Kapiidzic and the ’574 paatent discloose similar
`
`logical hieerarchies.
`
`
`b. Claims 118–22
`
`
`
`
`
`
`Kapidzicc disclosess a CMS inncluding a rrequester ssending a ccertificate
`
`
`
`
`
`
`
`requuest messagge to a certtificate authhority (CAA) and the CCA sendinng back a
`of
`
`
`
`
`
`
`messsage with aa signed ceertificate, wwhich IBMM maps to ““a method
`
`ed in the ppreamble o
`
`
`
`
`
`requuesting andd issuing a ppublic keyy certificatee,” as recit
`f
`
`
`
`
`
`indeppendent cllaim 18. Pet. 8, 10 (cciting Ex. 11007, 5, 7,
`
`
`8). Kapiddzic furtherr
`
`
`
`
`
`
`
`disclloses a CAA generating a pair of f keys (pubblic and priivate) and ssending a
`
` Ex. 10077,
`
`
`
`
`
`
`self-signed cerrtificate creeated from the publicc key to a pparent CA.
`
`
`
`
`
`
`
`7–8. IBM mapps that discclosure of KKapidzic too the first mmethod steep reciting
`that
`
`
`
`
`
`
`one processs generatees a certificcate with aa public keyy, self-signns the
`
`
`certiificate, andd sends the
`
`
`
`
`
`
`self-signed certificatte in a requuest to an iissuing CAA.
`
`12
`
`
`
`
`
`IPR22014-006660
`
`
`Patennt 5,745,5774
`
`
`
`
`Pet. 8, 10. Kappidzic alsoo discloses
`t CA verifi
`
`es the requuest, signs
`the parent
`
`
`
`
`
`
`
`the ccertificate, and sends a reply baack to the rrequester, wwhich IBMM maps to
`
`
`
`
`
`
`
`
`the rrecited stepp of the issuuing CA pprocess “veerifying thee authenticcity of saidd
`
`requuest, and . .
`
`
`. certifyinng and returrning the”
`
`
`certificatee to the reqquesting
`
`
`
`
`proccess in a repply. Id. at 8, 11 (citinng Ex. 10007, 7–8).
`
`
`
`
`
`
`
`Kapidzicc uses the same terminology to
`
`
`
`
`
`
`indeppendent cllaim 18. TThe Petitionn and Dr. MMatthew BBlaze’s dec
`laration
`
`
`
`
`
`
`
`bothh refer to KKapidzic’s ddescriptionn of its certtification pprocess in ssupport of
`
`
`
`
`
`
`
`the aargument thhat Kapidzzic disclosees the methhod recitedd in indepeendent
`
`
`
`
`
`claimm 18. Id. aat 9–11; Exx. 1001 ¶¶ 74, 77. Drr. Blaze al
`
`so referencces Figure
`
`
`
`, ¶ 74), whhich is reprroduced beelow:
`
`
`2 of Kapidizic (Ex. 1001
`
` describe tthe processs recited inn
`
`
`n process oertificationmple of a cets an examFiguure 2 depict
`
`
`
`
`
`its parent
`f a CA by
`
`
`
`
`
`
`
`CA ((in this casse a PCA) iin the CMSS disclosedd by Kapiddzic. Ex. 11007, 7.
`
`
`
`
`
`
`
`Reviiewing Figgure 2 and tthe disclossure of Kappidzic citedd by Petitiooner, we
`
`13
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`are persuaded that IBM demonstrates a reasonable likelihood that
`independent claim 18 is anticipated by Kapidzic.
`Claims 19–22 depend directly from claim 18 and add either an
`additional step of storing the received signed certificate, or define when the
`method of claim 18 is performed, specifically: (1) claim 19 recites “storing
`the received signed certificate at said requesting computer process”;
`(2) claim 20 recites “storing the received signed certificate or copy of a
`signed certificate at a common certificate repository”; (3) claim 21 recites
`performing the method of claim 18 “when adding a new entity to a
`certification infrastructure, which entity may be [a] policy certification
`authority, certification authority, application[,] or end-user”; and (4) claim
`22 recites performing the method of claim 18 “upon expiration of an existing
`certificate, where the new certificate may contain either the existing or a new
`public key.” Ex. 1004, 19:6220:7. We have reviewed the arguments and
`evidence submitted by IBM and, based on the record before us, IBM
`demonstrates a reasonable likelihood that claims 19–22 are anticipated by
`Kapidzic.
`
`c. Claims 23–27
`Kapidzic discloses a CA sending a “Certificate Reply” message
`“contain[ing] the requested certificate as well as all the certificates in the
`certificate verification path, up to the top of the hierarchy,” which IBM maps
`to “obtaining a public key certificate for every computer process in the
`infrastructure between the sender and a common point of trust in the
`infrastructure,” as recited in independent claim 23. Pet. 8, 14 (citing Ex.
`1007, 8). Kapidzic also discloses “verif[ying] the signatures of the
`certificates from the message, starting from the PCA’s certificate” down to
`
`14
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`the lowest level certificate in the message, which IBM maps to “verifying
`the authenticity of signatures iteratively, beginning with the common point
`of trust,” as recited in claim 23. Pet. 14–15 (citing Ex. 1007, 6, 8). The
`portions of Kapidzic cited by Petitioner explain that the verification process
`when requesting a certificate is the same process used when initially
`receiving a signed certificate. Ex. 1007, 8. We are persuaded, on this
`record, that IBM demonstrates a reasonable likelihood that claim 23 is
`anticipated by Kapidzic.
`Claims 24–27 depend from claim 23 and recite limitations relating to
`the use of CRLs, how the certificates are verified, and the location from
`which the certificates are obtained. We have reviewed the arguments and
`evidence submitted by IBM and, on this record, we are persuaded that IBM
`demonstrates a reasonable likelihood that claims 24–27 are anticipated by
`Kapidzic.
`
`d. Claims 28 and 29
`Kapidzic discloses “[t]he certificate verification process must
`therefore include a check that the otherwise seemingly valid certificate has
`not been revoked.” Ex. 1007, 10. As discussed above with respect to claim
`24, Kapidzic also discloses “check[ing] the certificate against the current
`CRL of the same issuer” for every certificate being verified. Id. IBM maps
`those disclosures of Kapidzic to the method of validating a public key
`including using CRLs “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,” as recited in independent claim 28. Pet. 9, 17–19. Kapidzic
`also discloses storing CRLs for later use in verification after retrieval of
`
`15
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`CRLs and obtaining CRLs if they are not available locally, which IBM maps
`to “[t]he method of claim 28 in which retrieved certificate revocation lists
`are stored locally in the computer at which the certificate is being validated,”
`as recited in dependent claim 29. Id. at 19 (citing Ex. 1007, 10–11). We
`have reviewed the arguments and evidence submitted by IBM and, on this
`record, we are persuaded that IBM demonstrates a reasonable likelihood that
`claims 28 and 29 are anticipated by Kapidzic.
`e. Claim 30
`Kapidzic discloses that a new key pair may need to be generated when
`the key expires or is believed to be compromised and that “[w]hen a new
`key pair is generated by some CA, the same procedure is followed as in the
`original certification.” Ex. 1007, 9. Kapidzic also discloses that “[a]fter re-
`issuance of a CA’s certificate, the whole certification sub-hierarchy
`underneath that CA becomes invalidated” and the CA needs to re-sign all
`certificates it has issued with its new key and inform its subordinates of the
`change so that the entire sub-hierarchy can be updated iteratively. Id. at 10–
`11. IBM maps those disclosures of Kapidzic to the method of updating
`certificates recited in independent claim 30. Pet. 9, 19–22 (citing Ex. 1007,
`5, 8–11). On this record, we are persuaded that IBM demonstrates a
`reasonable likelihood that claim 30 is anticipated by Kapidzic.
`
`f. Claim 31
`Kapidzic discloses establishing the CMS hierarchy in a top-down
`manner. Ex. 1007, 7. Kapidzic discloses that establishment of a CA
`includes two phases, specifically registration and certification (the request
`for and signing of a certificate discussed above). Id. In order to register
`itself, a CA may provide a suggested “relative distinguished name” and the
`
`16
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`name of its parent CA, which specifies its place in the CMS hierarchy. Id.
`Upon receipt of that information, the PCA may generate a unique
`distinguished name (DN) for the CA and “[t]he PCA updates its local
`database with the CA’s DN, address, and its position in the hierarchy.” Id.
`IBM maps the disclosures of Kapidzic related to registration of a CA to
`“adding a new component to a representation of a certification infrastructure
`at a location indicative of where the said computer process is to be added,”
`as recited in independent claim 31. Pet. 9, 23 (citing Ex. 1007, 7).
`As part of the certification process in the CMS, Kapidzic discloses
`that the parent CA verifies a request from a CA desiring certification, signs
`the certificate, stores a local copy, and sends a reply with the signed
`certificate back to the requesting CA. Ex. 1007, 8. Kapidzic also discloses
`that the requesting CA verifies the signatures of the certificates from the
`reply message (including its own requested certificate) and stores the
`certificates in a local database. Id. IBM maps those disclosures to “creating
`entries in a certificate storage database at least at both said new computer
`process and at the computer process authorized to certify the said new
`process,” and “obtaining a signed certificate for the said new computer
`process from said computer process authorized to certify the new process
`and storing it at the said new computer process,” as recited in independent
`claim 31. Pet. 23–25 (citing Ex. 1007, 7, 8). On this record, we are
`persuaded that IBM demonstrates a reasonable likelihood that claim 31 is
`anticipated by Kapidzic.
`
`17
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`2. Anticipation of Claims 23–25, 27, and 28 by PKI Report and
`Obviousness of Claims 18–22, 26, and 29–31 over PKI Report
`IBM challenges claims 23–25, 27, and 28 as anticipated by PKI
`Report, supported by a chart showing where PKI Report allegedly discloses
`limitation. Pet. 26, 31–36. IBM challenges claims 18–22, 26, and 29–31 as
`obvious over PKI Report, supported by a chart showing where PKI Report
`allegedly teaches limitation. Id. at 25–31, 34–35, 37–43. Intellectual
`Ventures elects not to present argument addressing whether PKI Report
`discloses or teaches the subject matter of the challenged claims at this time.
`Prelim. Resp. 1–2 n.1, 14–15.
`a. PKI Report (Ex. 1008)
`PKI Report is the result of a study requested by the NIST (National
`Institute of Standards and Technology) and conducted by the MITRE
`Corporation to study “alternatives for automated management of public keys
`and of the associated public key certificates for the Federal Government.”
`Ex. 1008, 5, 6. PKI Report addresses issues of a public key infrastructure
`(PKI) for automatically managing public keys using public key certificates.
`Id. at 6. PKI Report includes user and technical “requirements that relate to
`the generation and distribution of keys, to the obtaining of public key
`certificates and to the distribution of” CRLs. Id. The entities within the PKI
`may be arranged in a hierarchical structure. Id. at 7.
`The PKI described in PKI Report may be used for encrypting
`messages to ensure confidentiality, but the focus of PKI Report is verifying
`the sender of a message. Ex. 1008, 18. In order to verify the signature on a
`message, a recipient must be confident in the integrity of the public key used
`to decrypt the signed message. Id. at 18, 22. The verifier may have
`confidence in the integrity of the key used to decrypt a message “because it
`
`18
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`was manually delivered [or the verifier] obtained it from a certificate signed
`by an entity for which he holds a public key he trusts.” Id. at 22. Thus, the
`verifier must hold a chain of trusted keys back to a common point of trust,
`for which the verifier obtained a key “in a trusted ‘out-of-band’ manner.”
`Id. This chain of trusts is called a certification path (id. at 23) and allows for
`a hierarchical system of validating a certificate by starting with the common
`point of trust and iteratively obtaining the key at the next level until the
`sender’s certificate may be verified using the issuing CA’s key. Id. at 22,
`23. In particular, a “certification path is a sequence of CAs, the first being a
`CA for which the verifier holds a trusted copy of the public key and the last
`being the CA that issued the certificate certifying the needed PKI entity’s
`public key.” Id. at 23.
`Recognizing that keys in global systems may originate from anywhere
`in the world, PKI Report studied alternatives for establishing an automated
`system to manage and distribute keys electronically, namely a PKI. Ex.
`1008, 19. The purposes of the desired PKI include generating public key
`certificates binding the identity of users to their public keys, providing users
`with easy access to other users’ certificates, and providing users with timely
`information regarding revocation of certificates. Id.
`b. Claims 18–22
`IBM challenges claims 18–22 as obvious over PKI Report, supported
`by a chart showing where PKI Report allegedly teaches each limitation. Pet.
`25–26, 28–31. IBM explains that PKI Report describes various
`embodiments but that the various embodiments contain “complementary
`architectures and methods for managing public key certificates, such that
`one having ordinary skill in the art would be motivated to combine their
`
`19
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`teachings,” and that developing a single infrastructure using the desired
`aspects was the point of the study conducted that resulted in PKI Report. Id.
`at 27 (citing Ex. 1001, ¶¶ 186189). Dr. Blaze explains that the PKI Report
`“examined the disclosed standards to develop the PKI infrastructure,” such
`that the “PKI Report can readily be combined with the disclosed standards
`used to develop the PKI Report.” Ex. 1001 ¶ 189. We have reviewed PKI
`Report, Dr. Blaze’s testimony, and the combinations proposed in IBM’s
`challenges and, on this record, we are persuaded that IBM’s rationale for
`combining the various embodiments is reasonable.
`PKI Report explains that a goal of the study is to “design [a public
`key] infrastructure that will allow users to establish chains of trust” and “to
`facilitate trusted electronic correspondence beyond those users with whom
`one has manually exchanged public keys.” Ex. 1008, 23. PKI Report
`“addresses the issues related to a Public Key Infrastructure (PKI), which will
`automatically manage public keys through the use of public key
`certificates.” Id. at 6. PKI Report describes a process for a user or CA to
`obtain a public key certificate including sending a self-signed request
`including the public key to an issuing CA and the issuing CA verifying the
`signature on the request, generating and signing a certificate using its private
`key, and sending
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
