`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`Compass Bank,
`Commerce Bancshares, Inc.,
`First National Bank of Omaha,
`Petitioners
`
`v.
`
`Intellectual Ventures II LLC
`Patent Owner
`
`
`Patent No. 5,745,574
`Filing Date: December 15, 1995
`Issue Date: April 28, 1998
`Title: SECURITY INFRASTRUCTURE FOR ELECTRONIC TRANSACTIONS
`
`
`
`
`Inter Partes Review No. Unassigned
`
`PETITION FOR INTER PARTES REVIEW
`UNDER 35 U.S.C. §§ 311-319 AND 37 C.F.R. § 42.100 ET SEQ.
`
`
`
`
`ATI-2590540v2
`
`Intellectual Ventures Exhibit 2003
`IBM v. Intellectual Ventures
`IPR2014-01410
`
`

`

`TABLE OF CONTENTS
`
`
`2.
`
`3.
`
`Page
`MANDATORY NOTICES UNDER 37 C.F.R. § 42.8(A)(1) ......................................... 1
`A.
`Real Party-In-Interest under 37 C.F.R. § 42.8(b)(1) ....................................... 1
`B.
`Related Matters under 37 C.F.R. § 42.8(b)(2) ................................................ 1
`C.
`Lead and Back-Up Counsel under 37 C.F.R. § 42.8(b)(3) .............................. 2
`D.
`Service Information ......................................................................................... 3
`PAYMENT OF FEES – 37 C.F.R. § 42.103 ............................................................... 3
`REQUIREMENTS FOR IPR UNDER 37 C.F.R. § 42.104 ......................................... 3
`A.
`Grounds For Standing under 37 C.F.R. § 42.104(a) ....................................... 3
`B.
`Identification of Challenge under 37 C.F.R. § 42.104(b) and Relief
`Requested ....................................................................................................... 4
`THE ‘574 PATENT AND CLAIM CONSTRUCTION ................................................... 5
`A.
`Summary of the ‘574 Patent ........................................................................... 5
`B.
`Summary of the Prosecution History of the ‘574 Patent ............................... 10
`C.
`Claim Constructions Under 37 C.F.R. § 42.104(b)(3) ................................... 12
`THERE IS A REASONABLE LIKELIHOOD THAT AT LEAST ONE CLAIM OF
`THE ‘574 PATENT IS UNPATENTABLE ................................................................. 14
`A.
`Kapidzic Anticipates Claims 18-31 ................................................................ 15
`1.
`Claims 18-22 ...................................................................................... 21
`2.
`Claims 23-27 ...................................................................................... 25
`3.
`Claims 28-31 ...................................................................................... 28
`PKI Study Anticipates and/or Renders Obvious Claims 18-31 ..................... 34
`1.
`Claims 18-22 are Obvious in View of PKI Study Combined With
`RFC 1424 .......................................................................................... 38
`PKI Study Anticipates Claims 23-27, and Claim 25 is Obvious
`in View of PKI Study .......................................................................... 45
`PKI Study Anticipates Claims 28-31, and Claims 29 and 30 are
`Obvious in View of PKI Study ............................................................ 51
`CONCLUSION ......................................................................................................... 59
`
`I.
`
`II.
`III.
`
`IV.
`
`V.
`
`VI.
`
`B.
`
`ATI-2590540v2
`
`i
`
`

`

`
`
`LIST OF EXHIBITS
`
`Exhibit 1001: Declaration of David Naccache, Ph.D. (“Naccache Dec.”)
`
`Exhibit 1002: U.S. Patent No. 5,745,574 to Sead Muftic (“the ‘574 patent”)
`
`Exhibit 1003: The ‘574 patent file history
`
`Exhibit 1004: Nada Kapidzic & Alan Davidson, “A Certificate Management System:
`
`Structure, Functions and Protocols” Proceedings, IEEE Symposium on Network and
`Distributed System Security, Feb. 16-17, 1995, at 153-160 (“Kapidzic”)
`
`Exhibit 1005: Shimshon Berkovits, et al., Public Key Infrastructure Study: Final
`Report, April 1, 1994 (“PKI Study”)
`
`Exhibit 1006: Burton Kaliski, Network Working Group Request for Comments: 1424,
`Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related
`Services, Feb. 1993 (“RFC 1424”)
`
`Exhibit 1007: March 24, 2014 Amended Joint Claim Construction and Prehearing
`Statement in Intellectual Ventures II LLC v. First National Bank of Omaha, Case No. 8:13-
`cv-00167 (D. Neb.)
`
`Exhibit 1008: April 23, 2014 Revised Joint Prehearing Statement and Claim
`Construction Chart in Intellectual Ventures II LLC v. Commerce Bancshares, Inc. and
`Commerce Bank, Case No. 2:13-cv-04160-NKL (W.D. Mo.)
`
`Exhibit 1009: April 21, 2014 Joint Claim Construction and Prehearing Statement in
`Intellectual Ventures II LLC v. BBVA Compass Bancshares, Inc. and Compass Bank N.A.
`d/b/a BBVA Compass, Case No. 2:13-cv-01106-AKK (N.D. Ala.)
`
`
`ATI-2590540v2
`
`ii
`
`

