UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner,
`v.
`UNIVERSAL SECURE REGISTRY, LLC,
`Patent Owner.
`_________________________________________
`Case CBM2018-00024
`U.S. Patent No. 8,577,813
`________________________________________
`
`REPLY TO PATENT OWNER’S RESPONSE
`
`

`

`Contents
`
`Introduction .......................................................................................................... 1
`I.
`II. The Board Correctly Found The ’813 Patent To Be CBM Review Eligible. .. 1
`A. The ’813 Patent As A Whole Claims Subject Matter That Was Known And
`Obvious. .................................................................................................................. 1
`B. The Board Need Not Consider Whether The ’813 Patent Is A Technical
`Solution To A Technical Problem. ......................................................................... 2
`C. USR Misconstrues The Record In Its Attempt To Compare This Case To
`IBG v. Trading Technologies Int’l. ........................................................................ 3
`III. Maes In View Of The ’585 Reference Discloses A “Secure Registry.” .......... 4
`IV. Maes In View Of The ’585 Reference Discloses The Claimed “Encrypted
`Authentication Information.” ..................................................................................... 6
`V. A POSITA Would Have Applied The ’585 Reference’s Teachings To Maes
`Because Both References Include Secure Registries That Receive And Decrypt
`Information To Authenticate The User. ..................................................................... 7
`VI. Maes Only Suggests that Physical Components Should Remain Compatible
`With Existing Infrastructure, Not Server Software. .................................................. 9
`VII. Combining The ’585 Reference’s Authentication Codes With Maes’
`Authentication System Would Have Improved The Security Of Maes. ................. 12
`A. A POSITA Would Have Understood That The ’585 Reference’s Multi-
`factor Authentication Code Is More Secure Than The Encrypted Information Of
`Maes. ..................................................................................................................... 12
`B. The ’585 Reference’s Authentication Codes Would Have Added Security
`To Maes’ Digital Certificate System. ................................................................... 13
`VIII. Combination Function 230 Teaches That Inputs Can Be Combined,
`Including Secret Information And Identifying Information. ................................... 14
`IX. Maes Discloses Displaying Indicators For The Plurality Of Accounts. ........ 14
`X. Maes Discloses De-Activating The Electronic ID Device. ............................ 17
`XI. The ’585 Reference Discloses Generating The Claimed Seed. ..................... 17
`XII. Maes And The ’585 Reference Disclose The Claimed Act Of Generating
`Encrypted Authentication Information. ................................................................... 19
`XIII. Maes In View Of Maritzen Discloses Not Permitting The Entry Of User
`Input.
` ..................................................................................................................... 20
`
`i
`
`

`

`XIV. A POSITA Would Not Have Been Dissuaded From Applying Maritzen’s
`Teachings To Maes Based On Immaterial Design Differences............................... 21
`XV. Maes Discloses Displaying Options For Purchase. ........................................ 22
`XVI. A POSITA Would Not Have Been Dissuaded From Applying Labrou’s
`Teachings To Maes Based On Immaterial Design Differences............................... 23
`XVII. USR Failed To Demonstrate Secondary Considerations Of Non-
`Obviousness. ............................................................................................................ 24
`XVIII. Conclusion ................................................................................................... 26
`
`
`ii
`
`

