`
`
`
`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-00025
`U.S. Patent No. 8,857,813
`_________________________________________
`
`PETITIONER’S REPLY TO PATENT OWNER RESPONSE
`
`
`
`

`

`Contents
`
`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`
`Introduction ......................................................................................................... 1 
`I. 
`II.  Argument ............................................................................................................. 1 
`A.  The Board Correctly Found The ’813 Patent To Be CBM Review Eligible.
`
`1 
`
`The ’813 Patent As A Whole Claims Subject Matter That Was Known
`1. 
`And Obvious. ...................................................................................................... 1 
`The Board Need Not Consider Whether The ’813 Patent Is A Technical
`2. 
`Solution To A Technical Problem. ..................................................................... 3 
`3.  USR Misconstrues The Record In Its Attempt To Compare This Case To
`IBG v. Trading Technologies Int’l. ..................................................................... 3 
`B.  Ground 1: USR Has Failed To Rebut Apple’s Showing That Claims 1-2, 4-
`11, 13, 16-20, And 24 Would Have Been Obvious Over The ’585 Reference in
`View of Maritzen. ................................................................................................... 5 
`1.  USR Has Failed to Overcome Apple’s Showing That The “Electronic ID
`Device” Limitation Would Have Been Obvious. ............................................... 5 
`2.  USR Has Failed to Overcome Apple’s Showing That The “Point-of-Sale
`Terminal” Limitation Would Have Been Obvious. .......................................... 13 
`3.  USR Has Failed to Overcome Apple’s Showing That The “Secure
`Registry” Limitation Would Have Been Obvious. ........................................... 16 
`4.  USR Has Failed To Overcome Apple’s Showing That Claim 4 Would
`Have Been Obvious. .......................................................................................... 19 
`5.  USR Has Failed to Overcome Apple’s Showing That Claims 6 And 18
`Would Have Been Obvious. .............................................................................. 20 
`6.  USR Has Failed to Overcome Apple’s Showing That Claims 10 and 19
`Would Have Been Obvious. .............................................................................. 21 
`7.  USR Has Failed to Overcome Apple’s Showing That Claim 20 Would
`Have Been Obvious. .......................................................................................... 22 
`C.  Ground 2: USR Has Failed To Rebut Apple’s Showing That Claims 14-15,
`22-23, And 25-26 Would Have Been Obvious Over The ’585 Reference In View
`Of Maritzen And Labrou. ..................................................................................... 23 
`1.  USR Has Failed To Overcome Apple’s Showing That A POSITA Would
`Have Been Motivated to Combine The ’585 Reference, Maritzen, And Labrou.
`
`23 
`
`i
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`D.  USR Failed To Demonstrate Secondary Considerations Of Non-
`Obviousness. ......................................................................................................... 24 
`III.  Conclusion ...................................................................................................... 26 
`
`ii
`
`

`

