Trials@uspto.gov
`571.272.7822
`
`Paper No. 12
`Filed: November 6, 2014
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`COMPASS BANK, COMMERCE BANCSHARES, INC., and
`FIRST NATIONAL BANK OF OMAHA,
`Petitioner,
`
`v.
`
`INTELLECTUAL VENTURES II LLC,
`Patent Owner.
`
`Case IPR2014-00724
`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
`
`Compass Bank, Commerce Bancshares, Inc., and First National Bank
`
`of Omaha (collectively, “Petitioner”) filed a petition to institute an inter
`
`partes review (Paper 1, “Pet.”) of claims 18–31 (the “challenged claims”) of
`
`U.S. Patent No. 5,745,574 (Ex. 1002, “the ’574 patent”). 35 U.S.C. § 311.
`
`
`
`Intellectual Ventures Exhibit 2004
`IBM v. Intellectual Ventures
`IPR2014-01410
`
`
`571.272.7822
`
`Paper No. 12
`Filed: November 6, 2014
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`COMPASS BANK, COMMERCE BANCSHARES, INC., and
`FIRST NATIONAL BANK OF OMAHA,
`Petitioner,
`
`v.
`
`INTELLECTUAL VENTURES II LLC,
`Patent Owner.
`
`Case IPR2014-00724
`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
`
`Compass Bank, Commerce Bancshares, Inc., and First National Bank
`
`of Omaha (collectively, “Petitioner”) filed a petition to institute an inter
`
`partes review (Paper 1, “Pet.”) of claims 18–31 (the “challenged claims”) of
`
`U.S. Patent No. 5,745,574 (Ex. 1002, “the ’574 patent”). 35 U.S.C. § 311.
`
`
`
`Intellectual Ventures Exhibit 2004
`IBM v. Intellectual Ventures
`IPR2014-01410
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`Intellectual Ventures II LLC (“Intellectual Ventures” or “Patent Owner”)
`
`filed a preliminary response (Paper 9, “Prelim. Resp.”) on August 8, 2014.
`
`We have jurisdiction under 35 U.S.C. § 314.1 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 Petitioner 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
`
`Petitioner indicates the ’574 patent is at issue in several district court
`
`proceedings involving numerous parties. Pet. 1–2; Paper 11, 2–4. Petitioner
`
`indicates that International Business Machines Corporation also has filed
`
`two petitions for inter partes review of the ’574 patent (IPR2014-00660 and
`
`IPR 2014-01410) and a petition for a covered business method patent review
`
`(CBM2014-00160). Pet. 2; Paper 11, 4.
`
`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.
`
`
`1 Patent Owner requests denial of the petition based on Petitioners’ use of
`Arial Narrow Font. Prelim. Resp. 3–4, 25–26. Because the proceedings are
`no longer in the preliminary stage, we are not persuaded that it is in the
`interest of the efficient administration of the Office to dismiss the petition
`based on this argument.
`
`2
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`1002, 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
`
`by the sender. Id. at 1:57–65. A public key infrastructure (PKI), with a
`
`hierarchical system of encrypting public lower nodes’ public keys, allows
`
`for a common point of trust between two parties who wish to communicate
`
`with each other. Id. at 3:16–39. The ’574 patent explains that some of the
`
`problems with conventional PKE systems include that such systems do not
`
`have a “consistent public key infrastructure which can actually and
`
`automatically provide the certifications required for a public key system[, a]
`
`hierarchical arrangement of certifying authorities which can cross policy
`
`certifying authority boundaries[, or a convenient and transparent] way for
`
`permitting secure transactions to cross organizational boundaries.” Id. at
`
`4:41–51. The ’574 patent purports to “provid[e] a full, correct, consistent
`
`and very general security infrastructure which will support global secure
`
`electronic transactions across organizational, political and policy certifying
`
`authority boundaries.” Id. at 4:55–59.
`
`The challenged claims recite various processes used within a PKI
`
`system to request, issue, and update public key certificates, add nodes or
`
`entities (described as “computer processes” in the ’574 patent) to the
`
`3
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`hierarchy, and verify and validate certificates received. Figure 4 of the ’574
`
`patent is reproduced below:
`
`
`
`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. 1002, 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:36–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
`
`4
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`the PCA. Ex. 1002, 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
`
`the issuing CA (the CA above it in the hierarchy) to request a signature from
`
`that CA. Ex. 1002, 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. 1002,
`
`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
`
`5
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`public key that corresponds to the private key used for signing the message
`
`sent from the node to the issuing CA. Ex. 1002, 14:54–60, 15:10–22. If the
`
`keys match, the node stores the signed certificate. Id. at 14:61–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. 1002, 1:57–65,
`
`3:22–39, 6:65–7:20, 11:66–12:43. Referring back to Figure 4, U1 may
`
`receive a signed message from user U2. Id. at 12:1–2, Fig. 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, Fig. 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.
`
`6
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`1002, 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. 1002, 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.
`
`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:
`
`In a certification system for secure communications
`18.
`computer processes
`arranged
`in
`a
`certification
`containing
`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.
`
`7
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`In a global network with secure communications
`23.
`computer processes
`arranged
`in
`a
`certification
`containing
`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.
`
`In a certification system for secure communications
`28.
`computer processes
`arranged
`in
`a
`certification
`containing
`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.
`
`In a computer system for secure communications
`30.
`computer processes
`arranged
`in
`a
`certification
`containing
`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
`
`8
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`computer processes subordinate in the infrastructure to said first
`computer process have the new certificates.
`
`In a certification system for secure communications
`31.
`computer processes
`arranged
`in
`a
`certification
`containing
`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,
`
`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.
`
`E. The Evidence of Record
`Petitioner relies upon the following prior art references2 as its basis for
`
`challenging claims 18–31 of the ’574 patent:
`
`Exhibit
`1004
`(“Kapidzic”)
`
`1005
`(“PKI Report”)
`
`Printed Publication
`Nada Kapidzic & Alan
`Davidson, A Certificate
`Management System: Structure,
`Functions and Protocols,
`Proceedings of the Symposium
`on Network and Distributed Sys.
`Sec. 10–17 (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 1–193
`(April 1, 1994)
`
`2 Petitioner also proffers the declaration of Dr. David Naccache. Ex. 1001.
`
`Reference
`Kapidzic
`
`PKI Report
`
`9
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`RFC 1424
`
`Burton S. Kaliski, Jr., Privacy
`Enhancement for Internet
`Electronic Mail: Part IV: Key
`Certification and Related
`Services, Network Working
`Group, Request for Comments:
`1424 1–9 (1993)
`
`1006
`(“RFC 1424”)
`
`F. The Asserted Grounds of Unpatentability
`
`Petitioner contends that the challenged claims are unpatentable under
`
`35 U.S.C. §§ 102 and/or 103 based on the following grounds (Pet. 4):
`
`Statutory Ground
`§ 102(a)
`§ 102(b)
`§ 103(a)
`§ 103(a)
`
`Challenged Claims
`Reference
`18–31
`Kapidzic
`23–31
`PKI Report
`25, 29, 30
`PKI Report
`PKI Report + RFC 1424 18–22
`
`A. Real Party-In-Interest
`
`ANALYSIS
`
`Patent Owner asserts that the petition should be denied for failing to
`
`name all real parties in interest, as required by 35 U.S.C. § 312(a)(2).
`
`Prelim. Resp. 5–10. Specifically, Patent Owner contends that Petitioners
`
`failed to name Banco Bilbao Vizcaya Argentaria, S.A. (BBVA) as a real
`
`party-in-interest. Id. at 7. Patent Owner asserts that BBVA is a real party-
`
`in-interest because it owns and controls BBVA Compass Bancshares, Inc.
`
`(“BBVA Compass”), one of the identified real parties-in-interest. Id. at 7–8.
`
`Patent Owner argues that BBVA Compass has admitted that it is controlled
`
`by BBVA, and admitted that BBVA serves as a source of strength and
`
`capital to BBVA Compass. Id. at 8 (citing Ex. 2002, 28, 30).
`
`Whether a party who is not a named participant constitutes a real
`
`party-in-interest to a proceeding is a highly fact-dependent question. Office
`
`10
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`Patent Trial Practice Guide, 77 Fed. Reg. 48,756, 48,759 (Aug. 14, 2012)
`
`(citing Taylor v. Sturgell, 553 U.S. 880 (2008); 18A Charles Alan Wright,
`
`Arthur R. Miller & Edward H. Cooper, Federal Practice & Procedures §§
`
`4449, 4451 (2d ed. 2011)). The Office Patent Trial Practice Guide provides
`
`guidance regarding factors to consider in determining whether a party is a
`
`real party-in-interest. Id. One important consideration is whether a non-
`
`party exercises, or could have exercised, control over a party’s participation
`
`in the proceeding. Id. An example justifying the real party-in-interest label
`
`is a party that funds and directs and controls an IPR petition or proceeding.
`
`Id. at 48,760.
`
`Although Patent Owner’s evidence demonstrates a parent-subsidiary
`
`relationship between BBVA and BBVA Compass, Patent Owner’s evidence
`
`does not demonstrate sufficiently that BBVA exercised or could have
`
`exercised control over BBVA Compass’s filing of the petition. Likewise,
`
`Patent Owner’s evidence does not demonstrate sufficiently that BBVA
`
`funded, directed, and controlled the filing of the petition.
`
`Based on the record before us, Patent Owner does not provide a
`
`sufficient factual basis to conclude that BBVA should have been identified
`
`as a real party-in-interest. Accordingly, we decline to deny the petition for
`
`failure to identify all real parties in interest under 35 U.S.C. § 312(a)(2).
`
`B. 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.100(b). Applying that standard, we interpret the claim terms of the
`
`’574 patent according to their ordinary and customary meaning in the
`
`11
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`context of the patent’s written description. See In re Translogic Tech., Inc.,
`
`504 F.3d 1249, 1257 (Fed. Cir. 2007). We find, for purposes of this
`
`decision, it is not necessary to construe explicitly any term at this time.
`
`C. The Asserted Grounds
`
`1. Anticipation of Claims 18–31 by Kapidzic
`
`Petitioner challenges claims 18–31 as anticipated by Kapidzic,
`
`supported by a chart showing where Kapidzic allegedly discloses each claim
`
`limitation. Pet. 15–34. Intellectual Ventures elects not to present argument
`
`addressing whether Kapidzic discloses the subject matter of the challenged
`
`claims at this time. Prelim. Resp. 24–25.
`
`a. Kapidzic (Ex. 10043)
`
`Kapidzic is one paper in a collection of papers, which were the subject
`
`of a symposium on network and distributed system security. Ex. 1004, 10.
`
`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.” Id.
`
`Figure 1 of Kapidzic is reproduced below:
`
`
`3 References to pages in Exhibit 1004 are to the pagination inserted by
`Petitioner rather than to the original pagination of the document.
`
`
`
`12
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`Figure 1 depicts a logical representation of a hierarchy within a public key
`
`infrastructure of the CMS disclosed by Kapidzic. Ex. 1004, 11. Kapidzic
`
`uses the certificates defined in the X.509 standard and uses a hierarchy with
`
`the Internet Policy Registration Authority (IPRA) as a single root Policy
`
`Certification Authority (PCA) in a hierarchical infrastructure of Certification
`
`Authorities (CAs). Id. at 10.
`
`b. Claims 18–22
`
`Kapidzic discloses a certification process starting with generating a
`
`pair of keys (a public key and a private key), sending a self-signed certificate
`
`request message to a CA, and the CA sending back a message with a signed
`
`certificate, which Petitioner maps to “a method of requesting and issuing a
`
`public key certificate,” as recited in the preamble of independent claim 18.
`
`Pet. 17–18, 21 (citing Ex. 1004, 10–134). Specifically, Petitioner maps
`
`Kapidzic’s disclosure of a CA generating a pair of keys and sending a self-
`
`signed certificate created from the public key to a parent CA to the method
`
`step reciting that one process generates a certificate with a public key, self-
`
`signs the certificate, and sends the self-signed certificate in a request to an
`
`issuing CA. Id. at 17–18, 21–22 (citing Ex. 1004, 10, 12–13). Kapidzic
`
`further discloses a parent CA verifying the request, signing the certificate,
`
`and sending a reply back to the requester, which Petitioner maps to the
`
`recited step of the issuing CA process “verifying the authenticity of said
`
`request, and . . . certifying and returning the” certificate to the requesting
`
`process in a reply. Id. at 18, 22 (citing Ex. 1004, 10, 12–13).
`
`
`4 Although Petitioner refers to the original pagination in the document, for
`consistency, we refer to the pagination inserted by Petitioner rather than the
`original pagination of the document.
`
`13
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`The description of Kapidzic’s certification process that is cited as
`
`disclosing the method recited in independent claim 18 is supported by Figure
`
`2 of Kapidzic. Figure 2 of Kapidzic is reproduced below:
`
`
`
`Figure 2 depicts an example of a certification process of a CA by its parent
`
`CA (in this case a PCA) in the CMS disclosed by Kapidzic. Ex. 1004, 12.
`
`Reviewing Figure 2 and the disclosure of Kapidzic cited by Petitioner, we
`
`are persuaded Petitioner 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
`
`14
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`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.” We have reviewed the arguments and evidence submitted by
`
`Petitioner, and based on the record before us, Petitioner demonstrates a
`
`reasonable likelihood that claims 19–22 are anticipated by Kapidzic.
`
`c. Claims 23–27
`
`Kapidzic discloses a hierarchical infrastructure with a PCA as a
`
`common root of the entire hierarchy, where each user or CA is certified by a
`
`parent CA. Pet. 25 (citing Ex. 1004, 10–11, 13–14). Kapidzic explains that
`
`a CA sends 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 Petitioner 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. Id. at 25–26 (citing Ex. 1004, 13–14). Kapidzic also
`
`discloses “verif[ying] the signatures of the certificates from the message,
`
`starting from the PCA’s certificate” down to the lowest level certificate in
`
`the message, which Petitioner maps to “verifying the authenticity of
`
`signatures iteratively, beginning with the common point of trust,” as recited
`
`in independent claim 23. Id. at 26 (citing Ex. 1004, 13). 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
`
`15
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`signed certificate. Id. We are persuaded, on this record, that Petitioner
`
`demonstrates a reasonable likelihood that claim 23 is anticipated by
`
`Kapidzic.
`
`Claims 24–27 depend directly from claim 23 and recite limitations
`
`relating to the use of Certificate Revocation Lists (CRLs), how the
`
`certificates are verified, and the location from which the certificates are
`
`obtained. We have reviewed the arguments and evidence submitted by
`
`Petitioner, and on this record, we are persuaded that Petitioner 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. 1004, 15. 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. Petitioner
`
`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. 29. Kapidzic also
`
`discloses storing CRLs for later use in verification after retrieval of CRLs
`
`and obtaining CRLs if they are not available locally, which Petitioner maps
`
`to “retrieved certificate revocation lists are stored locally in the computer at
`
`which the certificate is being validated,” as recited in dependent claim 29.
`
`Id. (citing Ex. 1004, 15–16). We have reviewed the arguments and evidence
`
`submitted by Petitioner, and on this record, we are persuaded Petitioner
`
`16
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`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. 1004, 13–14. Kapidzic also discloses that “when
`
`a certificate is updated, the old certificate must be revoked” 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 12, 14. Petitioner maps those disclosures of Kapidzic to
`
`the method of updating certificates recited in independent claim 30. Pet. 30–
`
`32 (citing Ex. 1004, 10–15). On this record, we are persuaded Petitioner
`
`demonstrates a reasonable likelihood that claim 30 is anticipated by
`
`Kapidzic.
`
`f. Claim 31
`
`Kapidzic discloses that “[t]he certification hierarchy is established
`
`top-down, starting with the PCA,” which is responsible for the
`
`administration of the hierarchy structure. Ex. 1004, 11–12. Kapidzic further
`
`discloses that establishment of a CA includes two phases, specifically
`
`registration and certification (the request for and signing of a certificate
`
`discussed above) and that “[n]o CA can be added to the hierarchy without
`
`first registering its DN with the PCA.” Id. at 11–12. In order to register
`
`itself, a CA may provide a suggested “relative distinguished name” and the
`
`name of its parent CA, which specifies its place in the CMS hierarchy. Id. at
`
`12. Upon receipt of that information, the PCA may generate a unique
`
`17
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`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.
`
`Petitioner 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. 33 (citing Ex. 1004, 10–12).
`
`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. 1004, 13. 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. Petitioner 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. 33–34 (citing Ex. 1004, 12–14). On this record, we are
`
`persuaded Petitioner demonstrates a reasonable likelihood that claim 31 is
`
`anticipated by Kapidzic.
`
`2. Anticipation of Claims 23–31 by PKI Report, Obviousness of
`Claims 18–22 over PKI Report and RFC 1424, and
`Obviousness of Claims 25, 29, and 30 over PKI Report
`
`Petitioner challenges claims 18–22 as obvious over PKI Report
`
`combined with RFC 1424, claims 23–31 as anticipated by PKI Report, and
`
`claims 25, 29, and 30 as obvious over PKI Report. Pet. 38–59. Intellectual
`
`18
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`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. 24–25.
`
`a. PKI Report (Ex. 10055)
`
`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. 1005, 5, 7. PKI Report addresses issues of a Public Key Infrastructure
`
`(PKI) for automatically managing public keys using public key certificates.
`
`Id. at 7. PKI Report includes sections on architectural alternatives for a
`
`certificate management infrastructure (Section 3), implementation
`
`alternatives (Section 4), and operational concepts, which include generation,
`
`certification, and distribution of keys, signature and verification, caching of
`
`certificates, and the use of Certificate Revocation Lists (CRLs) (Section 5).
`
`Id. at 15–16.
`
`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. Ex. 1005, 15–16. The entities
`
`within the PKI may be arranged in a hierarchical structure. Id. at 8. 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. Id. at 22.
`
`
`5 References to pages in Exhibit 1005 are to the pagination inserted by
`Petitioner rather than to the original pagination of the document.
`
`19
`
`
`
`IPR2014-00724
`Patent 5,745,574
`
`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. Ex. 1005, 22, 26. The verifier may have confidence in the
`
`integrity of the key used to decrypt a message “because it 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 26. Thus, the verifier must
`
`hold a chain of truste
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