`

`
`
`Through counsel, Compass Bank, Commerce Bancshares, Inc., and First National
`
`Bank of Omaha (collectively, “Petitioners”) hereby petition for inter partes review (“IPR”)
`
`under 35 U.S.C. §§ 311-319 and 37 C.F.R. § 42 of claims 18-31 of U.S. Patent No.
`
`5,745,574 (“the ‘574 patent”), and assert that there is a reasonable likelihood that they will
`
`prevail with respect to at least one of the claims challenged in this petition.
`
`I.
`
`MANDATORY NOTICES UNDER 37 C.F.R. § 42.8(a)(1)
`A.
`Real Party-In-Interest under 37 C.F.R. § 42.8(b)(1)
`Compass Bank, BBVA Compass Bancshares, Inc., Commerce Bancshares, Inc.,
`
`Commerce Bank, First National Bank of Omaha, and First National of Nebraska, Inc. are the
`
`real parties-in-interest for the instant petition.
`
`Related Matters under 37 C.F.R. § 42.8(b)(2)
`B.
`Patent Owner Intellectual Ventures II LLC (“IV”) has asserted the ‘574 patent in
`
`seven separate patent infringement lawsuits pending in various district courts: (1)
`
`Intellectual Ventures II LLC v. First National Bank of Omaha, No. 8:13-cv-00167 (D. Neb.).
`
`IV filed this action on May 29, 2013, and served the complaint on June 3, 2013. (2)
`
`Intellectual Ventures II LLC v. BBVA Compass Bancshares, Inc. and Compass Bank N.A.
`
`d/b/a BBVA Compass, No. 2:13-cv-01106 (N.D. Ala.). IV filed this action on June 12, 2013,
`
`and served the complaint on June 12, 2013. (3) Intellectual Ventures II LLC v. Commerce
`
`Bancshares, Inc. and Commerce Bank, No. 2:13-cv-04160 (W.D. Mo.). IV filed this action
`
`on June 20, 2013, and served the complaint on June 21, 2013. (4) Intellectual Ventures II
`
`LLC v. JP Morgan Chase & Co., JPMorgan Chase Bank, N.A., and Chase Bank USA, N.A.,
`
`ATI-2590540v2
`
`1
`
`

`

`
`
`No. 1:13-cv-03777 (S.D.N.Y.). IV filed this action on June 4, 2013, and served the complaint
`
`on June 4, 2013. (5) Intellectual Ventures II LLC v. SunTrust Banks, Inc. and SunTrust
`
`Bank, No. 1:13-cv-02454 (N.D. Ga.). IV filed this action on July 24, 2013, and served the
`
`complaint on July 29, 2013. (6) Intellectual Ventures II LLC v. U.S. Bancorp and U.S. Bank,
`
`No. 0:13-cv-02071 (D. Minn.). IV filed this action on July 31, 2013, and served the
`
`complaint on August 11, 2013. (7) Intellectual Ventures II LLC v. Huntington Bancshares
`
`Inc. and The Huntington National Bank, No. 2:13-cv-00785 (S.D. Ohio). IV filed this action
`
`on August 7, 2013, and served the complaint on August 11, 2013.
`
`In addition, the ‘574 patent was asserted in Prism Technologies, LLC v. VeriSign,
`
`No. 8:08-cv-00195 (D. Neb.), which was filed on April 30, 2008 and dismissed on January 5,
`
`2009.
`
`Finally, on April 17, 2014, IBM filed a petition for inter partes review of claims 18-31
`
`of the ‘574 patent (IPR2014-00660).
`
`Lead and Back-Up Counsel under 37 C.F.R. § 42.8(b)(3)
`C.
`Petitioners provide the following designation of counsel.
`
`LEAD COUNSEL
`Geoffrey K. Gavin (Reg. No. 47,591)
`(ggavin@jonesday.com)
`JONES DAY
`1420 Peachtree Street, N.E., Suite 800
`Atlanta, GA 30309
`T: 404-581-8646; F: 404-581-8330
`BACK-UP COUNSEL
`Marc Vander Tuig (Reg. No. 57,964)
`(MVanderTuig@senniger.com)
`
`BACK-UP COUNSEL
`Joseph Melnik (Reg. No. 48,741)
`(jmelnik@jonesday.com)
`JONES DAY
`1755 Embarcadero Road
`Palo Alto, CA 94303
`T: 650-739-3939; F: 650-739-3900
`BACK-UP COUNSEL
`Jason S. Jackson (Reg. No. 56,733)
`(Jason.Jackson@kutakrock.com)
`
`ATI-2590540v2
`
`2
`
`

`

`
`
`SENNIGER POWERS LLP
`KUTAK ROCK LLP
`100 North Broadway, 17th Floor
`1650 Farnam St., The Omaha Building
`Omaha, NE 68102
`St. Louis, MO 63102
`T: 402-231-8359; F: 402-346-1148
`T: 314-345-7019; F: 314-345-7600
`A power of attorney is being filed with the designation of counsel in accordance with
`
`37 C.F.R. § 42.10(b).
`
`Service Information
`D.
`As identified in the attached Certificate of Service, a copy of the present petition, in
`
`its entirety, is being served to the address of the attorney or agent of record. Petitioners
`
`may be served at the counsel addresses provided in Section I.C of this Petition, and
`
`Petitioners consent to service by email.
`
`II.
`
`PAYMENT OF FEES – 37 C.F.R. § 42.103
`This petition for inter partes review requests review of fourteen (14) claims, so no
`
`excess claim fees are required. The undersigned authorizes the PTAB to charge the fee set
`
`forth in 37 C.F.R. § 42.15(a) for this Petition to Deposit Account No. 503013, ref: 318208-
`
`615002.
`
`III.
`
`REQUIREMENTS FOR IPR UNDER 37 C.F.R. § 42.104
`A.
`Grounds For Standing under 37 C.F.R. § 42.104(a)
`Petitioners certify that the ‘574 patent is eligible for IPR and further certify that they
`
`are not barred or otherwise estopped from requesting IPR challenging the identified claims
`
`on the grounds identified within the present petition.
`
`ATI-2590540v2
`
`3
`
`

`

`
`
`B.
`
`Identification of Challenge under 37 C.F.R. § 42.104(b) and Relief
`Requested
`Petitioners request inter partes review of claims 18-31 of the ‘574 patent on the
`
`grounds set forth in the table below and request that each of the claims be found
`
`unpatentable. An explanation of how claims 18-31 are unpatentable under the statutory
`
`grounds identified below, including the identification of where each element is found in the
`
`prior art publications and the relevance of the prior art references, is provided in the form of
`
`detailed claim charts. Additional explanation and support for each ground of rejection is set
`
`forth in the Declaration of Professor David Naccache, Ph.D. (Exhibit 1001).
`
`Ground
`
`1
`
`2
`
`3
`
`4
`
`‘574 Patent
`Claims
`18-31
`
`18-22
`
`23-31
`
`Basis for Rejection
`
`Anticipated under § 102(a) by Kapidzic
`
`Obvious under § 103 in view of PKI Study plus RFC 1424
`
`Anticipated under § 102(b) by PKI Study
`
`25, 29, 30 Obvious under § 103 in view of PKI Study
`
`Nada Kapdizic & Alan Davidson, “A Certificate Management System: Structure,
`
`Functions and Protocols” Proceedings, IEEE Symposium on Network and Distributed
`
`System Security, 1995, at 153-160 (“Kapidzic,” Exhibit 1004) was published on February 16,
`
`1995, and therefore qualifies as prior art under 35 U.S.C. § 102(a). Shimshon Berkovits, et
`
`al., Public Key Infrastructure Study: Final Report (“PKI Study,” Exhibit 1005) was published
`
`in April 1994, and therefore qualifies as prior art under 35 U.S.C. § 102(b). Burton Kaliski,
`
`ATI-2590540v2
`
`4
`
`

`

`
`
`Network Working Group Request for Comments: 1424, Privacy Enhancement for Internet
`
`Electronic Mail: Part IV: Key Certification and Related Services (“RFC 1424,” Exhibit 1006)
`
`was published in February 1993, and therefore qualifies as prior art under 35 U.S.C. §
`
`102(b). References to §§ 102 and 103 are to the pre-AIA versions of the statute.
`
`IV.
`
`THE ‘574 PATENT AND CLAIM CONSTRUCTION
`A.
`Summary of the ‘574 Patent
`The ’574 patent (Ex. 1002) is titled “Security Infrastructure For Electronic
`
`Transactions” and generally discloses an infrastructure of certification authorities that
`
`provide public key certificates to facilitate secure transactions over an unsecure network
`
`using common certification functions. The ‘574 patent describes “Background Art” in cols.
`
`1-4 of the specification. The patent explains that public key encryption is well known in the
`
`art, for example:
`
` “In a public key encryption system each participant has two related keys. A
`
`public key which is publicly available and a related private key or secret key
`
`which is not. The public and private keys are duals of each other in the sense
`
`that material encrypted with the public key can only be decrypted using the
`
`private key.” (1:34-39.)
`
` “Public key encryption software is widely available. For example, Pretty Good™
`
`Privacy public key encryption software is available …” (2:36-39.)
`
`The patent states that “Public key encryption systems are most vulnerable if the
`
`ATI-2590540v2
`
`5
`
`

`

`
`
`public keys are tampered with.” (2:58-59.) Obtaining the public key directly from the source
`
`confirms its authenticity, but if obtained elsewhere, the key may be unreliable. (3:15-21.)
`
`The inventor acknowledges one known way to address this problem is to obtain the public
`
`key “from a trusted third party who knows he has a good copy of the recipient’s public key.”
`
`(3:23-24.) The trusted party is registered as a certifying authority and signs the public key
`
`to vouch for its integrity. (3:24-40.)
`
`The specification explains that development for secure networks across the Internet
`
`is described in the Network Working Group Request for Comments 1421 (“RFC 1421”) and
`
`Request for Comments 1422 (“RFC 1422”), which the specification states “particularly
`
`addresses certificate-based key management.” (3:65-4:14; 4:10-11.) RFC 1421 and RFC
`
`1422 are dated February 1993 – almost three years before the application for the ‘574
`
`patent was filed – and the ‘574 patent incorporates both of these documents by reference,
`
`while noting that these proposals incorporate concepts utilized in CCITT Recommendations
`
`X.400, X.500, and X.509, which were published in 1988 and “directed to an authentication
`
`framework.” (4:15-19.)
`
`The ‘574 patent suggests the “problems with the prior art proposals” are that they are
`
`directed primarily to email, and not other types of services, and do not represent actual
`
`implementations of systems. (4:20-30.) In addition, the patent suggests the prior art lacks a
`
`“hierarchical arrangement of certifying authorities which can cross policy certifying authority
`
`boundaries …” and “consistent public key
`
`infrastructure which can actually and
`
`ATI-2590540v2
`
`6
`
`

`

`
`
`automatically provide the certifications required for a public key system.” (4:40-48.)
`
`However, the ‘574 patent claims are not directed to new methods for solving these
`
`problems, but instead generic, preexisting methods well known to those skilled in the art.
`
`The inventor nevertheless purported to solve these problems “by providing a multi-
`
`hierarchical certification system for issuing and authenticating public keys used for all types
`
`of electronic transactions and applications.” (5:15-18.) “FIG. 1A is a logical representation
`
`of a hierarchical security or
`
`public key
`
`infrastructure
`
`in
`
`accordance with the invention.”
`
`(9:8-10.) “Each of the blocks in
`
`FIG. 1A is implemented as a
`
`computer process running on a
`
`computer.” (9:64-65.) The ‘574
`
`patent states: “In accordance
`
`with
`
`the
`
`invention,
`
`secure
`
`electronic documents and the
`
`handling of public keys in an
`
`open network, such as
`
`the
`
`Internet, are based on some type of certificate. A certificate is specially constructed data
`
`structure which contains the user’s public key.” (10:35-39.) “In order to guarantee the
`
`ATI-2590540v2
`
`7
`
`

