throbber
Trials@uspto.gov
`Tel: 571-272-7822
`
`Paper 41
`Entered: November 5, 2015
`
`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.
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`A. Background
`
`I. INTRODUCTION
`
`Compass Bank, Commerce Bancshares, Inc., and First National Bank
`
`of Omaha (collectively, “Petitioner”) filed a petition requesting an inter
`
`partes review of claims 18–31 (the “challenged claims”) of U.S. Patent No.
`
`5,745,574 (Ex. 1002, “the ’574 patent”) under 35 U.S.C. §§ 311–319. Paper
`
`1 (“Petition” or “Pet.”). On November 6, 2014, we instituted an inter partes
`
`review of the challenged claims. Paper 12 (“Decision” or “Dec. on Inst.”).
`
`Intellectual Ventures II LLC (“Patent Owner”) filed a Patent Owner
`
`Response. Paper 19 (“PO Resp.”). Petitioner filed a Reply. Paper 29
`
`(“Reply”). An oral hearing was held on June 11, 2015.1
`
`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. Pet. 1–2; Paper 11, 2–4. The ’574
`
`patent also was the subject of inter partes review Case IPR2014-00660. 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.
`
`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
`
`
`1 The record includes a transcript of the oral hearing. Paper 40 (“Tr.”).
`
`2
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`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. 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.
`
`3
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`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 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. 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 users may send communications that can
`
`4
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`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
`
`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:54–63. If the
`
`5
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`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 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.
`
`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
`
`6
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`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 (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:
`
`In a certification system for secure communications
`18.
`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-00724
`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.
`
`In a certification system for secure communications
`28.
`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.
`
`In a computer system for secure communications
`30.
`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-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.
`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. 1002, 19:4761, 20:816, 20:3242, 20:4667, 21:114.
`
`E. The Evidence of Record
`
`Petitioner relies upon the following references as its basis for
`
`challenging claims 18–31 of the ’574 patent.2
`
`Reference Printed Publication
`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)
`PKI Report Shimshon Berkovits et al., Public Key
`Infrastructure Study: Final Report, MITRE
`Report on NIST Request for Study on
`Policy and Legal Issues Related to the
`Operation and Management of the PKI
`(April 1, 1994)
`
`Exhibit
`1004
`(“Kapidzic”)
`
`1005
`(“PKI Report”)
`
`
`2 Petitioner also proffers Dr. David Naccache’s Declaration. Ex. 1001.
`
`9
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`Reference Printed Publication
`RFC 1424 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)
`
`Exhibit
`1006
`(“RFC 1424”)
`
`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. 28):
`
`Statutory Ground Reference[s]
`§ 102(a)
`Kapidzic
`§ 102(b)
`PKI Report
`§ 103
`PKI Report
`§ 103
`PKI Report and RFC 1424
`
`Challenged Claims
`18–31
`23–31
`25, 29, and 30
`18–22
`
`A. Claim Construction
`
`II. ANALYSIS
`
`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); In re Cuozzo Speed Techs., LLC, 793 F.3d 1268, 1275–79 (Fed.
`
`Cir. 2015). Applying that standard, we interpret the claim terms of the ’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. 9–13.
`
`10
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`“computer process”
`
`Patent Owner argues that “the broadest reasonable interpretation of
`
`‘process’ . . . include[s] ‘computer program instructions running on a
`
`computer.’”3 PO Resp. 9. 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 that, even to the extent Patent Owner’s proposed
`
`construction is accepted, all of the steps recited in the challenged claims are
`
`still performed at a computer process. Reply 3–4. As one example,
`
`Petitioner points out that the verifying, certifying, and returning steps recited
`
`in claim 18 “clearly take place at a computer running computer instructions
`
`because the emails Kapidzic describes require computers running
`
`instructions.” Id. at 4. Petitioner further asserts that the inventor of the ’574
`
`patent even “admits Kapidzic teaches claim 18’s elements.” Id. (citing Ex.
`
`2017, 42:25–43:14, 48:20–25, 50:18–22, 51:21–53:5). Petitioner argues that
`
`Patent Owner’s argument depends on whether the broadest reasonable
`
`interpretation of the claims excludes all human or manual interaction with
`
`computers or software, which Petitioner asserts is unsupported by the claims
`
`and specification of the ’574 patent. Id. at 4.
`
`
`3 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-00724
`Patent 5,745,574
`
`In particular, Petitioner argues that “certification functions . . . can be
`
`invoked by commands or by messages, such as an http command, an email
`
`message or program to program communication.” Reply 4 (quoting Ex.
`
`1002, 5:65–67). Petitioner further argues the description of Figures 7
`
`through 27 states that the commands and processes described as collectively
`
`forming the certification system, functions and infrastructure of the
`
`invention “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 4–5
`
`(quoting Ex. 1002, 13:53–61). Petitioner also points to the portion of the
`
`’574 patent that discloses “[t]he appropriate process can be invoked
`
`manually by commands as well.” Id. at 5 (quoting Ex. 1002, 17:66–67).
`
`Petitioner also argues that Patent Owner’s “application of its ‘process’
`
`argument is based on faulty assumptions by its” declarant, Dr. Frederic T.
`
`Chong. Reply 5 (citing PO Resp. 20–23). In particular, Petitioner asserts
`
`Dr. Chong’s statement that “certification in Kapidzic ‘normally require[s]
`
`manual intervention’” (Ex. 2012 ¶ 36) is inaccurate because Kapidzic states
`
`that verifying the identity of a requester, not the entire certification process,
`
`normally requires manual intervention. Reply 5–6 (citing Ex. 1004, 13).
`
`Petitioner further argues that Dr. Chong assumed Kapidzic processed emails
`
`manually, but that he was unaware of whether the emails could have been
`
`automatically processed in December 1995. Id. (citing Ex. 1010, 44:9–21,
`
`46:24–47:3).
`
`We find 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
`
`12
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`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.
`
`1002, 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
`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. 1002, 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
`
`13
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`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
`
`processes. See, e.g., Ex. 1002, 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. See Reply 5 (citing Ex. 1002, 11:30–65, 13:64–16:50).
`
`The ’574 patent refers to these processes and entities interchangeably. Ex.
`
`1002, 13:53–17:54.
`
`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,
`
`14
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`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. 10 (citing Ex. 2012 ¶¶ 17–19). 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 and every certification authority in the
`
`infrastructure. Id.
`
`Petitioner argues that the ’574 patent discloses that the common
`
`certificate repository may include public key certificates for all CAs in the
`
`hierarchy, and that, because “may” is permissive, the proper construction is
`
`not limited as proposed by Patent Owner. Reply 7. Petitioner also asserts
`
`that the inventor of the ’574 patent admitted that the X.500 directory,
`
`disclosed in Kapidzic and relied upon in Petitioner’s challenges, is one
`
`example of a common certificate repository. Id. (citing Ex. 2017, 54:20–
`
`55:13).
`
`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
`
`15
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`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
`
`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. 12; 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
`
`16
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`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
`
`each limitation. Pet. 15–34. 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–21 and 23–31 are
`
`unpatentable as anticipated by Kapidzic. Petitioner, however, has not met its
`
`burden to show, by a preponderance of the evidence, that claim 22 is
`
`unpatentable as anticipated by Kapidzic.
`
`a. Kapidzic (Ex. 1004)
`
`Kapidzic is one paper in a collection of papers, which were the subject
`
`of a symposium on network and distributed system security. Ex. 1004, 1–4,
`
`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. at
`
`10.
`
`17
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`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. 1004, 11.
`
`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. 16 (citing Ex. 2010 ¶ 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 18.
`
`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
`
`18
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`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
`
`careers and attend conferences; (8) he had already co-authored two papers
`
`(Exs. 2007, 2009, 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 himself as an author on the Kapidzic article”; and (9) the
`
`contributions in Kapidzic are his contributions, not Dr. Kapidzic’s or
`
`Mr. Davidson’s. PO Resp. 18–20; Ex. 2010 ¶¶ 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. 2007); 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. 2009).
`
`PO Resp. 18–19; IPR2014-00660, Paper 57 (“’660 Tr.”), 29:8–23, 30:18–
`
`31:2, 39:17–40:2.
`
`Patent Owner argues an inventor need not be listed as an author on a
`
`reference in order to disqualify that reference as prior art. PO Resp. 17
`
`(citing Pictometry Int’l Corp. v. Geospan Corp., No. 2011-010700, 2011
`
`WL 4857918 (BPAI Oct. 7, 2011)). Patent Owner also asserts that a
`
`declaration from an inventor is sufficient to remove a reference as prior art
`
`19
`
`

`
`IPR2014-00724
`Patent 5,745,574
`
`and that declarations from co-authors supporting an inventor’s testimony are
`
`not required. Id. at 16–17 (citing In re Katz, 687 F.2d 450, 454–55 (CCPA
`
`1982)). At oral hearing for IPR2014-00660, which involves the

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket