Paper No. 21
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`________________
`
`VISA INC. and VISA U.S.A. INC.
`APPLE INC.,
`
`Petitioners,
`
`v.
`
`UNIVERSAL SECURE REGISTRY LLC,
`
`Patent Owner
`
`________________
`
`Case IPR2018-013501
`
`U.S. Patent No. 8,856,539
`
`________________
`
`PATENT OWNER’S SUR-REPLY
`
`
`
`
`1 Apple Inc., which filed a petition in IPR2019-00727, has been joined as a party
`to this proceeding.
`
`
`
`

`

`TABLE OF CONTENTS
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`Page
`
`I.
`
`II.
`
`V.
`
`CLAIM CONSTRUCTION ............................................................................ 1
`A.
`“based at least in part on the indication of the provider and the
`time-varying multicharacter code of the transaction request” .............. 1
`“provider requesting the transaction” .................................................... 2
`B.
`BRENER FAILS TO DISCLOSE LIMITATION 1.6 .................................... 2
`A.
`Petitioner Continues to Advance a Flawed Argument for
`Brener’s Shipping Carrier That the Board Previously, and
`Correctly, Rejected ................................................................................ 2
`Brener’s Bank Computer 150 Cannot Be the Claimed Third
`Party Because it Does Not Receive Account Identifying
`Information ............................................................................................ 5
`III. A POSITA WOULD NOT BE MOTIVATED TO COMBINE
`BRENER AND WEISS TO ACHIEVE THE RECITED TIME-
`VARYING CODE ........................................................................................... 9
`A.
`Patent Owner Debunked the Petition’s Lone Example of How
`Brener and Weiss Would Be Combined ............................................... 9
`Brener’s PKAC is a Digital Certificate ............................................... 11
`Petitioner’s New Argument That Weiss’ Time-Varying Value
`Can Be Appended to Brener’s PKAC Should Be Disregarded ........... 14
`Petitioner’s New Argument Appending Weiss’s Time-Varying
`Value to Brener’s PKAC is Meritless ................................................. 16
`IV. PETITIONER FAILS TO SHOW THAT BRENER AND DESAI
`DISCLOSE THE CLAIMED ACCESS RESTRICTIONS........................... 20
`A.
`Petitioner’s Proffered Reason for Combining Brener and Desai
`Fail Because a POSITA Would Not Make the Combination to
`Achieve the Claimed Invention ........................................................... 20
`Petitioner Has Not Presented a Viable Explanation for How
`Brener and Desai Would Work Together ............................................ 22
`PETITIONER CONFLATES BRENER’S DISCUSSION OF
`DIGITAL SIGNATURES WITH ENCRYPTION TO SAVE ITS
`FAILED UNPATENTABILITY ARGUMENT FOR CLAIMS 3/24 .......... 25
`
`B.
`
`B.
`C.
`
`D.
`
`B.
`
`
`
`i
`
`

`

`VI. CONCLUSION .............................................................................................. 25
`
`
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`ii
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`TABLE OF AUTHORITIES
`
`CASES
`
`Page
`
`Apple v. Uniloc Luxembourg S.A.,
`IPR2018-00420, Paper 7 ................................................................................11
`
`DyStar Textilfarben v. C.H. Patrick Co.,
`464 F.3d 1356 (Fed. Cir. 2006) .....................................................................21
`
`In re Magnum Oil Tools Int’l, Ltd.,
`829 F.3d 1364 (Fed. Cir. 2016) .....................................................................11
`
`Personal Web Techs., LLC v. Apple, Inc.,
`848 F.3d 987 (Fed. Cir. 2017) ............................................................ 9, 11, 22
`
`PTAB Trial Practice Guide August 2018 Update at 14 ................................... 14, 16
`
`OTHER AUTHORITIES
`
`
`
`
`
`iii
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`Ex. 2001
`
`Ex. 2002
`Ex. 2003
`Ex. 2004
`
`Ex. 2005
`
`Ex. 2006
`
`Ex. 2007
`
`Ex. 2008
`Ex. 2009
`Ex. 2010
`
`Ex. 2011
`
`Ex. 2012
`
`PATENT OWNER’S LIST OF EXHIBITS
`
`Declaration of Dr. Markus Jakobsson in Support of
`Patent Owner’s Preliminary Response.
`Curriculum Vitae of Dr. Markus Jakobsson.
`Terminal Disclaimer Dated August 17, 2018.
`Declaration of Dr. Markus Jakobsson in Support of
`Patent Owner’s Response.
`Transcript of Dr. J. Douglas Tygar Deposition Dated
`April 19, 2019.
`N. Asokan, et. al, The State of the Art in Electronic
`Payment Systems, IEEE Computer, Vol. 30, No. 9, pp.
`28-35 (IEEE Computer Society Press, Sept. 1997).
`M. Baddeley, Using E-Cash in the New Economy: An
`Economic Analysis of Micropayment Systems, J.
`Electronic Commerce Research, Vol. 5, No. 4, pp. 239-
`253 (Nov. 2004).
`U.S. Application No. 11/768,729.
`U.S. Application No. 09/710,703.
`Declaration of Dr. Markus Jakobsson in Support of
`Motion to Amend.
`Declaration of Dr. Markus Jakobsson in Support of
`Patent Owner’s Reply to Opposition of Conditional
`Motion to Amend
`U.S. District Court for Delaware Report and
`Recommendation.
`
`iv
`
`
`
`
`
`
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`Universal Secure Registry LLC (“Patent Owner” or “PO”) submits this Sur-
`
`reply in response to Petitioner’s Reply to Patent Owner Response, Paper 16
`
`(“Reply”). The challenged claims are not unpatentable in view of the prior art
`
`because, among other things: Brener’s alleged third party bank does not receive
`
`account identifying information from a secure registry; Petitioner’s original proposal
`
`to make Brener’s private key authorization code time-varying would render Brener
`
`inoperable; Petitioner’s new argument to append a time-varying value to Brener’s
`
`private key authorization code is also meritless; and Petitioner’s proposed
`
`combination of Brener and Desai would not have a reasonable likelihood of success.
`
`I.
`
`CLAIM CONSTRUCTION
`
`A.
`
`“based at least in part on the indication of the provider and the
`time-varying multicharacter code of the transaction request”
`
`As the Board already found in its institution decision, the “based at least in
`
`part on” phrase should be construed to modify “determining compliance with any
`
`access restrictions for the provider to secure data of the entity.” POR at 13-16; ID
`
`(Paper 7) at 8-9. Petitioner’s arguments to the contrary are unpersuasive, effectively
`
`arguing that a recited feature can be read out of a claim (or otherwise misconstrued)
`
`if the specification describes an embodiment that does not require that feature. See
`
`Reply at 3. Unsurprisingly, Petitioner cites no legal precedent for this defective
`
`argument.
`
`
`
`1
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`B.
`
`“provider requesting the transaction”
`
`As previously explained, the phrase “provider requesting the transaction”
`
`should be construed as “the provider that sent the transaction request.” POR at 18-
`
`21. Moreover, contrary to Petitioner’s assertions, even if the Board were to reject
`
`PO’s proposed construction of this phrase, PO’s arguments concerning limitation
`
`1.6 do not hinge on PO’s construction, and so would be unaffected. See infra
`
`Section II.B.
`
`II. BRENER FAILS TO DISCLOSE LIMITATION 1.6
`
`A.
`
`Petitioner Continues to Advance a Flawed Argument for Brener’s
`Shipping Carrier That the Board Previously, and Correctly,
`Rejected
`
`The Petitioner advances no justification for altering the Board’s previous
`
`rejection of Petitioner’s arguments concerning Brener’s “shipping carrier” for
`
`limitation 1.6. See Institution Decision (“ID”) (Paper 7) at 16-17. First, Petitioner
`
`erroneously alleges that PO effectively proffered a “narrow[] construction of the
`
`term ‘to enable transactions’ to mean approving only the financial aspect of the
`
`transaction.” Reply at 6-7. This is demonstrably false; PO never advanced a narrow
`
`construction for the phrase “to enable or deny the transaction” in an attempt to avoid
`
`application of Brener. See POR (Paper 12) at 12-21, 22-25. Indeed, a narrow
`
`interpretation of this phrase is unnecessary to avoid Brener, as Brener’s own
`
`
`
`2
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`disclosure provides the necessary distinction: Brener’s bank computer 150 has
`
`already determined whether to enable or deny the transaction before the shipping
`
`carrier receives the shipping information. Ex. 1005, Brener at 14:28-15:10. Notably,
`
`in the paragraphs immediately preceding the one Petitioner cites, Brener expressly
`
`states:
`
`The bank computer 150 then determines whether or not to
`
`authorize the transaction…Once the bank computer 150 has
`
`authorized the purchase [] the bank computer 150 returns the vendor
`
`number, the transaction identifier and/or the customer object or public
`
`key, and the approval of the transaction back to the vendor computer
`
`140…Upon approval of the transaction, the vendor readies the
`
`goods for anonymous shipment as explained below.”
`
`Id. at 13:25-26, 14:16-22. Thus, PO does not import a narrowing construction into
`
`limitation 1.6 to limit its scope to “only the financial aspect of the transaction” as
`
`Petitioner asserts. Instead, PO merely focuses on Brener’s unequivocal teaching that
`
`before the shipping carrier receives shipping information, a determination has
`
`already been made as to whether to enable or deny Brener’s transaction (which in
`
`this case happens to be a purchase transaction).2
`
`
`2 It does not matter that Brener’s transaction here is a purchase transaction. The
`analysis would be exactly the same even if Brener’s bank 150 were tasked with
`
`
`
`3
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`Furthermore, although the recited phrase is “to enable or deny the transaction
`
`with the provider,” Petitioner consistently focuses on only the enabling portion of
`
`the phrase to buttress its arguments. See Reply at 6-8 (consistently focusing on
`
`“enabling” and omitting “or deny” and “with the provider”). Petitioner advances this
`
`selective re-imagining of the claim because Brener does not disclose that the
`
`shipping carrier computer 180 may enable or deny a transaction, much less enable
`
`or deny the transaction with the vendor 140; that’s because the bank computer 150
`
`has already enabled the transaction with the vendor 140 before involvement of the
`
`shipping carrier computer 180. See Ex. 1005, Brener at 13:25-14:22 (“The bank
`
`computer 150 then determines whether or not to authorize the transaction.”).
`
`PO’s expert’s views, the ’539 patent specification, and dependent claim 25
`
`are all in agreement with this analysis. For example, dependent claim 25 specifies
`
`that the “transaction” includes a delivery service provided by the provider, and that
`
`the “account identifying information” sent to the third party is associated with an
`
`address to which an item is to be delivered. In this case, the third party receives this
`
`account identifying information to enable or deny the entity’s delivery transaction
`
`
`determining whether to enable or deny other transaction types (e.g., access to a
`secure facility, open a line of credit, etc.). What’s relevant is that, unlike the claims,
`a determination to enable or deny the transaction occurs before any purported third
`party receives the shipping information.
`
`
`
`4
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`with the provider. This is different from what Petitioner points to in Brener where
`
`the transaction with the provider is a purchase transaction with a vendor 140, and
`
`the bank computer has already enabled or denied that transaction prior to Brener’s
`
`shipping carrier 180 receiving the shipping information and shipping the goods
`
`bought during the purchase transaction.
`
`Accordingly,
`
`the Board should simply affirm
`
`its previous correct
`
`determination that “Brener’s shipping carrier cannot be the ‘third party’ because the
`
`carrier is not involved until a transaction is approved.” ID (Paper 7) at 16.
`
`B.
`
`Brener’s Bank Computer 150 Cannot Be the Claimed Third Party
`Because it Does Not Receive Account Identifying Information
`
`Brener fails to disclose limitation 1.6 (See POR at 22-25), and Petitioner
`
`wrongly asserts that PO’s explanation of Brener’s deficiency wholly “relies on its
`
`claim construction for ‘the provider requesting the transaction.’” Reply at 9-10.
`
`While PO did discuss the proper claim construction of “the provider requesting the
`
`transaction” to point out that in the cited portion of Brener (9:19-10:2) the vendor
`
`sends the customer object to the bank 150 (alleged third party) and not to the secure
`
`provider 110 (alleged secure registry), PO also emphasized that the cited portion of
`
`Brener fails to disclose limitation 1.6 because it is untrue that, in the claims, “account
`
`information may be provided to a third party financial institution or bank computer
`
`by the secure provider to complete the purchase transaction by approving or denying
`
`
`
`5
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`a transaction.” POR at 24 (citing Pet. at 40) (emphasis added in POR). All four
`
`independent claims make clear that after the secure registry maps the time-varying
`
`multicharacter code to the entity’s identity and accesses the entity’s account
`
`identifying information, the secure registry provides the account identifying
`
`information to the third party. See limitations 1.6, 22.5, 37.7, 38.5.
`
`This is not what Brener teaches at 9:19-10:2. First, if the bank computer 150
`
`described at 9:19-10:2 is the claimed “third party” as Petitioner alleges (Reply at 9-
`
`11), then that same bank computer 150 must receive the account information from
`
`secure provider 110 (alleged secure registry). See POR at 24; Ex. 2004, Jakobsson
`
`Decl. at ¶56. However, Brener does not teach this. Instead, the bank computer 150
`
`only receives a customer object (alleged time-varying multicharacter code), not
`
`account information, from a vendor 140. Brener’s bank computer 150 also only
`
`obtains “linking information”—not account information—that it then uses “to link
`
`the customer object with personal information about the customer, including
`
`customer account information.” Ex. 1005, Brener at 9:23-26. Thus, contrary to
`
`Petitioner’s assertions, the bank computer does not “send[] the request to the secure
`
`provider,” nor does the secure provider 110 “provide[] account identifying
`
`information to the bank.” Reply at 11. Indeed, Brener at 9:19-10:2 does not discuss
`
`the secure provider 110 at all, much less disclose that it sends the bank computer
`
`
`
`6
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`150 the customer’s account information.
`
`Second, Petitioner mischaracterizes Brener’s teachings by arguing that
`
`Brener’s secure provider 110 “provides account identifying information to the bank
`
`via the linking table stored in the database of the secure provider computer.” Reply
`
`at 11 (citing Brener at 9:23-26). The cited portion of Brener states, “The bank
`
`computer 150 obtains or is already provided with the linking information to link
`
`the customer object with personal information about the customer, including
`
`customer account information.” Ex. 1005, Brener at 9:24-26. The “linking
`
`information” is not the claimed “account identifying information.” Brener expressly
`
`explains that “linking information” is “stored…in a linking table…that matches up
`
`each customer object with the customer’s personal information.” Id. at 8:8-14. Thus,
`
`the linking information, as part of the linking table, is the information used to
`
`link/match the customer object to the account identifying information.3 If anything,
`
`
`3 This interpretation of “linking information” and analysis of Brener’s teachings at
`9:23-26 are also consistent with how the Petition originally interpreted this section
`of Brener. See, e.g., Pet. at 38 (summarizing 9:23-26 as “allowing the bank computer
`to obtain the customer’s account information using the linking information to link
`the customer object with personal information about the customer”); see also id.
`(“Brener further teaches that the customer’s information may include account
`identifying information, such as the customer’s name or other ‘personal information
`about the customer, including customer account information.’”). Thus, Petitioner in
`its Reply contradicts itself when it argues that 9:23-26 instead teaches that the secure
`
`
`
`7
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`the bank computer 150 appears to serve as the recited secure registry when it uses
`
`the linking information to link/match the customer object to the customer’s personal
`
`information. Since the recited “third party” must be “a party other than the entity,
`
`the provider, and the secure registry” (see POR at 16-18), the bank computer 150
`
`cannot be the “third party.” Accordingly, even if the Board rejects PO’s proffered
`
`construction for “the provider requesting the transaction,” Brener does not disclose
`
`that its bank computer 150 acts as a third party by receiving account identifying
`
`information, such as a customer’s personal information, from the secure provider
`
`110 (the purported secure registry).
`
`The cited portions of Brener undermine Petitioner’s argument that “even
`
`where the vendor sends the transaction request to the bank, Brener explains that it is
`
`also sent from the vendor directly to the secure provider.” Reply at 11 (citing Ex.
`
`1005, Brener at 3:1-4, 3:25-30). Brener reiterates that when it comes time to process
`
`payment for a purchase transaction, the vendor sends the customer object directly to
`
`the financial institution (i.e., bank 150). Brener at 3:25-30. The financial institution
`
`again only obtains linking information—not account identifying information, such
`
`as personal or account information—and uses the linking information to look up the
`
`
`provider “provides account identifying information to the bank via the linking table
`stored in the database of the secure provider computer.” Reply at 11.
`
`
`
`8
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`identity of the customer in the linking tables. Id. at 3:30-4:2. These disclosures
`
`further reinforce that Brener’s bank/financial institution, performing acts associated
`
`with a secure registry, is not the recited “third party.” Moreover, that Brener’s vendor
`
`sends a separate transaction identifier to the secure provider (Id. at 3:1-4), where the
`
`latter also acts as a secure registry, shows at most that Brener’s system can include
`
`two separate secure registries.
`
`III. A POSITA WOULD NOT BE MOTIVATED TO COMBINE BRENER
`AND WEISS TO ACHIEVE THE RECITED TIME-VARYING CODE
`
`A.
`
`Patent Owner Debunked the Petition’s Lone Example of How
`Brener and Weiss Would Be Combined
`
`The Federal Circuit has consistently held that a Petitioner cannot rely on
`
`conclusory statements to satisfy its obviousness burden; Petitioner must articulate a
`
`specific reasoning for combining references, including a “clear, evidence-supported
`
`account” of “how the combination” would work. Personal Web Techs., LLC v.
`
`Apple, Inc., 848 F.3d 987, 994 (Fed. Cir. 2017). The Petition fell short of this
`
`requirement for its proposed combination of Brener and Weiss, providing only
`
`cursory motivational statements. See, e.g., Pet. at 28 (Vaguely asserting that a
`
`POSITA “would have found it beneficial to incorporate a time-varying aspect into
`
`Brener’s customer objects, resulting in a time-varying code…”). As to how a
`
`POSITA would “incorporate a time-varying aspect into Brener’s customer objects,”
`
`
`
`9
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`Petitioner offers only that Brener’s customer object includes “a public key and a
`
`private key authorization code” and that a POSITA “would have modified Brener’s
`
`customer object private key authorization code
`
`to utilize a dynamic
`
`nonpredictable, time-varying code generated using a predetermined algorithm.”
`
`Ex. 1002, Tygar Decl. at ¶63. No further explanation is provided.
`
`In its POR, PO established that Brener’s “private key authorization code”
`
`(PKAC) is a digital certificate—a position conceded by Petitioner’s own expert4—
`
`and that, accordingly, time-varying such a digital certificate would be highly
`
`impractical and crippling to Brener’s system and principle of operation. See POR at
`
`25-37. Petitioner now re-characterizes its earlier modification as only “one
`
`‘example’ of how the combination could be achieved,”5 chastising PO for attacking
`
`this “single example” instead of Petitioner’s “broader proposal to incorporate a time-
`
`varying aspect into the customer object.” Reply at 12. Petitioner’s PKAC
`
`modification was not just “one example” of how to incorporate a time-varying aspect
`
`
`4 See POR at 32-33; Ex. 2005, Tygar Depo. at 39:2-40:4 (Dr. Tygar admitting that
`one of the only “two possibilities that make sense with the private-key authorization
`code” is that the PKAC is a “digital signature from a certificate authority that attests
`to the public key,” i.e., a digital certificate).
`5 Petitioner on Reply abandons its original argument that a POSITA “would have
`modified Brener’s customer object private key authorization code” in favor of a new
`argument that a POSITA would “append” a time-varying portion to the PKAC. See,
`infra, Section III.C.
`
`
`
`10
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`into Brener’s customer object, it was the only example set forth in the Petition.
`
`See Petition at 26-29, 56-58; Ex. 1002, Tygar Decl. at ¶¶62-64. Having completely
`
`debunked Petitioner’s specific example of how a POSITA would combine these
`
`references, there is no need to address Petitioner’s non-specific, “broader proposal.”
`
`It is Petitioner’s burden to provide “a clear, evidence-supported account of how the
`
`alleged teachings work together.” Apple v. Uniloc Luxembourg S.A., IPR2018-
`
`00420, Paper 7, 18 (citing Personal Web, 848 F.3d at 994). Because Petitioner fails
`
`to provide a specific, tangible, evidence-supported explanation of how a POSITA
`
`would actually “incorporate a time-varying aspect into Brener’s customer objects”
`
`(Pet. at 28), the Board must reject Petitioner’s obviousness allegations as conclusory.
`
`In re Magnum Oil Tools Int’l, Ltd., 829 F.3d 1364, 1380 (Fed. Cir. 2016) (“[t]o
`
`satisfy its burden of proving obviousness, a petitioner cannot employ mere
`
`conclusory statements. The petitioner must instead articulate specific reasoning
`
`based on evidence.”).
`
`B.
`
`Brener’s PKAC is a Digital Certificate
`
`PO provided multiple reasons why Brener’s PKAC is a digital certificate
`
`issued by a certificate authority, see POR at 28-33, and Petitioner’s expert agreed
`
`that one of the only “two possibilities” for the PKAC was that it is a “digital signature
`
`from a certificate authority that attests to the public key,” i.e., a digital certificate.
`
`
`
`11
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`Ex. 2005, Tygar Depo. at 39:2-40:4.
`
`In response, Petitioner relies on its expert’s deposition testimony that the other
`
`“possibilit[y]” for the PKAC is that it is the customer’s private key. Reply at 13
`
`(citing Ex. 2005, 39:24-40:1). Petitioner misconstrues Brener to argue it “explicitly
`
`teaches that the private key may be disseminated to specific parties to the
`
`transaction as part of the private segment of the customer object.” Reply at 13
`
`(citing Ex. 1005, Brener at 10:27-28). But a POSITA would not understand that
`
`Brener teaches disseminating a customer’s private key to other parties of a
`
`transaction. A key tenet of public-key cryptography is that a user’s private key is
`
`kept private; disseminating the private key to other parties would compromise the
`
`security of the entire asymmetric key-based security system. Instead, a POSITA
`
`would understand Brener’s disclosure that the customer object’s “private segment to
`
`a digital certificate or key” refers to the digital signature within the certificate signed
`
`by the private key of the certificate authority, not that Brener teaches dissemination
`
`of the customer’s private key as part of the customer object. See Ex. 1015, Jakobsson
`
`Depo. at 86:2-12 (Dr. Jakobsson testifying that “in my view that solidly rules out the
`
`option that [the PKAC] is a private key because one does not transmit private
`
`keys…That would be an insecure thing to do. So I agree with Dr. Tygar that it’s
`
`a certificate in the context of Brener.”).
`
`
`
`12
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`Moreover, contrary to Petitioner’s attempt to mischaracterize PO’s expert’s
`
`written and oral testimony, Dr. Jakobsson’s declaration in support of (ISO) PO’s
`
`Preliminary Response (POPR) is consistent with his later declaration in support of
`
`the POR. In his POPR declaration, Dr. Jakobsson indicated that the PKAC is a digital
`
`signature that is “used by the holder of the public key to verify that the purchase was
`
`requested by the holder of the private key,” which is what a digital certificate does.
`
`Ex. 2001, Jakobsson Decl. ISO POPR at ¶63. And as Dr. Jakobsson made clear at
`
`his deposition, digital certificates include digital signatures. Ex. 1015, Jakobsson
`
`Depo. at 87:3-12.6 Moreover, in both of his declarations, Dr. Jakobsson testified that
`
`modifying this digital signature would render it void. Compare Ex. 2001 at ¶63
`
`(“changing the digital signature’s value directly over time[] means the existing
`
`public key held by the other party can no longer be used to verify the resulting
`
`changed digital signature”) to Ex. 2004 at ¶67 (“Altering the certificate, including
`
`its digital signature, whether in time or otherwise, renders the certificate void and
`
`useless as it cannot be used to verify the authenticity of the public key.”).
`
`Accordingly, Petitioner fails to rebut PO’s argument that the PKAC, which
`
`Petitioner argued would vary in time, is a digital certificate. Petitioner also does not
`
`
`6 Tellingly, Petitioner’s citation to Jakobsson’s deposition transcript at 86:22-87:2,
`87:16-88:11 conveniently excises this explanatory testimony.
`
`
`
`13
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`dispute that a time-varying digital certificate would cripple Brener’s system or
`
`render it inoperable for its intended purpose. See Reply at 12-16. As such, Petitioner
`
`has failed to show that a POSITA would be motivated to modify Brener’s customer
`
`object private key authorization code to be time-varying in view of Weiss.
`
`C.
`
`Petitioner’s New Argument That Weiss’ Time-Varying Value Can
`Be Appended to Brener’s PKAC Should Be Disregarded
`
`The Petition only offered a single explanation of how a POSITA would
`
`incorporate a time-varying aspect into Brener’s customer objects: “[A POSITA]
`
`would have modified Brener’s customer object private key authorization code
`
`to utilize a dynamic nonpredictable, time-varying code generated using a
`
`predetermined algorithm.” Petition at 28 (citing Ex. 1002, Tygar Decl. at ¶63). On
`
`Reply, Petitioner did not address PO’s counter-argument that a POSITA would not
`
`modify Brener’s PKAC (i.e., digital certificate) to vary in time (POR at 25-37),
`
`because a time-varying PKAC (i.e., digital certificate) cannot work. Instead,
`
`Petitioner proffers a new argument in its Reply that a POSITA “would have
`
`incorporated a time-varying aspect into Brener’s customer object by appending the
`
`time-varying portion to the existing information, such as the private key
`
`authorization code.” Reply at 14.
`
`Of course, new arguments on Reply, that could have been raised in the
`
`Petition, are not permitted. PTAB Trial Practice Guide August 2018 Update at 14
`
`
`
`14
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`(“Petitioner may not submit new evidence or argument in reply that it could have
`
`presented earlier, e.g. to make out a prima facie case of unpatentability.”). This is
`
`clearly a new argument, as appending a time-varying code to “existing information”
`
`of the customer object or the PKAC is not the same thing as modifying the PKAC to
`
`be time-varying. Referring to the graphic shown below, appending (or prepending)
`
`a discrete time-varying code to the other fields of the customer object, such as the
`
`PKAC or public key, does not modify the PKAC or public key; the bits of the PKAC
`
`or public key remain unchanged (much as adding a caboose to a train does not
`
`modify the train’s dining car or sleeping car).
`
`Petitioner’s Proposed Appending/Prepending of Time-Varying Code
`
`Accordingly, Petitioner’s Reply argument that a POSITA would have
`
`
`
`
`
`15
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`incorporated a time-varying aspect into Brener’s customer object by appending a
`
`time-varying code to the customer object is new and should be disregarded by the
`
`Board. Patent Owner is prejudiced by such new arguments because it cannot have
`
`its own expert opine on the technical illegitimacy of such new arguments. See
`
`August 2018 Update at 14 (“The sur-reply may not be accompanied by new evidence
`
`other than deposition transcripts of the cross-examination of any reply witness.”).
`
`D.
`
`Petitioner’s New Argument Appending Weiss’s Time-Varying
`Value to Brener’s PKAC is Meritless
`
`Petitioner’s new argument that a POSITA would have appended Weiss’s
`
`time-varying value to Brener’s customer object’s “existing information, such as the
`
`private key authorization code” is also without merit. Weiss expressly discloses that
`
`its “variable, non-predictable codes” (alleged time-varying multicharacter code) are
`
`“for the purpose of positively identifying an authorized individual or user of an
`
`apparatus or system and thereafter giving clearance to carry out a privileged
`
`transaction or access to a protected system or facility.” Ex. 1006, Weiss at 1:15-21;
`
`see also id. at 1:22-52. Notably, Petitioner’s own expert concedes that in Weiss
`
`“[t]hese dynamic, time-varying codes were used to replace ‘[t]ypical instances
`
`of fixed codes includ[ing] card numbers, user numbers or passwords issued to
`
`customers of computer data retrieval services.’” Ex. 1002, Tygar Decl. at ¶35
`
`(citing Ex. 1006, Weiss at 1:36-40). Accordingly, Petitioner agrees that Weiss’s
`
`
`
`16
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`variable, non-predictable codes, like user names and passwords, are used to
`
`authenticate the identity of individuals, i.e., to confirm that a person really is
`
`who they say they are.
`
`Critically, Brener’s customer object is not used to authenticate the customer’s
`
`identity when a vendor 140 provides the customer object to the secure provider 110
`
`as part of a transaction request. Instead, Brener repeatedly teaches that a customer’s
`
`identity is authenticated with the secure provider 110 (alleged secure registry) as a
`
`preliminary step when the customer logs into and connects to the secure provider
`
`110, which is always performed before the customer is allowed to access a vendor
`
`website to initiate a transaction. Ex. 1005, Brener at 8:3-6, 8:21-9:14, 10:22-24,
`
`11:23-12:6 (describing how customer first logs into secure provider 110 to establish
`
`a “secure connection pipeline 120” with secure provider 110 to avoid revealing its
`
`network address to vendors 140, which the customer accesses through the secure
`
`provider 110). Brener also explicitly teaches that the customer logs into the secure
`
`provider 110 using an “ID and password” first, and is then able to access the
`
`vendor’s website through the “secure provider’s proxy servers.” Id. at 8:3-6 (“To
`
`[anonymously shop online at vendor websites], a customer uses his customer
`
`computer 100…to connect the secure provider computer 110 and login with a
`
`certificate based ID and password.”); 9:12-14 (“With the secure connection, the
`
`
`
`17
`
`

`

`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`customer computer 100 can anonymously connect to the web sites of various
`
`vendor computers 140 using the Internet via the secure provider’s proxy servers.”).
`
`Thus, a POSITA would understand that the customer’s identity has already been
`
`authenticated with the secure provider 110 before the customer ever has a chance to
`
`provide its customer object to the vendor as part of a purchase transaction.
`
`After the customer’s identity