`

`
`
`integrity, authorization and originality of certificate data, each certificate must be issued by
`
`an authority, in this context, called a Certification Authority (CA).” (10:42-45.)
`
`A sample of the data structure for a certificate is shown in Fig. 3 of the patent. The
`
`inventor’s description makes repeated reference to the X.500 and X.509 recommendations
`
`in explaining the fields in the exemplary certificate of Fig. 3. (10:60-11:20.)
`
`“FIG. 4 illustrates how the public key infrastructure in accordance with the invention
`
`can be utilized to verify transactions.”
`
`(11:66-12:1.) User U2 sends a signed
`
`message to user U1, but does not include
`
`a certificate. (12:1-11.) To verify U2’s
`
`signature, user U1 sends a Certificate
`
`Request message to user U2 and to
`
`certifying authorities CA2 and CA3.
`
`(12:12-18.) User U1 receives Certificate
`
`Reply messages from these three entities,
`
`and
`
`their certificates are extracted,
`
`verified, and stored
`
`in
`
`the certificate
`
`database. (12:18-20.)
`
`
`
`Because CA1 is in the direct chain
`
`of hierarchy between user U1 and the root of the hierarchy (referred to the PRA (Policy
`
`ATI-2590540v2
`
`8
`
`

`

`
`
`Registration Authority)), user U1 already has a certificate for CA1 stored in the certificate
`
`storage database. (12:14-16; 12:22-24.) User U1 uses the stored version of CA1’s
`
`certificate to authenticate the certificate from CA2, and, once verified, the valid certificate for
`
`CA2 can be used to verify the certificate for CA3. (12:25-32.) Once CA3’s certificate is
`
`verified as valid, user U1 can use the public key from CA3’s certificate to verify user U2’s
`
`certificate signature. (12:32-36.) Once confident of the validity of U2’s certificate, user U1
`
`can verify the signed message from U2 using U2’s public key and “have considerable
`
`confidence the message is authentic and that no public keys have been tampered with.”
`
`(12:35-40.) CA1 represents the “common point of trust” as it is the lowest point in the
`
`hierarchy common to both user U1 and user U2. (12:40-43.)
`
`
`
`Fig. 5 shows “the process by which a signature may be verified.” (12:44-45.) Fig. 6
`
`depicts an exemplary structure for a certificate revocation list. (13:3-4.) A certificate may
`
`need to be revoked if the private key has been compromised, the certificate has expired, or
`
`there is a user or certification authority (CA) change. (12:61-64.) Utilizing a certificate
`
`revocation list is described further at 13:5-30.
`
`
`
`Finally, Figs. 7-27 show “a set of processes which collectively form the certification
`
`system, functions, and certification infrastructure of this invention.” (13:53-55.) These flow
`
`charts are simplistic and the patent describes them in only a few sentences each. (See
`
`cols. 14-17.) For example, the Certificate_Signature_Request process shown in Fig. 8 and
`
`described at 14:24-34 generally corresponds to the subject matter of claim 18. This process
`
`ATI-2590540v2
`
`9
`
`

`

`
`
`is simple and was well known before the alleged invention in the ‘574 patent, as Petitioners
`
`demonstrate below.
`
`Summary of the Prosecution History of the ‘574 Patent
`B.
`Examination of the ‘574 patent claims was brief and not rigorous. In sum, an initial
`
`rejection of all the claims based on one prior art reference was overcome with a single
`
`response that did little more than simply recite claim limitations while stating that each
`
`limitation was absent from the cited reference.
`
`The original patent application, No. 08/573,025 (“the ‘025 application”), attached
`
`hereto as a part of Exhibit 1003, was filed on December 15, 1995, with claims 1-34. In a
`
`March 31, 1997 first Office Action, the examiner rejected all of claims 1-34 under 35 U.S.C.
`
`§102(e) as anticipated by U.S. Patent No. 5,497,421 to Kaufman et al. The entirety of the
`
`examiner’s rejection was:
`
`
`The patent applicant responded on July 31, 1997, stating that Kaufman did not teach
`
`one or more limitations in each independent claim. For claim 18, the applicant stated
`
`“Independent claim 18 recites ‘a method of requesting and issuing a public key certificate.’
`
`Kaufman distributes a private key to the user and prevents the login agent from having
`
`ATI-2590540v2
`
`10
`
`

`

`
`
`access to the user’s password. Kaufman et al. do not request and issue public key
`
`certificates as recited in claim 18.” (Ex. 1003, 7/31/97 Response at 2.) For claim 23,
`
`applicant stated “Independent claim 23 recites ‘a method of verifying a signed data structure
`
`sent from a sender to a receiver.’ It further requires ‘obtaining a public key certificate for
`
`every computer process in the infrastructure between the sender and a common point of
`
`trust in the infrastructure.’ This is not discussed at all in Kaufman et al. The idea of a
`
`common point of trust is not mentioned in Kaufman et al.” (Ex. 1003, 7/31/97 Response at
`
`2-3.) For independent claims 28, 30, and 31, the applicant made similar statements:
`
`
`On September 12, 1997, the examiner mailed a Notice of Allowability indicating claims 1-34
`
`were allowable, without any further explanation. The ‘574 patent issued in due course on
`
`April 28, 1998.
`
`ATI-2590540v2
`
`11
`
`

`

`
`
`Claim Constructions Under 37 C.F.R. § 42.104(b)(3)
`C.
`A claim subject to IPR is given its “broadest reasonable construction in light of the
`
`specification of the patent in which it appears.” 37 C.F.R. § 42.100(b). This means that the
`
`words of the claim are given their plain meaning unless that meaning is inconsistent with the
`
`specification. In re Zletz, 893 F.2d 319, 321 (Fed. Cir. 1989). Petitioners assert that the
`
`terms in the ‘574 patent claims have their plain and ordinary meaning as understood by a
`
`person of skill in the art. A person of ordinary skill in the art at the time of the alleged
`
`invention would have had ( a ) a bachelor’s degree in computer science, electrical
`
`engineering, software engineering, or a closely related field plus at least two years of
`
`experience with implementation or maintenance of systems for security of electronic
`
`transactions, or (b) a master’s degree in computer science, electrical engineering, software
`
`engineering, or a closely related field with some graduate-level coursework relating to
`
`security for electronic transactions.
`
`In the pending litigations, IV and one or more of Petitioners have agreed to
`
`constructions for the following claim terms:
`
`Term(s)
`
`Agreed Construction in
`
`Source
`
`District Court Litigation
`
`policy certification
`
`authority that defines a particular
`
`Ex. 1007 at 2; Ex. 1009 at 1
`
`authority
`
`set of certification policies
`
`revocation list; or
`
`list(s) identifying revoked
`
`Ex. 1007 at 2; Ex. 1008,
`
`ATI-2590540v2
`
`12
`
`

`

`
`
`Term(s)
`
`Agreed Construction in
`
`Source
`
`District Court Litigation
`
`certificate revocation lists certificates
`
`Ex. A at 18; Ex. 1009 at 2
`
`[upon] expiration of an
`
`on or after the expiration date of
`
`Ex. 1007 at 2; Ex. 1009 at 1
`
`existing certificate
`
`an existing certificate
`
`common point of trust; or
`
`point that is trusted by both the
`
`Ex. 1007 at 2; Ex. 1008,
`
`point of trust in common
`
`sender and the receiver
`
`Ex. A at 18; Ex. 1009 at 1-2
`
`certificate signature
`
`a message requesting that a
`
`Ex. 1009 at 1
`
`request
`
`public key certificate be issued
`
`certificate signature reply a message returning a signed
`
`Ex. 1009 at 1
`
`certificate to the requesting entity
`
`verifying the authenticity
`
`verifying that the request is from
`
`Ex. 1009 at 1
`
`of said request
`
`the requestor
`
`For the purposes of this proceeding, Petitioners believe the above constructions are
`
`consistent with the plain and ordinary meaning of these claim terms under the broadest
`
`reasonable interpretation standard. While IV has offered constructions for additional terms
`
`in the ‘574 patent in the pending litigations, including other constructions that parties may
`
`have agreed to in litigation, Petitioners do not believe such additional terms need
`
`construction in this proceeding, and IV’s constructions for such additional terms are not
`
`consistent with the broadest reasonable interpretation of such terms.
`
`ATI-2590540v2
`
`13
`
`