`I.
`
`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`
`Introduction
`Universal Secure Registry’s (“USR”) Patent Owner Response (“POR”) fails
`
`to rebut the obviousness showing set forth in Apple’s Petition. USR’s arguments
`
`rely on a narrow, unrealistic view of how a POSITA would read the prior art. For
`
`instance, USR advances the baseless contention that the ’585 reference could not
`
`be used to conduct financial transactions involving a point-of-sale terminal, even
`
`though the reference expressly describes using credit cards and card readers to
`
`access “financial services.” Elsewhere, USR advances claim constructions that
`
`read in limitations from embodiments, such as an unsupported requirement that a
`
`“secure registry” must be capable of interfacing with multiple credit card
`
`companies. USR also contends that a POSITA would not have found it obvious to
`
`implement well-known concepts such as seed values and lockout mechanisms,
`
`even though the ‘585 reference teaches exactly when and how to use them. For the
`
`reasons set forth below, USR’s arguments are inconsistent with both the disclosure
`
`of the ’813 patent and a POSITA’s understanding of the prior art.
`
`II. Argument
`A. The Board Correctly Found The ’813 Patent To Be CBM Review
`Eligible.
`1.
`The ’813 Patent As A Whole Claims Subject Matter That
`Was Known And Obvious.
`The Board previously rejected USR’s argument that the ‘813 patent solves a
`
`technical problem with a technical solution – to which USR devotes nearly half its
`
`1
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`POR – correctly finding that each claimed step uses a feature “that was known in
`
`the art” and “conventional.” DI, 8-13; Ex-1101, ’813 patent, 43:54-44:7. The
`
`evidence supporting the Board’s previous finding has only grown stronger since
`
`the DI, as 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-1127,
`
`Jakobsson-Dep., 307:11-17 (’813 patent uses conventional biometric 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).
`
`2
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`2.
`The Board Need Not Consider Whether The ’813 Patent Is
`A Technical Solution To A Technical Problem.
`Under 37 C.F.R. Section 42.301, 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.301. 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,
`
`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, 18) 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., 9-18.
`
`3.
`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
`
`3
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`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, 20-23) because Apple’s
`
`objection to the magistrate judge’s recommendation on this issue is currently
`
`pending before the district judge. Therefore, unlike the patents in IBG, the ’813
`
`patent’s eligibility has not been finally determined by any court. Thus, the Board
`
`finding of CBM eligibility here is not inconsistent with any final rulings.
`
`Furthermore, the Board reversing its finding regarding CBM eligibility will
`
`not promote consistency with other findings regarding Section 101. To the
`
`contrary, USR’s argument (POR, 20-23) ignores 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.
`
`4
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`B. Ground 1: USR Has Failed To Rebut Apple’s Showing That
`Claims 1-2, 4-11, 13, 16-20, And 24 Would Have Been Obvious Over
`The ’585 Reference in View of Maritzen.
`1.
`USR Has Failed to Overcome Apple’s Showing That The
`“Electronic ID Device” Limitation Would Have Been Obvious.
`a)
`The ’585 Reference and Maritzen Render Obvious The
`Electronic ID Device.
`As the Board found, the ’585 reference and Maritzen render obvious a
`
`system incorporating a user device [electronic ID device] that can be used to
`
`select a specific account for use in a transaction. DI, 33-34. The ’585 reference
`
`teaches that in a typical implementation of a security system, users may
`
`communicate a user name and password combination corresponding to a specific
`
`user account. Ex-1115, ’585 reference, [0003]-[0004], Pet., 36-37. The ’585
`
`reference also explains that the inputs to the combination function 230—which
`
`generates the encrypted authentication information transmitted to the verifier—can
`
`include “unique names and numbers, or other information,” which the ’585
`
`reference teaches could be related to “financial services and records.” Ex-1115,
`
`‘585 reference, [0021] (discussing how the verifier receives additional data from
`
`the user device), [0039], [0061] (same), [0097] (same), [0112] (same); Ex-1126,
`
`Juels-Decl., ¶30. From these teachings alone, a POSITA would have understood
`
`that one way for a user to “select” an account using the user authentication device
`
`120 [electronic ID device] would be to login via the user interface 130 with a
`
`username/password combination or to input “unique names and numbers, or other
`
`5
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`information” corresponding to a particular account that could be incorporated into
`
`the authentication value. Pet., 36-37; Ex-1128, Shoup-Decl., ¶23.
`
`USR’s contention (repeated from its Preliminary Response (“POPR”)) that
`
`the ’585 reference does not disclose an electronic ID device for use in financial
`
`transactions is specious. POPR, 45-46. The ’585 reference’s disclosure that
`
`“[a]uthentication can result in . . . access to . . . financial services and records”
`
`plainly teaches that the ’585 reference is applicable in the context of a financial
`
`transaction. Ex-1115, ’585 reference, [0039]. The ’585 reference also discloses
`
`that its user authentication device 120 can be “a card such as a credit card
`
`including a magnetic strip” (id., [0041])1, and communications terminal 140 can be
`
`“a card reader.” Id., [0044]. Although Dr. Jakobsson opined that the ’585
`
`
`1 When asked whether Jakobsson’s user authentication device 120 could be a credit
`
`card, Dr. Jakobsson was repeatedly evasive. Ex-1127, Jakobsson-Dep., 386:1-
`
`389:2. And his testimony that the 585 reference’s disclosure of “credit cards” is
`
`merely a reference to a “form factor” (id., 386:1-7) is flatly contradicted by the
`
`’585 reference’s disclosure that user authentication device 120 can be “a card such
`
`as a credit card including a magnetic strip.” Ex-1115, ’585 reference, [0041].
`
`Indeed, Dr. Jakobsson’s testimony on this point is so lacking in objectivity that it
`
`should lead the Board to give no credence to any of his opinions.
`
`6
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`reference “does not teach or suggest an electronic ID device that is used to conduct
`
`financial transactions or that allows a user to select one of a plurality of accounts”
`
`(Ex-2013, Jakobsson Decl., ¶58), he admitted that in the ’585 reference “some
`
`financial services would involve financial transactions” and that “a credit card
`
`transaction is related to [a] financial service.” Ex-1127, Jakobsson-Dep., 101:18-
`
`21, 108:1-5. USR’s reliance on Dr. Jakobsson’s testimony about what he, as the
`
`named inventor, purportedly intended to claim in the ’585 reference (POR, 41) is
`
`irrelevant, since Dr. Jakobsson’s subjective intent has no bearing on how a
`
`POSITA would have understood the reference’s disclosure. See Howmedica
`
`Osteonics Corp. v. Wright Med. Tech., Inc., 540 F.3d 1337, 1347 (Fed. Cir. 2008)
`
`(“testimony as to the inventor's subjective intent is irrelevant” to claim
`
`interpretation). As such, there can be no legitimate dispute about whether a
`
`POSITA would have understood the ’585 reference to apply in the context of a
`
`financial transaction. Pet., 25-26, 37; Ex-1128, Shoup-Decl., ¶24; Ex-1126, Juels-
`
`Decl., ¶¶37-38.
`
`To the extent that the claimed electronic ID device would not already have
`
`been obvious in view of the ’585 reference, a POSITA would have found it
`
`obvious to combine the ’585 reference with Maritzen’s PTD 100, which allows
`
`7
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`user selection of an account from a “list” prior to executing a financial transaction.2
`
`Ex-1116, Maritzen, [0057]; Pet., 29-38. Maritzen explains that PTD 100 includes
`
`a memory 240, which a POSITA would have understood could store the account
`
`information. Ex-1116, Maritzen, [0048]-[0049], [0065] (non-volatile memory 240
`
`can contain “transaction key[s]” associated with particular accounts), Fig. 3. Ex-
`
`1128, Shoup-Decl., ¶25.
`
`The POR merely rehashes the POPR argument that because Maritzen only
`
`expressly discloses the selection of accounts from a list in response to an
`
`“insufficient funds message,” it cannot render obvious the electronic ID device of
`
`claim 16. POR, 43-45; see also POPR, 47-49; DI, 33-34. USR argues that
`
`because the “account selected by the user” limitation of claim 16 is listed before
`
`the “generating encrypted authentication information” limitation, the account must
`
`be selected prior to generation of authentication information. POR, 44. But the
`
`Federal Circuit has made clear that the steps in method claims need not be
`
`performed in the order in which they appear unless expressly required. See
`
`
`2 This disclosure applies equally to render obvious claims 13 and 17 (and to rebut
`
`the POR’s arguments (POR, 74-75)), which require a user to select an account via
`
`“display indicators.” Maritzen’s disclosure of a “list” of accounts on the user
`
`interface plainly meets this claim limitation. Ex-1128, Shoup-Decl, ¶25.
`
`8
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`Interactive Gift Exp., Inc. v. Compuserve Inc., 256 F.3d 1323, 1342 (Fed. Cir.
`
`2001) (“Unless the steps of a method actually recite an order, the steps are not
`
`ordinarily construed to require one.”). Therefore, the POR fails to provide any
`
`legally sufficient reason to impose an order of operations on claim 16.
`
`Furthermore, even if claim 16 (or any other claim) did require such an order,
`
`Maritzen teaches that the user may select a transaction key (associated with a
`
`specific account) on the user interface prior to conducting a transaction. See Ex-
`
`1116, Maritzen, [0048] (“[T]he user may set-up specific [transaction] keys to
`
`conduct specific financial transactions.”), [0049] (“[C]learing house 130 selects an
`
`account associated with the transaction key.”). And even if Maritzen did not
`
`contain this explicit teaching, a POSITA would have found it obvious in view of
`
`Maritzen’s disclosure to apply the same account-selection mechanism used in an
`
`“insufficient funds” scenario to allow the user to select a default account or to
`
`select an account prior to initiating a transaction. POR, 42-43 (“Maritzen’s . . .
`
`electronic ID device is configured to use a pre-established account.”) (emphasis
`
`added). An account selection is a simple user interface feature that is unrelated to
`
`the issue of insufficient funds and would have been obvious to implement to
`
`improve the user experience. Ex-1128, Shoup-Decl., ¶26.
`
`USR’s argument that neither the ’585 reference nor Maritzen teaches
`
`“storing” a plurality of accounts on the authentication device (another argument
`
`9
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`recycled from its POPR) also fails. Compare POPR, 51-52 with POR, 51-52.
`
`Maritzen discloses a PTD 100 with non-volatile memory 240 that can store a
`
`transaction key 340 that corresponds to a specific account. Ex-1116, Maritzen,
`
`[0049]. Maritzen explains that the user can select (through the user interface) a
`
`transaction key (and hence an account) for use in particular financial transactions.
`
`Id. [0048], [0065], Figs. 2-3. Because the ’585 reference discloses an on-board
`
`memory for its user authentication device 120 (Ex-1115, the ’585 reference,
`
`[0041]), it would have been obvious to incorporate Maritzen’s storage of account
`
`information to the ’585 reference so that a user could conveniently select between
`
`multiple accounts. Ex-1128, Shoup-Decl., ¶27.
`
`Claim 17 recites “user interface indicators for the plurality of user accounts
`
`stored in a memory of the electronic ID device,” and would have obvious over
`
`the ’585 reference in view of Maritzen. Pet., 73-75. Specifically, Maritzen
`
`discloses a PTD 100 with non-volatile memory 240 that can store a transaction key
`
`340 that corresponds to a specific account. Ex-1116, Maritzen, [0049], [0065].
`
`Maritzen explains that the user can select (through the user interface) a transaction
`
`key (and hence an account) for use in particular financial transactions. Id., [0048],
`
`[0065], Figs. 2-3. Since the user authentication device 120 of the ’585 reference
`
`could have been configured to store account information, (Ex-1115,’585 reference,
`
`[0041]), it would likewise have been obvious to incorporate Maritzen’s teaching to
`
`10
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`display user interface indicators to facilitate account selection. Pet., 29-35; Ex-
`
`1128, Shoup-Decl., ¶28.
`
`A POSITA Would Have Been Motivated To Combine the
`b)
`’585 Reference and Maritzen.
`Contrary to USR’s assertion, a POSITA would have been motivated to
`
`combine the ’585 reference and Maritzen. DI, 39-40. The ’585 reference plainly
`
`discloses a system to control access to financial transactions3, and so Maritzen’s
`
`own system for conducting financial transactions would have been an obvious way
`
`to apply the ’585 reference’s teachings.4 See Pet., 29-35 (explaining motivation to
`
`combine), supra II(B)(1); Ex-1115, ’585 reference, [0039], [0041], [0044]; Ex-
`
`1126, Juels-Decl., ¶¶37-38. Ex-1128, Shoup-Decl., ¶29.
`
`USR’s contention that the ‘585 reference and Maritzen are directed to
`
`different fields (cryptography/security and financial transactions, respectively) and
`
`
`3 USR’s explanation that the RSA SecurID tokens discussed in the ‘585
`
`reference could not have been used in financial transactions is contradicted by the
`
`’813 patent itself, which describes the use of the same SecurID tokens to conduct
`
`financial transactions. Compare POR, 46-48 with Ex-1101, ’813 patent, 12:45-46
`
`(“In one embodiment, the user of the database will carry a SecurIDTM card
`
`available from RSA Security.”); see also Ex-1126, Juels-Decl., ¶¶37-38.
`
`
`
`11
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`therefore would not be combined (POR, 49-50) is rebutted by its own expert.
`
`Specifically, Dr. Jakobsson admitted at his deposition that the relationship between
`
`these two fields was already well known by the time of the ’813 patent. Ex-1127,
`
`Jakobsson-Dep., 307:8-11; see also Ex-1115, ’585 reference, [0039]; Ex-1116,
`
`Maritzen [0006] (discussing “settlement of vehicle-accessed, financial
`
`transactions that provide anonymity and security”); Ex-1128, Shoup-Decl.,
`
`¶30.
`
`USR’s contention – also advanced in its POPR – that the ’585 reference
`
`teaches away from the “back-and-forth” transmissions like Maritzen’s “insufficient
`
`funds” protocol is incorrect. Compare POPR, 50-51 with POR, 50-51. Rather, the
`
`“insufficient funds” message is little more than a (negative) acknowledgment of
`
`the type that USR admits the ’585 reference explicitly discusses. A POSITA
`
`would not have found merely transmitting an acknowledgement and receiving a
`
`new account selection to be a security risk. Ex-1128, Shoup-Decl., ¶31; cf. Ex-
`
`1126, Juels-Decl. ¶36.
`
`Combining the ’585 reference and Maritzen would not have required more
`
`than routine modifications to either system (POR, 48), since the ’585 reference’s
`
`authentication device 120 (which can be a credit card or a user device containing
`
`credit card information), communication terminal 140 (which can be a card
`
`reader), and the verifier 105 (which receives transaction data from the
`
`12
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`communication terminal) are already configured to control access to financial
`
`services such as transactions. Ex-1115, ’585 reference, [0039], [0041], [0044];
`
`Pet., 29-35. Moreover, the ’585 reference contemplates that its framework is
`
`adaptable and can be applied in a variety of contexts. Ex-1115, ’585 reference,
`
`[0039], [0041], [0044]. Accordingly, any such modifications would have been
`
`obvious to a POSITA. Indeed, the POR admits that Maritzen discloses a system
`
`where account information is displayed, but not stored in memory on the user
`
`device. Compare POR, 52 (“Maritzen teaches that account information is stored
`
`on the remote server (not the user device).”) with Ex-1116, Maritzen, [0057]
`
`(“[T]he user may select a different account from a list of accounts displayed on
`
`PTD 100.”). Ex-1128, Shoup-Decl., ¶32.
`
`2.
`USR Has Failed to Overcome Apple’s Showing That The
`“Point-of-Sale Terminal” Limitation Would Have Been Obvious.
`The ’585 reference and Maritzen render obvious the claimed “point-of-sale”
`
`(“POS”) terminal because they each disclose devices that could readily have been
`
`combined (communication terminal 140 in the ’585 reference and VAPGT 120 in
`
`Maritzen). USR’s arguments to the contrary (POR, 54-63) are incorrect. Ex-1128,
`
`Shoup-Decl., ¶33.
`
`First, contrary to USR’s assertion (POR, 55-59), the ’585 reference’s
`
`communication terminal 140 encompasses a point-of-sale device because it can
`
`control access to, e.g., financial information and performing financial services,
`
`13
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`including financial transactions. Ex-1126, Juels-Decl., ¶¶37-40. The ’585
`
`reference even discloses an embodiment wherein the communication terminal 140
`
`is a card reader and the user device 120 is a credit card. Ex-1115, ’585 reference,
`
`[0041], [0044]. A POSITA would have understood that in such an embodiment,
`
`the communication terminal 140 could be a POS terminal capable of receiving a
`
`swipe from a user’s credit card (i.e., “a device located at a point of sale capable of
`
`transmitting and/or receiving information related to a financial transaction”). Ex-
`
`1128, Shoup-Decl., ¶34; Ex-1126, Juels-Decl., ¶¶39-40.
`
`Although USR points to other aspects of the ’585 reference that it contends
`
`are incompatible with the use of a POS terminal (POR, 56-57), those disclosures
`
`all relate to different optional embodiments. See, e.g., Ex-1115,’585 reference,
`
`[0047] (“[t]he terminal 140 and the authentication device 120 can each be
`
`integrated”) (emphasis added), 64 (“The combination function . . . can be
`
`14
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`implemented in the . . . communications terminal 140”) (emphasis added).5
`
`Because the ’585 reference explains that it is applicable in a wide array of contexts
`
`including to control access to “financial services” (Ex-1115, ’585 reference,
`
`[0039]), a POSITA would not have read these disclosures as limiting the ’585
`
`reference in the way USR suggests. Ex-1128, Shoup-Decl., ¶35; Ex-1126, Juels-
`
`Decl., ¶¶37-38.
`
`A POSITA would have been motivated to look to Maritzen’s VAPGT for
`
`additional detail regarding implementation of a POS terminal. Ex-1116, Maritzen,
`
`[0039], [0042]. USR’s argument that no such motivation would have existed
`
`(POR, 59-63) ignores multiple paragraphs where the Petition explains that the ’585
`
`reference and Maritzen utilize a similar structure wherein the ’585 reference’s
`
`communication terminal 140 and Maritzen’s VAPGT both serve as an
`
`
`5 USR’s arguments also ignore the ’585 reference’s disclosure of a credit card (Ex-
`
`1115, ’585 reference, [0041]), and focus instead on smart cards that it claims could
`
`not be used for financial transactions. POR, 58-59. But it was well understood
`
`that smart cards (such as chip-cards) could be used in a variety of contexts,
`
`including for financial transactions. See e.g., Ex-1101, ’813 patent, 12:45-46 (“In
`
`one embodiment, the user of the database will carry a SecurIDTM card available
`
`from RSA Security.”); Ex-1126, Juels-Decl., ¶¶37-40.
`
`15
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`intermediary interface between the user device and a backend system that controls
`
`access to secure data. Pet., 55-56. As such, it would have been obvious to
`
`combine them or use them interchangeably. Id., Ex-1128, Shoup-Decl., ¶36; Ex-
`
`1126, Juels-Decl., ¶¶37-38.
`
`3.
`USR Has Failed to Overcome Apple’s Showing That The
`“Secure Registry” Limitation Would Have Been Obvious.
`As the Petition demonstrates, the ’585 reference and Maritzen disclose the
`
`claimed “secure registry.” In response, USR merely repackages the same POPR
`
`argument – which the Board rejected (DI, 31-32) – that is based on an unsupported
`
`construction of “secure registry.” POR, 63-65. The ’585 reference and Maritzen
`
`disclose this limitation because both references disclose a database used to control
`
`access to a user’s financial data. Pet., 38-40; Ex-1128, Shoup-Decl., ¶37; Ex-1126,
`
`Juels-Decl., ¶¶31, 34-36.
`
`USR’s proposed construction of secure registry is
`a)
`incorrect.
`USR’s arguments improperly add to Apple’s construction of “secure
`
`registry” a new requirement that the database store “user account information
`
`16
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`associated with different entities.”6 Although the ’813 specification suggests that
`
`the secure registry may interact with multiple credit card companies, nothing in the
`
`specification requires such an implementation. Indeed, all citations in the POR
`
`explain that the system “can” or “may” interface with multiple entities, but do not
`
`require them to do so. See also Ex-1101, ’813 patent, 16:12-18:36, Figs. 7-10
`
`(embodiments describing transactions between a single user involving a single
`
`financial institution). As such, the broadest reasonable construction would include
`
`a secure registry that only had data relating to a single credit card company. Ex-
`
`1128, Shoup-Decl., ¶38.
`
`b)
`
`Under either party’s construction, it would have been
`obvious to use the systems in the ’585 reference and
`Maritzen with multiple entities.
`The ’585 reference renders the claimed secure registry obvious because a
`
`single verifier 105 [secure registry] may be used to conduct transactions with
`
`multiple users and/or multiple entities. USR’s argument that each verifier must be
`
`specific to a particular credit card company (POR, 63-64) fails because the cited
`
`
`6 USR uses the term “entities” to refer to “credit card companies.” POR 14 (“For
`
`instance, the ’813 patent teaches that the USR database can include account
`
`information for credit cards from multiple entities, e.g. Visa, Mastercard, Discover
`
`and American Express…”)
`
`17
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`passage of the ’585 reference describes only one potential embodiment. Ex-1115,
`
`’585 reference, [0076] (“The other data also can include a verifier identifier (V). .
`
`. .” (emphasis added)). Nothing in the ’585 reference mandates that each financial
`
`institution have a separate verifier; rather, having multiple verifiers is merely an
`
`option.7 Id. Nor does the ’585 reference teach that when a single verifier is used,
`
`“two or more institutions would share the same secret with the authentication
`
`device.” POR, 64. Rather, a POSITA would have understood that although the
`
`secret key is stored in the verifier, there would be no reason to provide any secret
`
`key to any financial institution, since the verification process takes place
`
`exclusively in the verifier. This understanding would have been further reinforced
`
`by Maritzen’s disclosure of the “clearing house 130,” which performs the same
`
`verification function as the ’585 reference’s verifier in conjunction with one or
`
`more financial processors (i.e., financial institutions) without sharing user-specific
`
`secret information with those third parties. Ex-1116, Maritzen, [0050]-[0051]; Ex-
`
`1128, Shoup-Decl., ¶39.
`
`
`7 Even if the functionality of the secure registry were distributed among multiple
`
`verifiers, the ’813 patent explains that the secure registry can comprise “multiple
`
`computers connected over a computer network.” Ex-1101, ’813 patent, 10:60-63.
`
`18
`
`

`

`U.S. Pat. No. 8,577,813
`Reply to Patent Owner’s Response
`USR’s POR also repeats the same incorrect argument from its POPR that the
`
`’585 reference does not disclose “access restrictions” because “authentication” is
`
`different from an “access restriction.” POR, 64-65; see also POPR, 43-44. That
`
`argument fails because the ’585 reference explains that “authentication can result
`
`in the performance of one or more actions including . . . providing access or
`
`privileges.” Ex-1115, ’585 reference, [0039]. As such, a POSITA would have
`
`understood that when the ’585 reference discloses authentication, it is for the
`
`purpose of confirming compliance with access restrictions for, inter alia,
`
`conducting a financial transaction. Id.; DI, 31-32; Ex-1128, Shoup-Decl., ¶40.
`
`4.
`USR Has Failed To Overcome Apple’s Showing That Claim
`4 Would Have Been Obvious.
`USR’s argument that the ’585 reference and Maritzen fail to render claim 4
`
`obvious (POR, 65-66) is based on its failed contention that neither reference
`
`discloses “selection” of an account (such as by including account identifying
`
`information in the secret information). But as explained at supra II(B)(1),
`
`selecting an account would have been obvious because the ’585 reference discloses
`
`selection