Trials@uspto.gov
`Tel: 571-272-7822
`
`Paper 58
`Entered: October 19, 2015
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`INTERNATIONAL BUSINESS MACHINES CORPORATION,
`Petitioner,
`
`v.
`
`INTELLECTUAL VENTURES II LLC,
`Patent Owner.
`
`Case IPR2014-006601
`Patent 5,745,574
`
`
`
`
`
`
`
`
`
`Before KRISTEN L. DROESCH, JENNIFER S. BISK, and
`JUSTIN BUSCH, Administrative Patent Judges.
`
`BUSCH, Administrative Patent Judge.
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`
`
`1 Case IPR2014-01410 has been consolidated with the instant proceeding.
`
`
`Tel: 571-272-7822
`
`Paper 58
`Entered: October 19, 2015
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`INTERNATIONAL BUSINESS MACHINES CORPORATION,
`Petitioner,
`
`v.
`
`INTELLECTUAL VENTURES II LLC,
`Patent Owner.
`
`Case IPR2014-006601
`Patent 5,745,574
`
`
`
`
`
`
`
`
`
`Before KRISTEN L. DROESCH, JENNIFER S. BISK, and
`JUSTIN BUSCH, Administrative Patent Judges.
`
`BUSCH, Administrative Patent Judge.
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`
`
`1 Case IPR2014-01410 has been consolidated with the instant proceeding.
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`I. INTRODUCTION
`
`A. Background
`International Business Machines Corporation (“Petitioner”) filed a
`second corrected Petition requesting an inter partes review of claims 18–31
`(the “challenged claims”) of U.S. Patent No. 5,745,574 (Ex. 1004,2 “the ’574
`patent”) under 35 U.S.C. §§ 311–319. Paper 13 (“Petition” or “Pet.”).
`Petitioner also filed another Petition requesting an inter partes review of
`claim 30 of the ’574 patent. IPR2014-01410, Paper 2 (“1410 Pet.”). On
`October 20, 2014, we instituted an inter partes review in IPR2014-00660.
`Paper 19 (“Decision” or “Dec. on Inst.”). On December 18, 2014, we
`instituted an inter partes review in IPR2014-01410 and consolidated that
`trial with the instant trial. IPR2014-01410, Paper 8 (“1410 Dec. on Inst.”).
`Intellectual Ventures II LLC (“Patent Owner”) filed a Patent Owner
`Response. Paper 29 (“Response” or “PO Resp.”). Petitioner filed a Reply.
`Paper 37 (“Reply”). An oral hearing was held on June 11, 2015.3
`We have jurisdiction under 35 U.S.C. § 6(c), and this Final Written
`Decision is issued pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73.
`For the reasons that follow, we determine Petitioner has shown by a
`preponderance of the evidence that claims 18–31 are unpatentable.
`B. Related Proceedings
`Petitioner indicates the ’574 patent is at issue in several district court
`proceedings involving numerous parties, none of which name Petitioner as a
`defendant. Pet. 2; Paper 16, 2–3. Petitioner also indicates that the ’574
`patent is the subject of co-pending inter partes review Case IPR2014-00724.
`
`2 All Papers and Exhibits referenced in this final written decision refer to
`papers filed in the record for IPR2014-00660, unless otherwise noted.
`3 The record includes a transcript of the oral hearing. Paper 57 (“Tr.”).
`
`2
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`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, sometimes referred to as a “secret key”) 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
`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.
`
`3
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`The challenged claims recite various processes used within a PKI
`system to request, issue, and update public key certificates, add nodes or
`entities to the 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. 1004, 8:17–29. As can be seen in Figure 4, a hierarchy includes
`certification authorities (CAs) CA1–CA4 and users U1 and U2. Id. at Fig. 4.
`Not depicted in Figure 4, at a level above CA1, is a policy certifying
`authority (PCA), “which defines a particular set of certification policies
`[and] set[s] 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 subordinate CAs “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
`
`4
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`procedure in order to participate in the PKI and obtain certificates, so that
`CAs may certify other nodes, and 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. 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
`
`5
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`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
`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 also
`may 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 node to the highest level
`node (e.g., a PCA or a Policy Registration Authority (PRA), which is above
`a PCA in the PKI hierarchy), such that in the example depicted in Figure 4,
`U2 may store a certificate for itself and a certificate for each of CA1, CA2,
`and CA3. Id. at 12:2–6. 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
`(e.g., U2, CA2, and CA3), U1 extracts, verifies, and stores the certificate. Ex.
`
`6
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`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 (or, alternatively, to a common repository) for
`the CRL 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 each are directed to
`methods for implementing various portions of the 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.
`
`7
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`In a global network with secure communications
`23.
`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:
`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
`
`8
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`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,
`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.
`E. The Evidence of Record
`Petitioner relies upon the following references as its basis for
`challenging claims 18–31 of the ’574 patent.4
`Reference
`Printed Publications
`Nada Kapidzic & Alan Davidson, A
`Kapidzic
`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
`
`4 Petitioner also proffers the declarations of Dr. Matthew Blaze. See Ex.
`1001; IPR2014-01410, Ex. 1001.
`
`Exhibit[s]
`1006, 1007
`(“Kapidzic”)
`
`PKI Report
`
`1008
`(“PKI Report”)
`
`9
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`Reference
`
`RFC 1422
`
`RFC 1424
`
`Exhibit[s]
`
`1009, 1010, 1011
`(“RFC 1422”)
`
`1012, 1013
`(“RFC 1424”)
`
`Printed Publications
`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)
`(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)
`
`F. The Asserted Grounds of Unpatentability
`The Board instituted inter partes review on the following asserted
`grounds of unpatentability under 35 U.S.C. §§ 102, 103 (Dec. on Inst. 29;
`1410 Dec. on Inst. 13):
`Challenged Claim[s]
`Statutory Ground Reference[s]
`18–31
`§ 102(a)
`Kapidzic
`23–25, 27, 28
`§ 102(b)
`PKI Report
`18–22, 26, 29–31
`§ 103
`PKI Report
`18
`§ 102(b)
`RFC 1424
`23–29
`§ 102(b)
`RFC 1422
`§ 103
`RFC 1422 and RFC 1424 19–22, 31
`
`II. 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.100(b). Applying that standard, we interpret the claim terms of the
`
`10
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`’574 patent according to their ordinary and customary meaning in the
`context of the written description. See In re Translogic Tech., Inc., 504 F.3d
`1249, 1257 (Fed. Cir. 2007) (quoting Phillips v. AWH Corp., 415 F.3d 1303,
`1312 (Fed. Cir. 2005) (en banc)). Patent Owner submits proposed claim
`constructions for three terms or phrases—process, common certificate
`repository, and verified by a direct inquiry to the certification authority. PO
`Resp. 11–15. Petitioner argues the plain and ordinary meaning should be
`attributed to each term. Reply 8–12.
`“computer process”
`Patent Owner argues that “the broadest reasonable interpretation of
`‘process’ . . . include[s] ‘computer program instructions running on a
`computer.’”5 PO Resp. 11. Patent Owner alleges that its proposed
`construction is consistent with the specification of the ’574 patent because
`the description of Figure 1A explains that each block in the flow chart “is
`implemented as a computer process running on a computer.” Id.
`Petitioner argues Patent Owner’s proposed construction is unlimited
`and indefinite because it provides no clear bounds and merely states that it
`would “include computer program instructions running on a computer.”
`Reply 8–9 (emphasis added) (internal citations omitted). Petitioner asserts
`that Patent Owner’s proposed construction does not clarify the claim
`language and, in fact, introduces ambiguity.
`
`5 The heading for the portion of the Response directed to Patent Owner’s
`arguments addressing the construction of process is similar to, but
`inconsistent with, arguments made in that section. Specifically, Patent
`Owner’s heading is: “The proper interpretation of ‘process’ is ‘a computer
`program loaded into memory and executing in a processor.’” The reasons
`discussed herein for declining to adopt Patent Owner’s proposed
`construction apply equally to the construction identified in the heading.
`
`11
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`Petitioner also submits that Patent Owner implicitly excludes human
`intervention from its proposed construction. Reply 9. Petitioner argues that
`manual intervention is not excluded from the challenged claims, which recite
`methods “comprising” steps performed at a computer process. Id. at 12–13.
`In support of its arguments, Petitioner points to the ’574 patent’s disclosure
`that “[t]he appropriate process can be invoked manually by commands as
`well.” Id. at 13 (quoting Ex. 1004, 17:59–67) (emphasis omitted).
`Petitioner further argues Patent Owner’s declarant, Dr. Frederic T. Chong ,
`admitted that the ’574 patent contemplates manually invoking a process. Id.
`(citing Ex. 1030, 94:17–25). Thus, Petitioner argues that the recitation of
`computer processes does not exclude all manual intervention, and that the
`plain and ordinary meaning is clear from the specification. Id.
`We agree with Petitioner that Patent Owner’s proposed construction
`adds no clarity to the meaning of the term “process.” We further agree that
`“process,” or more specifically, “computer process,” as recited in each of the
`challenged claims, should be given its plain and ordinary meaning. To the
`extent that there might have been ambiguity as to the plain and ordinary
`meaning, the references in the’574 patent to computer processes support the
`idea that a skilled artisan would have understood what was meant by the
`recitation of the term. In particular, the’574 patent discloses that “[e]ach
`user or certification authority of the infrastructure has access to a computer
`process which comprises appropriate certification software and storage areas
`for storing data structures.” Ex. 1004, 5:55–57. The’574 patent explains
`that the invention is directed to a certification system, which:
`includes computer processes
`implementing certification
`servers, certification clients and certification protocols, in
`which one or more first computer processes are associated with
`
`12
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`at least one initial (root) registration authority, one or more
`second computer processes are associated with policy
`certification authorities, one or more third computer processes
`are associated with certification authorities, and one or more
`end-user computer processes or application computer processes
`are associated with respective end-users or user applications.
`Id. at 6:1–13 (emphasis added); see id. at 1:64–66. The’574 patent further
`explains that the processes are arranged in a hierarchy, that each of these
`processes may hold certified data structures (i.e., certificates), and that
`“users and applications of said system are logically located at end-points of
`certification chains in a certification infrastructure.” Id. at 6:14–22.
`The computer processes use “a common application programming
`interface [API] for access to encryption and certification services,” and the
`API “is a set of certification functions which can be invoked by commands
`or by messages, such as an http command, an email message or program to
`program communication.” Ex. 1004, 5:62–67. Figures 7 through 27 of the
`’574 patent “describe a set of processes which collectively form the
`certification system, functions, and certification infrastructure of this
`invention.” Id. at 13:53–55. “The commands and processes described in
`FIGS 7-2[7] thus present a set of protocol and programming primitives
`which may be invoked either directly by a user or by part of an application
`process running on the user’s or CA’s computer.” Id. at 13:57–61. The’574
`patent further explains that a certification server process continuously
`monitors incoming messages and commands, which may be invoked
`manually, and determines which of the certification functions described in
`Figures 7 through 27 should be called. Id.at 17:55–67.
`Moreover, as discussed above, the’574 patent refers to entities
`(including PCA, CAs, and users) as being associated with computer
`
`13
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`processes. See, e.g., Ex. 1004, 1:64–66. Throughout the specification and,
`in particular in the description of the specific messages and “processes
`which collectively form the certification system” (see id. at 13:53–17:54),
`the ’574 patent refers to entities as sending and receiving messages and
`executing processes. The ’574 patent refers to these processes and entities
`interchangeably. Id.
`Thus, an ordinarily skilled artisan would have understood that the
`recited computer processes are instances of a computer program or programs
`running on the various computers, each of which may be associated with
`different nodes or entities (e.g., policy certification authorities, certification
`authorities, user applications) that carry out the tasks involved in the
`certification system described by the ’574 patent. Functions specifically
`recited as being performed at or by a computer process obviously exclude
`performance of that function that does not involve a computer process.
`Beyond steps explicitly recited as performed at or by a computer process,
`however, we find nothing in the recitations of a computer process that would
`exclude manual invocation or other manual intervention.
`“common certificate repository”
`Patent Owner argues that the broadest reasonable interpretation of
`“common certificate repository” is “a repository that stores public key
`certificates for all certification authorities [in the certification
`infrastructure].” PO Resp. 12. Patent Owner asserts that the ’574 patent,
`which states that a “common certificate repository may contain public key
`certificates for all certification authorities in the hierarchy,” requires a
`construction that a common certificate repository keeps a certificate for each
`
`14
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`and every certification authority in the infrastructure. Id. (quoting Ex. 1004,
`5:51–52).
`Petitioner points to the fact that the ’574 patent discloses that the
`common certificate repository may include public key certificates for all
`CAs and/or CRLs for multiple users or processes in the hierarchy. Reply 10.
`Thus, Petitioner argues that the ’574 patent uses the permissive “may” and
`alternative “or,” indicating that a common certificate repository may store,
`some, all, or none of the certificates in the hierarchy or infrastructure. Id.
`Because we use the broadest reasonable interpretation for construing
`claims, we decline to limit the construction of common certificate repository
`to require storage of public key certificates for all CAs, or even all CAs
`within a hierarchy or infrastructure. Other than declining to adopt Patent
`Owner’s proposed narrowing of the plain and ordinary meaning of a
`common certificate repository, we do not find it necessary to provide an
`explicit construction of the term.
`Whether recitation of a method step introduced by “may” further limits a
`claim
`Before we address the parties’ arguments regarding the construction
`of “verified by a direct inquiry to the certification authority,” recited in claim
`25, we must first address the use of “may” to introduce limitations in claims
`25–27. “[O]ptional elements do not narrow the claim because they can
`always be omitted.” In re Johnston, 435 F.3d 1381, 1384 (Fed. Cir. 2006).
`Claims that use the term “may” to introduce a limitation are permissive and,
`thus, do not narrow the scope of the claim. Id. Thus, the use of the term
`“may” or “may also” in claims 25–27 is not limiting. Specifically, claims
`25–27, which recite “[t]he method of verifying of claim 23 in which a public
`
`15
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`key certificate . . . may” be obtained or verified by various steps, do not
`further limit claim 23, from which they depend.
`We are not persuaded by Patent Owner’s argument that claim 25,
`which recites that the method of claim 23 “may also be verified by a direct
`inquiry,” “provides an alternative” approach to the iterative approach recited
`in claim 23. PO Resp. 14; see Johnston, 435 F.3d at 1385. Therefore, for
`purposes of this inter partes review, we construe claims 25–27 to be of the
`same scope as, and stand or fall with, independent claim 23.
`With respect to claim 22, which recites in part that “the new
`certificate may contain either the existing or a new public key,” the parties
`appear to agree that the recited language requires the certificate to have
`either the existing public key or a new public key. However, we find that
`the permissive language in claim 22 also fails to further limit the claim. The
`claim could have recited that the certificate contains (as opposed to may
`contain) either the existing or a new public key. Therefore, we find the
`scope of claim 22 to be the same as if the claim recited: “The method of
`claim 18, performed upon expiration of an existing certificate.”
`“verified by a direct inquiry to the certification authority”
`The parties dispute the proper construction of this phrase. However,
`we need not reach this issue because the disputed phrase is recited only in
`claim 25 as part of a non-limiting clause. As discussed above, we construe
`claims 25–27 to be of the same scope as claim 23.
`B. The Asserted Grounds
`1. Anticipation of Claims 18–31 by Kapidzic
`Petitioner asserts claims 18–31 are unpatentable as anticipated by
`Kapidzic, and provides a chart showing where Kapidzic allegedly discloses
`
`16
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`each limitation. Pet. 8–25; 1410 Pet. 6–28. As explained below, we
`conclude that Petitioner has met its burden to show, by a preponderance of
`the evidence, as required by 35 U.S.C. § 316(e), that claims 18–31 are
`unpatentable as anticipated by Kapidzic.
`a. Kapidzic (Ex. 1007)
`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. 1006, 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.
`Figure 1 of Kapidzic is reproduced below:
`
`
`Figure 1 depicts a logical representation of a hierarchy within a public key
`infrastructure of the CMS disclosed by Kapidzic. Ex. 1006, 6.
`
`17
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`b. Whether Kapidzic Is Prior Art
`Patent Owner argues that Kapidzic is not prior art under § 102(a)
`because “to the extent that Kapidzic discloses any of the concepts of claims
`18–31 of the ’574 patent, these concepts were derived from Dr. Sead Muftic,
`the sole inventor of those concepts.” PO Resp. 18 (citing Ex. 2005 ¶ 13).
`Specifically, Patent Owner asserts that “Dr. Muftic conceived of the
`concepts claimed in the ’574 patent,” and “[t]he concepts described in
`Kapidzic also originated from Dr. Muftic.” Id. at 19. Patent Owner
`acknowledges that testimony of the inventor of the ’574 patent is not, by
`itself, enough to show conception, and that Patent Owner must provide
`sufficient corroborative evidence that all of the ideas in Kapidzic are
`attributable to Dr. Muftic. See Tr. 28:11–29:12, 34:20–24, 37:16–38:5.
`Patent Owner further acknowledges that, in order to be disqualified as a
`prior art reference under § 102(a), Kapidzic needs to be only Dr. Muftic’s
`work. Id. at 41:5–19.
`Dr. Muftic testifies that: (1) he conceived of all the concepts described
`in Kapidzic; (2) Dr. Nada Kapidzic was his Ph.D. student from about 1992
`to 1997; (3) Mr. Alan Davidson was his Licentiate student from about 1992
`to 1995; (4) he explained the details of the concepts in Kapidzic to Dr.
`Kapidzic, who wrote about them under Dr. Muftic’s direction and
`supervision; (5) Mr. Davidson wrote a computer program prototype
`implementing the concepts of the system described in Kapidzic, and Mr.
`Davidson assisted Dr. Kapidzic in writing Kapidzic; (6) he omitted his name
`from Kapidzic to allow Dr. Kapidzic and Mr. Davidson to receive
`publication credit to help build their academic careers; (7) he has had a
`similar practice in other situations to aid students in building their academic
`
`18
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`careers and attend conferences; (8) he had already co-authored two papers
`(Exs. 2002, 2004, collectively “the two co-authored articles”) in the same
`area and multiple articles in the field of computer security and “did not deem
`it important to list [him]self as an author on the Kapidzic article”; and (9) the
`contributions in Kapidzic are his contributions, not Dr. Kapidzic’s or Mr.
`Davidson’s. Ex. 2005 ¶¶ 13–16, 19–22, 25–33. Patent Owner submits that
`Dr. Muftic’s testimony is supported by circumstantial evidence, namely: (1)
`the co-authors of Kapidzic (i.e., Nada Kapidzic and Alan Davidson) were
`Dr. Muftic’s graduate students; (2) Dr. Muftic is listed as co-author, with Dr.
`Kapidzic, on a paper published around the same time as Kapidzic and
`relating to the same area (Ex. 2002); and (3) Dr. Muftic is listed as co-
`author, with Dr. Kapidzic and Mr. Davidson, on another paper published
`around the same time and relating to the same area (Ex. 2004). PO Resp.
`19–21; Tr., 29:8–23, 30:18–31:2, 39:17–40:2.
`At oral argument, Patent Owner pointed, for the first time, to
`additional evidence that it argues corroborates Dr. Muftic’s testimony.
`Specifically, at oral argument Patent Owner pointed to: (1) a portion of Dr.
`Kapidzic’s doctoral thesis (Ex. 2006), which thanks Dr. Muftic for his
`“supervision and constant generation of new ideas” (Ex. 2006, page H); and
`(2) Dr. Chong’s testimony that events similar to those Dr. Muftic described
`regarding the history of Kapidzic “are commonplace in the academic
`community” (Ex. 2007 ¶ 31). Tr. 29:24–30:12, 33:1–14, 40:3–12. Patent
`Owner asserts that the two co-authored articles corroborate the fact that Dr.
`Kapidzic and Mr. Davidson were Dr. Muftic’s graduate students (Tr. 36:14–
`24), and that Patent Owner only needs to provide sufficient circumstantial
`
`19
`
`
`
`IPR2014-00660
`Patent 5,745,574
`
`evidence to corroborate
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