`

`
`
`Because the standard for claim construction at the Patent Office is different than that
`
`used during a U.S. district court litigation, see In re Am. Acad. of Sci. Tech Ctr., 367 F.3d
`
`1359, 1364, 1369 (Fed. Cir. 2004), Petitioners expressly reserve the right to argue a
`
`different claim construction in litigation for any term of the ‘574 patent as appropriate in such
`
`proceeding.
`
`V.
`
`THERE IS A REASONABLE LIKELIHOOD THAT AT LEAST ONE CLAIM OF THE
`‘574 PATENT IS UNPATENTABLE
`As detailed in the discussion and claim charts below, all limitations of claims 18-31 of
`
`the ‘574 patent were well known in the prior art. Specifically, Kapidzic describes all of the
`
`limitations of claims 18-31, as arranged in the claims. Similarly, PKI Study describes all of
`
`the limitations in claims 18-31 and/or such limitations are obvious in view of PKI Study
`
`combined with other prior art referenced by PKI Study or the knowledge of the skilled
`
`person. Regarding various combinations of prior art, the ‘574 patent claims merely recite
`
`the combination of “prior art elements according to known methods to yield predictable
`
`results” and/or the “[u]se of known technique[s] to improve similar devices (methods, or
`
`products) in the same way.” See KSR Intemational Co. v. Teleflex Inc., 550 U.S. 398,417-
`
`422 (2007).
`
`Claims 18-31 are directed to methods and systems for requesting and issuing public
`
`key certificates, verifying signatures, updating certificates, and adding processes or users to
`
`the infrastructure. The claims are very broad and basic. The claims do little more than
`
`recite familiar prior-art elements (e.g., “obtaining a public key certificate,” “common point of
`
`ATI-2590540v2
`
`14
`
`

`

`
`
`trust,” “certificate revocation lists,” etc.) first set forth in standards and recommendations
`
`that the authors of Kapidzic and PKI Study were also reviewing and that are explicitly
`
`referenced as prior art by the ‘574 patent specification.
`
`Petitioners present focused arguments herein and request IPR on a minimal number
`
`of grounds. Instituting trial on all requested grounds would not conflict with the PTAB’s
`
`statutory mandate nor its rules that require “the just, speedy, and inexpensive resolution of
`
`every proceeding.” The grounds presented in this Petition are not cumulative or redundant.
`
`Kapidzic is an 8-page paper that is §102(a) art and clearly anticipates every claim at issue.
`
`PKI Study does not anticipate every claim, so it may be considered a weaker reference than
`
`Kapidzic. However, PKI Study is a 100+ page report that is §102(b) art. The Patent Owner
`
`cannot antedate this reference, as is possible with Kapidzic. In addition, PKI Study is a
`
`comprehensive report sponsored by the National Institute of Standards and Technology
`
`(NIST) that necessarily provides more depth of discussion regarding the public key
`
`infrastructure. PKI Study may contain more insight into the knowledge and thinking of the
`
`skilled person in this art (at least as of April 1994) than the shorter, more focused Kapidzic
`
`publication, rendering it a stronger reference in some respects. Furthermore, §103 grounds
`
`based on PKI Study are not redundant of §102 grounds based on a different reference
`
`(Kapidzic).
`
`Kapidzic Anticipates Claims 18-31
`A.
`Kapidzic (Ex. 1004) describes a Certificate Management System (CMS):
`
`ATI-2590540v2
`
`15
`
`

`

`
`
`
`(Kapidzic at 153.) Here, Kapidzic specifically addresses several of the so-called “problems”
`
`with the prior art that the ‘574 patent highlighted – namely, the Kapidzic CMS is not limited
`
`to email, utilizes a certification hierarchy, and builds on existing specifications to provide a
`
`“functionally complete and immediately operable” system.
`
`
`
`Kapidzic explains
`
`that
`
`it
`
`is building on
`
`the CCITT 1988 X.500 series of
`
`recommendations, as well as RFC 1421 and RFC 1422 that supplement the X.509
`
`standard. (Id. at 153, §1.) These are the same series of recommendations and standards
`
`identified by the ‘574 patent. (‘574 patent at 4:1-19; 9:23-25; 10:58-11:15.) Kapidzic further
`
`notes that the “structure of a certificate is defined in the X.509 standard” and that RFC 1422
`
`“specifies an Internet wide hierarchical infrastructure of CAs with the Internet Policy
`
`Registration Authority (IPRA) as the single root.” (Kapidzic at 153, Abstract and §1, ¶3.)
`
`Kapidzic confirms that public key certificates and the use of hierarchies were well known
`
`those skilled in the art.
`
`ATI-2590540v2
`
`16
`
`

`