`

`I.
`
`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`
`Introduction
`USR’s Patent Owner Response (“POR”) fails to rebut Petitioner’s showing
`
`that the challenged claims are unpatentable. First, USR’s assertion that the
`
`claimed invention is a “technological solution” fails because, as the Board already
`
`determined, “each [of the] steps uses a technological feature that was known in the
`
`art [and] the steps appear to be implemented in a conventional manner.” DI, 12-
`
`13. Second, USR mischaracterizes the prior art references and the creativity and
`
`technical ability of persons having ordinary skill in the art. Finally, USR fails to
`
`demonstrate any secondary considerations of non-obviousness whatsoever.
`
`II. The Board Correctly Found The ’813 Patent To Be CBM Review
`Eligible.
`A. The ’813 Patent As A Whole Claims Subject Matter That Was
`Known And Obvious.
`Despite the Board previously rejecting USR’s argument that the ’813 patent
`
`is ineligible for CBM review—finding that each claimed step uses a feature “that
`
`was known in the art” and that was “conventional”— USR wastes nearly half of its
`
`POR recycling its argument that the ’813 patent solves a technical problem with a
`
`technical solution. DI, 12-13; Ex-1201, ’813 patent, 43:54-44:7; Pet. 14.
`
`Unsurprisingly, even USR’s own expert, Dr. Jakobsson, admits that all the
`
`technology used by the ’813 patent—from the hardware components, to the
`
`communication interface, to the database and encryption techniques—was known.
`
`Ex-1227, Jakobsson-Dep., 307:11-17 (’813 patent uses conventional biometric
`
`1
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`sensors), 308:19-21 (’813 patent uses a conventional user interface), 308:25-309:2
`
`(’813 patent uses conventional fingerprint sensors), 309:16-18 (’813 patent uses
`
`conventional processors), 311:3-5 (’813 patent discloses no improvements to
`
`hardware), 312:3-5 (’813 patent discloses no new form of communication
`
`interface), 312:21-25 (’813 patent can be used with any form of database), 313:21-
`
`314:17 (’813 patent discloses no new form of encryption), 315:10-14 (temporary
`
`disabling of a device was prior art), 319:10-12 (point-of-sale terminals were prior
`
`art), 322:5-13 (multifactor authentication involving biometric information was
`
`prior art), 323:17-22 (authentication based on a time-varying token was prior art),
`
`330:10-15 (limiting functionality of a user device based on a failed authentication
`
`was prior art), 355:22-356:2 (PIN and biometric based authentication was prior
`
`art); 357:9-11 (local authentication was prior art), 460:20-461:2 (combining local
`
`and remote authentication was prior art).
`
`B.
`The Board Need Not Consider Whether The ’813 Patent Is A
`Technical Solution To A Technical Problem.
`Under 37 C.F.R. Section 42.401, CBM Review is inapplicable for patents
`
`directed toward “technological inventions” that either (1) claim subject matter that
`
`“as a whole recites a technological feature that is novel or unobvious over the prior
`
`art” or (2) “solves a technical problem using a technical solution.” 37 C.F.R. §
`
`42.401. The Board need not consider the second prong if, as here, the patent only
`
`recites technological features that were known or obvious. Final Written Decision,
`
`2
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`CBM2017-00023 Paper 48, 30-31 (PTAB June 11, 2018) (“We need only assess
`
`whether one of the prongs set forth in 37 C.F.R. § 42.301(b) is deficient to
`
`determine whether the claims…are not for a ‘technological invention.’”); Apple
`
`Inc. v. Ameranth, Inc., 842 F.3d 1229, 1240 (Fed. Cir. 2016). The Board’s
`
`conclusions here do not “conflate the two prongs” of this analysis as USR contends
`
`(POR, 21) because it already found that that the ’813 patent fails to meet the first
`
`prong necessary for avoiding CBM Review and need not assess the second prong.
`
`To the extent USR contends that the ’813 patent is directed to a technical solution
`
`to a technical problem, the Petition already shows that it is not. Pet., 16-18.
`
`C. USR Misconstrues The Record In Its Attempt To Compare This
`Case To IBG v. Trading Technologies Int’l.
`USR’s reliance on IBG LLC v. Trading Techs. Int’l, Inc., 2019 WL 581580
`
`(Fed. Cir. Feb 13, 2019), is misplaced because the ‘813 patent’s eligibility has not
`
`been upheld by any final district court or PTAB determination. The Board has not
`
`held the ’813 patent to be Section 101 eligible because it has—so far—only found
`
`that it was not “more likely than not” that Petitioner would prevail in its showing
`
`patent ineligibility based on the Petition. Institution Decision, CBM2018-00026,
`
`Paper 11, 14 (PTAB 2018). Similarly, no federal court has held—in final form—
`
`the ’813 patent to be eligible as USR argues (POR, 23) because Apple’s objection
`
`to the magistrate judge’s recommendation on this issue is currently pending before
`
`the district judge. So, unlike the patents in IBG, the ’813 patent’s eligibility has
`
`3
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`not been finally determined by any court. Thus, the Board finding of CBM
`
`eligibility here is not inconsistent with any final rulings.
`
`The Board reversing its finding regarding CBM eligibility will not promote
`
`consistency with other findings regarding Section 101. USR’s argument (POR, 23-
`
`25) ignores the fact that the USPTO has finally rejected the claims in each of the
`
`’813 patent’s five continuation applications as patent ineligible under Section 101.
`
`See Applications Nos. 14/071,125, 15/045,408, 15/661,943, 15/661,955, an
`
`15/685,813. The Board’s finding of CBM eligibility here is entirely consistent
`
`with the USPTO’s findings in the ’813 continuation applications, and no reversal
`
`on the issue of CBM eligibility is therefore warranted.
`
`III. Maes In View Of The ’585 Reference Discloses A “Secure Registry.”
`The Petition shows that Maes in view of the ’585 reference discloses a
`
`“secure registry” (Pet., 31-35 (limitation 1[c])) configured to receive “encrypted
`
`authentication information” (Pet., 50-52 (limitation 1[g])) that is generated “from
`
`the non-predictable value, information associated with at least a portion of the
`
`biometric input, and the secret information” (Pet., 42-47 (limitation 1[f])). USR’s
`
`rebuttal mischaracterizes the references and Petitioner’s mapping. Ex-1225,
`
`Shoup-Decl., ¶23.
`
`As the Petition demonstrates, Maes’ financial institution 70 is a “secure
`
`registry” (Pet., 31-32, 50; DI, 31-32), which, properly construed, means a database
`
`4
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`with access restrictions. Pet., 24. Financial institution 70 is a database with access
`
`restrictions because it restricts access to information and services provided by a
`
`database. Id., 32-33. USR argues that “there are any number of security
`
`methodologies that could be implemented without using access restrictions” (POR,
`
`41), but fails to identify even one. This is not even Petitioner’s position. Financial
`
`institution 70 is a database with access restrictions because it restricts database
`
`access to authorized users by authenticating encrypted information sent by the
`
`user. Pet., 32-33. Once authorized, the financial server provides access to an
`
`authorization number that can be used to conduct a financial transaction. Id. It is
`
`irrelevant what security methodology is used to restrict access, because the claim
`
`merely requires that access to the database is restricted. Ex-1225, Shoup-Decl.,
`
`¶24.
`
`The ’585 reference also discloses a secure registry because its verifier 105
`
`restricts database access to authorized users. Pet., 35. Dr. Jakobsson asserts, with
`
`no support or explanation, that “authentication is not an access restriction” (Ex-
`
`2011, Jakobsson-Decl., ¶64), but the plain meaning of the phrase “access
`
`restriction” is a mechanism that restricts access, and the ’585 reference’s
`
`authentication mechanism clearly restricts access to financial services. Ex-1214,
`
`’585 reference, [0050], [0058], [0118]. Ex-1225, Shoup-Decl., ¶25.
`
`5
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`IV. Maes In View Of The ’585 Reference Discloses The Claimed
`“Encrypted Authentication Information.”
`Maes discloses transmitting encrypted authentication information to
`
`financial institution 70. Pet., 50 (limitation 1[g]). Financial institution 70 is
`
`coupled to central server 60, which, as the Board found, is an example of a
`
`database used by financial institution 70. DI, 32. USR contends that “[n]either
`
`[financial institution 70 nor central server 60] deals with, considers or suggests the
`
`claimed ‘encrypted authentication information’” (POR, 41), but immediately
`
`contradicts itself by acknowledging that “financial server 70 does receive
`
`encrypted information.” POR, 42; Ex-1213, Maes, 13:19-38. Ex-1225, Shoup-
`
`Decl., ¶26.
`
`The ’585 reference discloses encrypted authentication information that is
`
`generated “from the non-predictable value, information associated with at least a
`
`portion of the biometric input, and the secret information” (Pet., 42-47 (limitation
`
`1[f])), and it would have been obvious to combine these teachings with Maes
`
`because the ’585 reference’s authentication codes provide a robust security
`
`alternative to Maes’ encrypted information message. Pet., 48-49. USR complains
`
`that Apple’s combination fails to identify a “precise database functionality” and an
`
`“exact architecture” (POR, 47), but cannot cite to any “precise database
`
`functionality” or “exact architecture” that the claims require. In fact, Dr.
`
`Jakobsson acknowledges that the ’813 patent can be used with “any form of
`
`6
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`database.” Ex-1227, Jakobsson-Dep., 213:17-25. The combination meets the
`
`claimed limitations and the Petition shows that a POSITA would have been
`
`motivated to combine the references. There is no additional database functionality
`
`or architecture necessary to show that the claims are invalid. Nonetheless, the
`
`functionality and architecture for generating and processing the ’585 reference’s
`
`authentication codes are provided in detail by the disclosure of the ’585 reference.
`
`See, e.g., Ex-1214, ’585 reference, Figs. 1-2, [0037]-[0039], [0073]. Ex-1225,
`
`Shoup-Decl., ¶27.
`
`V. A POSITA Would Have Applied The ’585 Reference’s Teachings To
`Maes Because Both References Include Secure Registries That Receive And
`Decrypt Information To Authenticate The User.
`The ’585 reference discloses various non-limiting embodiments for
`
`generating and verifying authentication codes including encryption techniques that
`
`produce an encrypted authentication information. USR’s arguments erroneously
`
`assume that the ’585 reference is limited to one method (POR, 47), and ignore
`
`embodiments in the ’585 reference that are based on the same encryption and
`
`decryption model used by Maes. Ex-1226, Juels-Decl., ¶¶37-40. Ex-1225, Shoup-
`
`Decl., ¶28.
`
`For example, the ’585 reference discloses an authentication code 292, which
`
`is generated by encrypting a non-predictable value 291 using a block cipher. Pet.,
`
`43-45; Ex-1214, ’585 reference, [0073]. Thus, the ’585 reference’s authentication
`
`7
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`code 292 is encrypted authentication information; USR’s argument that no
`
`“encryption process, [takes] ‘authentication information’ as input” (POR, 52-53) is
`
`incorrect because authentication code 291 is authentication information that is
`
`input into a block cipher to create encrypted authentication code 292. Ex-1225,
`
`Shoup-Decl., ¶29.
`
`USR’s argument that “there is no decryption” in the ’585 reference’s system
`
`(POR, 54) overlooks that the ’585 reference discloses that the encrypted
`
`authentication code is decrypted. Ex-1214, ’585 reference, [0058] (“In some
`
`embodiments the verifier 105 decrypts a value encrypted by the user authentication
`
`device 120 using symmetric key encryption or asymmetric encryption techniques,
`
`such as public key encryption”). Likewise, the proposed combination need not
`
`undertake the “needless computational overhead” in USR’s contrived examples
`
`(POR, 55) because the ’585 reference discloses an authentication code this is
`
`encrypted, transmitted to a “secure registry,” and decrypted – just like the system
`
`in Maes. Ex-1225, Shoup-Decl., ¶30. As Dr. Ari Juels (a named inventor of the
`
`’585 reference) confirms, the verifier 105 need not separately derive its own
`
`authentication code and therefore need not store private data for each user to verify
`
`that user. Ex-1226, Juels-Decl., ¶¶37-40.
`
`
`
`USR also argues that erroneous PINs would deter a POSITA from making
`
`the proposed combination (POR, 56), but completely ignores the ’585 reference’s
`
`8
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`disclosure that PINs are first authenticated in a local authentication before being
`
`sent to the remote verifier 105. Ex-1214, ’585 reference, [0059]. Ex-1225, Shoup-
`
`Decl., ¶31.
`
`VI. Maes Only Suggests that Physical Components Should Remain
`Compatible With Existing Infrastructure, Not Server Software.
`USR’s contentions about the “basic principles of Maes” (POR, 57) are
`
`wrong because Maes makes clear that “existing infrastructure” relates only to
`
`physical devices like ATMs and kiosks and does not relate to modification to
`
`software on servers, which is the only type of modification required to combine the
`
`’585 reference with Maes. Maes itself proposes many modifications to servers that
`
`only require modifications to software and backend system changes that would not
`
`impact any “existing infrastructure.” Ex-1225, Shoup-Decl., ¶32.
`
`For example, Maes discloses embodiments where financial institutions
`
`possess a “requisite key (provided by the service provider upon enrollment) to
`
`decode (i.e., decrypt) the transmitted information to verify the identity of the user.”
`
`Ex-1213, Maes, 13:51-55. Maes discloses an enrollment process for “providing
`
`the service provider with the user’s credit card or ATM card information so that
`
`such information can be verified with the financial institutions 70 that issued such
`
`cards.” Id., 6:71-7:1. Maes also describes an enrollment process that involves
`
`comparing voice prints (id., 8:50-65) or asking a series of questions (id., 8:12-26).
`
`The existing infrastructure at the time of the Maes reference did not include
`
`9
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`support for such an enrollment process. These embodiments would have required
`
`changes to server software that are analogous to the software changes needed to
`
`implement the combination function of the ’585 reference. None of these
`
`modifications would have been incompatible with then existing infrastructure. Ex-
`
`1225, Shoup-Decl., ¶33.
`
`USR also argues that the proposed combination would require “significant
`
`modifications” that are incompatible with existing infrastructure, but Maes makes
`
`clear that compatibility with existing infrastructure is meant to avoid costly
`
`overhauls to deployed physical systems like ATMs. Id., 4:12-18; 11:52-57. In
`
`contrast, modifications to servers like the financial institution 70 or the verifier 105
`
`would be inexpensive in comparison to an overhaul of physical systems. The
`
`modifications required to implement the ’585 reference’s combination function
`
`would require only simple changes to software, without any change to existing
`
`physical systems. Accordingly, the proposed combination of the ’585 reference’s
`
`combination function with Maes would not contradict Maes’s suggestion that new
`
`systems should be compatible with existing infrastructure. Ex-1225, Shoup-Decl.,
`
`¶34.
`
`USR also argues that “a user would have to provide their private data (i.e.,
`
`their biometric information) to each and every financial institution for which they
`
`have an account because [the ’585 reference’s] verifier authorizes upon a
`
`10
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`comparison of the transmitted code with a recreated code drawn from the stored
`
`private data” (POR, 58), but neither the claims nor Maes require the use of
`
`multiple financial institutions. A user could easily have multiple accounts (e.g.,
`
`cards) with the same financial institution. Moreover, even if multiple financial
`
`institutions were used, the secure data could be stored on a centralized server as
`
`taught by Maes. Thus, sensitive information need not be distributed across
`
`multiple financial institutions. Indeed, as the ’585 reference recognizes, the
`
`verifier can be implemented as a distributed system. See Ex-1214, ’585 reference,
`
`[0038], [0139]-[0140], [0141]. A POSITA would have understood that the secure
`
`data could be kept on a centralized server like central server 60 if there were
`
`concerns about keeping sensitive data safe. Ex-1225, Shoup-Decl., ¶35.
`
`Moreover, the claims do not require the use of biometric information to
`
`generate the authentication information and authenticate the user. For example,
`
`claim 1 requires authentication information that is generated from “information
`
`associated with at least a portion of the biometric input.” See Ex-1201, ’813
`
`patent, cl. 1 (emphasis added). Claim 1 does not require that the biometric input
`
`itself is verified at the secure registry and therefore does not require that the
`
`verifier knows or uses any actual biometric information to authenticate the user.
`
`Consistent with this requirement, the ’585 reference teaches that the “User Data
`
`(P)” value that represents the biometric input to an authentication code can simply
`
`11
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`be a preprocessed form of biometric data. Ex-1214, ’585 reference, [0072],
`
`[0077]. It need not be the user’s biometric information itself. Claims 10 and 19
`
`only require that two of several factors (which happen to include biometric
`
`information) are used to generate a seed. These claims list biometric information
`
`as one of several optional inputs to generate the seed, but do not require that
`
`biometric information be used. Thus, contrary to USR’s argument, the
`
`combination of the ’585 reference and Maes does not require that the user’s
`
`biometric information is stored at each and every financial institution. Ex-1225,
`
`Shoup-Decl., ¶36.
`
`VII. Combining The ’585 Reference’s Authentication Codes With Maes’
`Authentication System Would Have Improved The Security Of Maes.
`A. A POSITA Would Have Understood That The ’585 Reference’s
`Multi-factor Authentication Code Is More Secure Than The Encrypted
`Information Of Maes.
`A POSITA would have understood that the multi-factor authentication code
`
`of the ’585 reference is harder to replicate and would therefore improve Maes’
`
`encrypted information. Pet., 47-50. USR disputes the proposed combination
`
`(POR, 44-47), but the Petition identifies a specific combination of the ’585
`
`reference’s combination function with the authentication system of Maes. Pet., 47
`
`(“It would have been obvious to combine the authentication code derivation
`
`techniques disclosed in [the ’585 reference’s] combination function with the
`
`teachings of Maes to arrive at limitation 1[f].”). USR argues that Dr. Shoup did
`
`12
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`not consider whether adding “the claimed encrypted authentication information” to
`
`Maes would have been an improvement (POR, 59), but he did consider whether the
`
`’585 reference’s combination function would have been an improvement to the
`
`security of Maes and agreed that it would “provide a more robust security system.”
`
`Ex-1202, Shoup-Decl., ¶111. Ex-1225, Shoup-Decl., ¶37.
`
`B.
`The ’585 Reference’s Authentication Codes Would Have Added
`Security To Maes’ Digital Certificate System.
`The ’585 reference’s authentication codes would have supplemented the
`
`security provided by Maes’ digital certificate security feature. Ex-1213, Maes,
`
`13:19-24. USR argues that combining the ’585 reference’s teachings would
`
`“eviscerate[] the purpose of the digital certificate” because “one would have to
`
`again connect to the server” (POR 51), but USR completely ignores embodiments
`
`in Maes itself that combine the digital certificate with a remote authentication like
`
`the one disclosed in the ’585 reference. Ex-1225, Shoup-Decl., ¶38.
`
`
`
`For example, Maes discloses embodiments “whereby the financial institution
`
`(e.g., credit card company) can verify the identity of the consumer during a
`
`purchase transaction.” Ex-1213, Maes, 13:22-25. In addition to the digital
`
`certificate, this embodiment uses a remote authentication involving encryption and
`
`decryption that is the same as the system disclosed in the ’585 reference, where the
`
`verifier 105 verifies the identity of the user during a transaction. Ex-1213, Maes,
`
`13:35-39. As Maes recognizes, this additional remote authentication “afford[s] an
`
`13
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`additional level of security for user verification.” Ex-1213, Maes, 13:19-24. Thus,
`
`far from “eviscerat[ing] the purpose of the digital certificate” (POR, 51), the ’585
`
`reference’s authentication techniques would similarly afford an additional level of
`
`security for user verification. Ex-1225, Shoup-Decl., ¶39.
`
`VIII. Combination Function 230 Teaches That Inputs Can Be Combined,
`Including Secret Information And Identifying Information.
`As shown in the Petition, it would have been obvious to apply the ’585
`
`reference’s teachings to Maes to meet the claim limitation requiring secret
`
`information that “includes the identifying information,.” Pet., 54. USR complains
`
`that the Petition fails to provide a motivation to combine (POR, 60-61), but the
`
`’585 reference’s combination function 230 shows how any input can be combined
`
`with any other input, in any order (Pet., 55; Ex-1214, ’585 reference, [0073], Fig.
`
`2), and the Petition explains various motivations to combine the ’585 reference’s
`
`combination function 230 with the teachings of Maes. Pet., 47-50. Ex-1225,
`
`Shoup-Decl., ¶40.
`
`IX. Maes Discloses Displaying Indicators For The Plurality Of Accounts.
`The Petition demonstrates that Maes discloses a “processor is configured to
`
`display indicators for the plurality of accounts” and the “act of displaying, on the
`
`user interface indicators for the plurality of user accounts stored in a memory of
`
`the electronic ID device,” as claims 13 and 17 require. Pet., 62. For example,
`
`Maes discloses that the “user select[s] a pre-enrolled credit card that is stored in
`
`14
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`memory” and that the “desired card may be selected through the user
`
`interface/display 34.” Ex-1213, Maes, 10:30-44. Ex-1225, Shoup-Decl., ¶40.
`
`Maes also discloses that the user interface/display 34 is “preferably a liquid crystal
`
`display (LCD) touch screen display (or equivalent user interface), for displaying
`
`and/or inputting data.” Ex-1213, Maes, 5:36-40. Thus, contrary to USR’s
`
`contentions (POR, 61-63), Maes does expressly disclose displaying indicators for a
`
`plurality of user accounts. Ex-1225, Shoup-Decl., ¶41.
`
`USR argues that the claimed display of indicators is not necessarily present
`
`because Maes “discloses other methods such as voice” (POR, 62), but Maes makes
`
`clear that cards can be selected through interface/display 34, which, as illustrated
`
`below, is separate from the microphone 18 used to capture voice input. Ex-1213,
`
`Maes, 5:4-6. Ex-1225, Shoup-Decl., ¶41. Moreover, Maes discloses that the
`
`interface/display 34 has two functions: a first function as an interface for “inputting
`
`data” and a second function as a display for “displaying…data.” Ex-1213, Maes,
`
`5:36-40. USR’s argument appears to conclude that the ability of interface/display
`
`34 to receive an input proves that the accounts are not displayed, but one way to
`
`choose from a list of displayed accounts is simply to type in the desired choice.
`
`Moreover, while it may be possible to search for desired cards by inputting search
`
`criteria through interface 34, Maes also discloses that the desired cards may be
`
`15
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`displayed on the display 34 because one of its two functions is to display data. Ex-
`
`1225, Shoup-Decl., ¶42.
`
`Maes also discloses that the CPU 12 “searches the memory 14 for the
`
`desired information” after the desired card is “selected through the user
`
`interface/display 34.” Ex-1213, Maes, 10:43-48. Thus, for example, the user
`
`could select the desired card from a listing of cards on the display (e.g., American
`
`Express Card, Bank of America Card, etc.) and the CPU 12 would then retrieve
`
`desired information such as the actual card number or the address associated with
`
`the card. Maes further discloses that the user can be prompted to select another
`
`card if the card information was not previously stored in device 10. Thus, for
`
`example, if the user selects his or her American Express card, and the information
`
`associated with that card is missing, the user may be prompted to select a different
`
`card. In either case, Maes still discloses displaying indicators for the plurality of
`
`user accounts stored in a memory. Ex-1225, Shoup-Decl., ¶43.
`
`USR argues that Maes’s system can be implemented “by typing in the name
`
`of the card on the user interface” (POR, 62), but as Dr. Shoup explains, displaying
`
`indicators for accounts or providing a search option were both well known, easily
`
`within the skill of a POSITA to implement, and the only practical options for
`
`providing access to multiple accounts. The ubiquity of these options is further
`
`illustrated in the Maritzen reference, which (like Maes) discloses that accounts can
`
`16
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`be selected from a list or retrieved using a search tool. Ex-1215, Maritzen, 105
`
`(“the user may select a different account from a list of accounts displayed or enter
`
`an account number into I/O 260”). Ex-1225, Shoup-Decl., ¶44.
`
`X. Maes Discloses De-Activating The Electronic ID Device.
`Claim 18 recites, and Maes discloses, “an act of de-activating the electronic
`
`ID device without generating the encrypted authentication information if the
`
`identity of the user is not successfully authenticated to the electronic ID device.”
`
`Pet., 62. Maes discloses that “PDA device 10 will prohibit the selected card
`
`information from being retrieved and transmitted to the transaction terminal 80 if
`
`the user is not biometrically verified.” Ex-1213, Maes, 12:18-23. Thus, the PDA
`
`device 10 is de-activated without generating the encrypted authentication
`
`information when the user is not successfully authenticated. Pet., 62-63. USR
`
`argues that Maes fails to disclose the claimed de-activating (POR, 63), but even by
`
`Dr. Jakobsson’s own definition, Maes discloses de-activating the device because
`
`PDA device 10 is made “ineffective” for the relevant purpose: transmitting
`
`encrypted information to conduct a transaction. Ex-2011, Jakobsson-Decl., ¶96
`
`(“de-activate means to make inactive or ineffective”). Ex-1225, Shoup-Decl., ¶45.
`
`XI. The ’585 Reference Discloses Generating The Claimed Seed.
`Maes in view of the ’585 reference discloses claim 19, which requires
`
`“generating a seed from which the authentication information is generated.” Pet.,
`
`17
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`63. USR complains that “[t]here is no other use of [authentication code 290] –
`
`ever” (POR, 65), but identifies no claim limitation, specification support, or
`
`definition that requires using claimed seed more than once. USR proposes no
`
`claim construction, and instead merely makes the bald assertion that a POSITA
`
`would not have understood the authentication code to be a seed. POR, 66.
`
`However, authentication code 290 of the ’585 reference matches the description of
`
`a “seed” presented by the ’813 patent itself because it is a value generated through
`
`various inputs that is then used to derive another value. See Ex-1201, ’813 patent,
`
`46:46-66 (“any two of the PIN, the biometric information, the electronic serial
`
`number, a discrete code associated with the device and the