`
`
`Kapidzic’s CMS has a number of co-operating Certification Authorities (CAs). (Id. at
`
`153, §2, ¶1.) The CA’s principle role is to sign certificates and thereby verify that the
`
`certificate has a legitimate binding to the owner’s Distinguished Name (DN). (Id.) The
`
`Policy Certification Authority (PCA)
`
`shown in Figure 1 is responsible for
`
`the administration of the hierarchy and
`
`is the “root of the hierarchy, which
`
`makes it the common point of trust for
`
`verification of all certificates in the
`
`system.” (Id. at 154, §2.1, ¶1.) “No
`
`CA can be added to the hierarchy without first registering its DN with the PCA.” (Id. at 154,
`
`§2.1, ¶3.) Leaf CAs are called User Certification Authorities (UCAs) because of their role in
`
`relation to users. (Id. at 154, §2.1, ¶1.)
`
`
`
`Establishment has two phases, DN registration and certification, and the hierarchy is
`
`established top-down beginning with the PCA. (Id. at 155, §3, ¶¶1-2.) Every CA in the
`
`hierarchy receives a configuration file that includes its DN, position in the tree, and the PCA
`
`certificate and address, as well as the DNs and addresses of the authorities it certifies and
`
`that are certified by it. (Id. at 155, §3.1, ¶¶1-2.) Figure 2 shows a certification example
`
`where the PCA is the parent CA. The CA generates a pair of public and private keys, and a
`
`ATI-2590540v2
`
`17
`
`

`

`
`
`“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.” (Id. at
`
`155-56, §3.2, ¶2.)
`
`
`
`“The parent CA verifies
`
`the integrity of the request, and
`
`the signature of the self-signed
`
`certificate contained in the request. 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 all the certificates to the top of the
`
`certification hierarchy, and sends it back to the requester.” (Id. at 156, §3.2, ¶3.) The CA
`
`verifies the signatures of the certificates from the reply message, from the PCA down to its
`
`own, and stores them locally. (Id. at 156, §3.2, ¶4.) “Users are certified by their UCAs in
`
`the same way as CAs are certified by their parent CAs. After the establishment phase is
`
`completed all certified users have their signed certificates and copies of all the certificates in
`
`their certificate verification path up to the top of the hierarchy.” (Id. at 156, §3.2, ¶5.)
`
`
`
`Kapidzic describes several variations for certificate retrieval by requesting the
`
`certificate from the UCA, the owner of the certificate, or the PCA. (Id. at 156-57, §§4, 4.1,
`
`ATI-2590540v2
`
`18
`
`

`

`
`
`4.2; Figs. 3-5.) Certificate retrieval involves two messages – Certificate Request and
`
`Certificate Reply. (Id.) The format of the Certificate Reply and the verification procedure is
`
`the same as for the Certificate Signature Reply discussed above. (Id. at 156, §4.1, ¶4.)
`
`When a user has the certificate of a second user but not the second user’s address or the
`
`full verification path, the user cannot send the Certificate Request directly to the UCA or
`
`owner (as in Figs. 3 and 4), so the user sends a Resolve Certificate Request to the PCA.
`
`(Id. at 157, §4.2 and Fig. 5.)
`
`
`
`The Kapidzic CMS also provides for updating and revoking certificates. (Id. at 157-
`
`59, §§5-6.) For example, “when a certificate is updated, the old certificate must be
`
`revoked.” (Id. at 155, §2.2, ¶2.) Any time a CA changes a key (expiration, key is
`
`comprised, etc.), it affects the entire certification hierarchy. (Id. at 157, §5, ¶¶1-2.) Thus,
`
`all certificates must be re-signed and redistributed to CAs and other users. (Id.)
`
`
`
`The
`
`certificate update
`
`process is shown in Figure 6.
`
`When a new key pair
`
`is
`
`generated
`
`by
`
`a CA,
`
`the
`
`procedure is the same as the
`
`original certification discussed
`
`above. (Id. at 157-58, §5, ¶4.)
`
`Once it has the new certificate,
`
`ATI-2590540v2
`
`19
`
`

`

`
`
`the CA re-signs all the certificates of its subordinates and sends a re-sign message to each
`
`subordinate in the same format as the Certificate Signature Reply message, which the
`
`receiver processes as discussed above. (Id. at 158, §5, ¶¶5-6.) The receiver als