Paper No. 34
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`________________
`
`APPLE INC.,
`
`Petitioner,
`
`v.
`
`UNIVERSAL SECURE REGISTRY LLC,
`
`Patent Owner
`
`________________
`
`Case IPR2018-00812
`
`U.S. Patent No. 8,856,539
`
`________________
`
`PATENT OWNER’S REPLY IN SUPPORT OF ITS MOTION TO AMEND
`PURSUANT TO 37 C.F.R. § 42.121
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`________________
`
`APPLE INC.,
`
`Petitioner,
`
`v.
`
`UNIVERSAL SECURE REGISTRY LLC,
`
`Patent Owner
`
`________________
`
`Case IPR2018-00812
`
`U.S. Patent No. 8,856,539
`
`________________
`
`PATENT OWNER’S REPLY IN SUPPORT OF ITS MOTION TO AMEND
`PURSUANT TO 37 C.F.R. § 42.121
`
`
`
`TABLE OF CONTENTS
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`Page
`
`III.
`
`I.
`II.
`
`INTRODUCTION ........................................................................................... 1
`PETITIONER’S ARGUMENTS FOR DENIAL OF MTA BASED
`ON DUTY OF CANDOR VIOLATIONS AND ESTOPPEL LACK
`MERIT ............................................................................................................. 1
`SUBSTITUTE CLAIMS ARE PATENTABLE OVER PRIOR ART ........... 3
`A.
`Limitations 39[b], 44[a], 47[b]: “from the provider” ............................ 3
`B.
`Limitations 39[c] and 46[b]: “time value” ............................................ 6
`C.
`Limitations 39[e]-[f] and 44[d]-[e]: “validate an identity of the
`provider and then execute a restriction mechanism…” ...................... 11
`Limitations 47[f], [g]: “public ID code” ............................................. 14
`D.
`IV. CLAIMS LIMITATIONS ARE PATENTABLE UNDER § 101 ................ 19
`CLAIMS LIMITATIONS 39[h], 44[b], 47[c] SATISFY 35 U.S.C.
`V.
`§ 112 .............................................................................................................. 23
`VI. CONCLUSION .............................................................................................. 25
`
`i
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`TABLE OF AUTHORITIES
`
`Page
`
`CASES
`Alice Corp. Pty. Ltd. v. CLS Bank Int'l
`134 S. Ct. 2347 ....................................................................................... 21, 23
`Cisco Systems, Inc. v. C-Cation Techs., LLC,
`IPR2014-00454 (PTAB, Aug. 29, 2014) ......................................................... 4
`DeSilva v. Dileonardi,
`181 F.3d 865 (7th Cir. 1999) ........................................................................... 4
`Universal Secure Registry, LLC v. Apple, Inc.,
`1:17-cv-00585-JFB-SRF (D. Del. Sep. 18, 2018) .........................................20
`
`STATUTORY AUTHORITIES
`35 U.S.C. § 112 ........................................................................................................23
`
`RULES AND REGULATIONS
`37 C.F.R. § 1.321 ....................................................................................................... 2
`37 C.F.R. § 42.24 ....................................................................................................... 4
`37 C.F.R. § 42.51 ....................................................................................................... 3
`37 C.F.R. § 42.6 ...................................................................................................4, 13
`
`OTHER AUTHORITIES
`Office PTG Guide, 77 Fed. Reg. 48,756, 48,767 (Aug. 14, 2012) ............................ 3
`
`ii
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`Ex. 2101
`
`Ex. 2102
`Ex. 2103
`
`Ex. 2104
`
`Ex. 2105
`Ex. 2106
`Ex. 2107
`
`Ex. 2108
`
`Ex. 2109
`Ex. 2110
`Ex. 2111
`Ex. 2112
`
`Ex. 2113
`
`PATENT OWNER’S LIST OF EXHIBITS
`
`Declaration by Dr. Markus Jakobsson in Support of
`Patent Owner’s Preliminary Response
`Curriculum Vitae of Dr. Markus Jakobsson
`Declaration ISO of Unopposed Motion for Admission
`Pro Hac Vice of Jordan B. Kaericher.
`Declaration ISO of Unopposed Motion for Admission
`Pro Hac Vice of Harold A. Barza
`U.S. Application No. 11/768,729
`U.S. Application No. 09/710,703
`Declaration by Dr. Markus Jakobsson in Support of
`Motion to Amend
`Declaration of Dr. Markus Jakobsson in Support of
`Patent Owner’s Response
`Rough Deposition Transcript of Dr. Victor John Shoup
`Disclaimer of Claims 5-8, 17-20, 26-30
`Final Deposition Transcript of Dr. Victor John Shoup
`U.S. District Court for Delaware Report and
`Recommendation.
`Declaration by Dr. Markus Jakobsson in Support of
`Patent Owner’s Reply to MTA Opposition
`
`iii
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`Universal Secure Registry LLC (“Patent Owner”) submits this Reply in
`
`support of its Conditional Motion to Amend, Paper 21 (“MTA”), and in response to
`
`Petitioner’s Opposition to the MTA, Paper 29 (“Op.”).
`
`I.
`
`INTRODUCTION
`
`Petitioner’s Opposition to the MTA is without merit: it improperly attacks the
`
`propriety of Patent Owner’s presentation of the substitute claims, including
`
`purported violations of duty of candor and the applicability of estoppel; and it also
`
`improperly incorporates substantive arguments from its Petition and Reply in an
`
`obvious attempt to circumvent this Board’s order on page limits. See Paper No. 17.
`
`II.
`
`PETITIONER’S ARGUMENTS FOR DENIAL OF MTA BASED ON
`DUTY OF CANDOR VIOLATIONS AND ESTOPPEL LACK MERIT
`
`Petitioner argues that (1) the MTA should be denied because Patent Owner
`
`allegedly violated its duty of candor with the Board, and (2) Patent Owner should be
`
`estopped from amending its claims to include what Petitioner believes is previously
`
`disclaimed subject matter. See Op. at 2-4. Petitioner’s contentions are factually and
`
`legally meritless.
`
`First, substitute claim 47 does not include amendments that were “previously
`
`disclaimed in the -023 CBM proceeding.” Id. at 2. Substitute claim 47 unequivocally
`
`requires that the claimed “account identifying information” include a “public ID
`
`code that identifies a financial account number.” Paper 21 (MTA) at A3-A4. A third
`
`1
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`party then uses the “public ID code” to obtain a financial account number. Id.
`
`Previously disclaimed claims 5-8, 16-19, and 26-30 of the ’539 Patent did not recite
`
`a “public ID code,” much less a “public ID code that identifies a financial account
`
`number.” Thus, Petitioner’s contention that Patent Owner reintroduces subject
`
`matter previously disclaimed in the ’539 Patent is demonstrably false. Moreover,
`
`whether Patent Owner disclaimed a claim in another patent not at issue before the
`
`Board in this proceeding that included a “public ID code” (see Op. at 3 n.1) is
`
`irrelevant because, among other things, disclaimer of such subject matter was not
`
`subject to adverse judgment.
`
`Second, Petitioner’s contention that Patent Owner has violated its duty of
`
`candor with the Board because “USR failed to disclose that it planned to seek or had
`
`sought inconsistent positions before the Board” is meritless. Op. at 3. Patent Owner
`
`has not taken any “position” in the past that now contradicts its stance that the
`
`substitute claims are patentable in view of the prior art. On August 17, 2018, Patent
`
`Owner submitted a disclaimer under 37 C.F.R. § 1.321(a) disclaiming claims 5-8,
`
`16-19, and 26-30 of the ’539 Patent (Ex. 2110). Patent Owner has never stated that
`
`the subject matter of these disclaimed claims was obvious in view of prior art or was
`
`unpatentable for any reason. See, e.g., Paper 25 (Patent Owner’s Response) at 1 n.1.
`
`As such, there is no “inconsistent position” that Patent Owner needed to disclose to
`
`2
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`the Board. Petitioner’s contention that Patent Owner violated 37 C.F.R.
`
`§ 42.51(b)(1)(iii) is also baseless. This rule relates to discovery between parties and
`
`not to duty of candor with the Board.
`
`Third, Patent Owner is not estopped from submitting the pending substitute
`
`claims. Petitioner alleges that “USR would also derive unfair advantage (to
`
`Petitioner’s detriment) if not estopped because it avoided institution of the -023
`
`CBM altogether…The Board should not permit USR to reap the benefit of its
`
`inconsistent and misleading positions.” Op. at 4 (citations omitted). As discussed
`
`above, Patent Owner has not taken any “inconsistent” positions. Furthermore, Patent
`
`Owner’s MTA does not derive an unfair advantage or impose a detriment on
`
`Petitioner. If Petitioner believes the unpatentability arguments it made with respect
`
`to disclaimed claims 5-8, 16-19, and 26-30 in CBM2018-00023 apply to the
`
`substitute claims here, it may raise those arguments—and any other new argument—
`
`in its Opposition. Office PTG Guide, 77 Fed. Reg. 48,756, 48,767 (Aug. 14, 2012).
`
`III.
`
`SUBSTITUTE CLAIMS ARE PATENTABLE OVER PRIOR ART
`
`A.
`
`Limitations 39[b], 44[a], 47[b]: “from the provider”
`
`Petitioner first argues that Reber alone discloses the limitation “from the
`
`provider” because a “POSITA would have found it obvious to configure Reber’s
`
`transaction request to include a first data element containing information about a
`
`3
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`merchant/provider…and a second data element containing a time-varying code
`
`corresponding to an entity.” Op. at 4-5 (citing Ex. 1131, Reber at 5:17-19 (first
`
`embodiment), 5:45-59 (second embodiment)). However, Petitioner’s Opposition
`
`provides no motivation to combine Reber’s first and second embodiments with one
`
`another. Instead, Petitioner attempts to improperly incorporate by reference
`
`arguments allegedly made in the Petition and POR Reply. Op. at 5 n.2. The Rules
`
`expressly prohibit this practice. 37 C.F.R. § 42.6(a)(3); see Cisco Systems, Inc. v. C-
`
`Cation Techs., LLC, IPR2014-00454, Paper 12 at 10 (PTAB, Aug. 29, 2014); see
`
`also DeSilva v. Dileonardi, 181 F.3d 865, 866-67 (7th Cir. 1999).1 Having cited to
`
`12 pages of its Petition and 6 pages of its POR Reply, it is wholly unclear what
`
`specific argument(s) Petitioner attempts to advance as its motivation(s) to combine
`
`for this limitation, effectively asking Patent Owner and the Board to “play
`
`archeologist with the record” to re-construct Petitioner’s arguments. DeSilva, 181
`
`F.3d at 866-67. The Board should not do so.
`
`Petitioner next appears to argue that the combination of Reber and Franklin
`
`1 The Opposition is exactly 25 pages. If the arguments that Petitioner attempts to
`
`incorporate by reference are not precluded, Patent Owner will be prejudiced by
`
`Petitioner exceeding the allotted page limit. See 37 C.F.R. § 42.24(b)(3).
`
`4
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`discloses this limitation. Op. at 5-6. Petitioner provides just two sentences for its
`
`proposed
`
`combination
`
`that
`
`fail
`
`to
`
`explain what
`
`the
`
`proposed
`
`modification/combination actually is or why a POSITA would be motivated to make
`
`it. See id. Indeed, Petitioner merely contends that Franklin discloses that a
`
`“merchant…submits a request for authorization…including a proxy transaction
`
`number…to the issuing bank front-end…for processing in conjunction with a third
`
`party.” Id. (citing Ex. 1132, Franklin at 11:33-49, 12:30-32). Petitioner also argues
`
`that “[a] POSITA would have been motivated to combine the disclosures of Reber
`
`and Franklin to arrive at these claim limitations for the same reasons set forth in the
`
`Petition and discussed in Apple’s reply brief.” Op. at 6 (citing Petition at 23-31, 33-
`
`35; POR Reply at § II(A)(4)). As above, incorporation by reference is improper and
`
`prejudices Patent Owner. It is also unclear what specific argument(s) Petitioner
`
`attempts to proffer for its motivation(s) to combine.
`
`In its POR Reply, Petitioner argues that it would be obvious to a POSITA to
`
`modify Reber’s first message transmitted from computer 20 to computer 64 (see Ex.
`
`1131, Reber at 5:17-27) to additionally include an indication of the provider because
`
`Franklin’s acquiring bank verifies that the merchant is a valid merchant. See Reply
`
`at 22-23. Thus, Petitioner attempts to import functionality of a bank into Reber’s
`
`computer 64. However, this contradicts Petitioner’s prior reliance on computer 64
`
`5
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`as merely being an “intermediary” between the database and third party financial
`
`institution, and not a financial institution itself. See POR Reply at 15. Indeed, in
`
`attempting to show that the prior art satisfies the third party limitation (“account
`
`identifying information is provided to a third party to enable or deny the transaction
`
`with the provider”), Petitioner divorces computer 64’s role as a financial institution
`
`and assigns that responsibility to a third party as purportedly taught by Franklin. See
`
`POR Reply at 15-19. Thus, according to Petitioner, computer 64 is not an acquiring
`
`bank or any other party related to financial institutions that would be incentivized in
`
`the same way to validate a merchant’s identity like Franklin. A POSITA would not
`
`look to Franklin to make such a modification to Reber. Ex. 2113, Jakobsson at ¶32.
`
`B.
`
`Limitations 39[c] and 46[b]: “time value”
`
`Petitioner alleges that Reber alone or in view of Franklin renders obvious the
`
`limitations “the transaction request including a time value representative of when
`
`the time-varying multicharacter code was generated” and “extract the time value
`
`from the transaction request” (referred to herein as “time value limitations”). Op. at
`
`6; MTA at B1, B3 (39[c], 46[b]). Petitioner fails to show that the references disclose
`
`these limitations for a number of reasons. Ex. 2113, Jakobsson at ¶33.
`
`Petitioner argues that “Reber alone renders this limitation obvious.” Op. at 7.
`
`However, this contention is unsupported because it’s based on incorrect
`
`6
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`mischaracterizations of what the prior art discloses. Specifically, Petitioner first
`
`contends that Reber’s “transaction data…may contain information sufficient for
`
`either the computer 20…or the computer 64…to generate transaction records that
`
`include, for instance, the date and time of the transaction.” Op. at 6 (emphasis added)
`
`(citing Ex. 1131, Reber at 5:33-38). However, Reber never discloses that the
`
`transaction data contains information sufficient to generate a record that includes
`
`a date and time of the transaction. See Ex. 1131, Reber at 5:33-38. Instead, the cited
`
`section of Reber states that after computer 20 has approved the transaction,
`
`computer 20 creates a record of the already-approved transaction, including data
`
`representative of the date and time of the approved transaction. See id. Thus,
`
`Petitioner is wrong when it asserts that a “POSITA would have understood that to
`
`generate such a record, time information could [] be ‘extracted’ from the transaction
`
`data.” Op. at 6. Instead, a POSITA would conclude that computer 20 creates a
`
`date/time record based on when it approved the transaction, which would be some
`
`time after the transaction data was created and would not be known to the user at the
`
`time the transaction data was created. Ex. 2113, Jakobsson at ¶34.
`
`Petitioner further argues that “Because the time-varying second data element
`
`is generated concurrent with the time of the transaction, the second data element
`
`could include ‘a time value representative of when the time-varying multicharacter
`
`7
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`code was generated.’” Op. at 6-7. But Reber does not disclose that its second data
`
`element is generated concurrent with the time of the transaction.2 Moreover, even if
`
`it were, Reber does not disclose that the time the second data element is generated
`
`is included with the transaction data. See, e.g., Ex. 1131, Reber at 2:58-4:62.
`
`Ex. 2113, Jakobsson at ¶35.
`
`Petitioner next argues that Franklin in combination with Reber discloses the
`
`time value limitations. But Petitioner’s proffered reasoning for why a POSITA
`
`would combine Reber and Franklin is inaccurate and irrelevant. First, Petitioner
`
`argues that “[a] POSITA would have been motivated to combine Franklin’s known
`
`technique of extracting a time value from a received code with Reber’s code-based
`
`transaction system to generate a data record based on received information.” Op. at
`
`8 (emphasis added). This is not true. Franklin does not teach extracting a time value
`
`from the received code (i.e., MAC value embedded within the received transaction
`
`2 The cited portions of Reber (3:4-8, 3:20-25) say nothing about the time-varying
`
`second data element being generated concurrent with the time of the transaction.
`
`Instead, they discuss how transaction data is generated at the user location 24 using
`
`a data reader 30, and how a network access apparatus can generate transaction data.
`
`Ex. 2113, Jakobsson at n.1.
`
`8
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`number). Instead, Franklin’s issuing bank simply receives the transaction date and
`
`time as part of transaction-specific data that the merchant provides to it along with
`
`the transaction number having the embedded MAC value. See Ex. 1132, Franklin
`
`5:61-63, 9:40-43, 11:33-36; Ex. 2113, Jakobsson at ¶36.
`
`Indeed, it would prove nearly impossible to extract the transaction date and
`
`time from the received MAC since a POSITA would know that a MAC is generated
`
`using a one-way function, such as a hash function. Consistent with this, Franklin
`
`discloses that the MAC is “preferably” generated using a hash function that receives
`
`as its input the transaction-specific data, such as the transaction date and time. See
`
`Ex. 1132, Franklin at 9:59-67; see also id. at 5:28-36, 6:3-7. Hash functions are one-
`
`way functions where the output cannot reasonably be used to reversibly determine
`
`the input values. For this reason, the issuing bank’s MAC coding and comparator
`
`unit 82 in Franklin goes through the process of deriving a test MAC from the same
`
`input values used to generate the received MAC to make a comparison; the MAC
`
`coding and comparator unit 82 does not and cannot “extract” the time value from the
`
`received MAC directly, as Petitioner alleges. See Ex. 1132, Franklin at 12:17-26;
`
`Ex. 2113, Jakobsson at ¶37.
`
`Moreover, Franklin explains that the MAC is generated “as a function of the
`
`private key, customer-specific data (e.g., card-holder's name, account number,
`
`9
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`etc.) and transaction(cid:173)specific data (e.g., transaction amount, merchant ID, goods
`
`ID, time, transaction date, etc.)” Ex. 1132, Franklin at Abstract. A POSITA
`
`would know that this corresponds to an input that is significantly longer than
`
`what can be represented in 4 to 6 decimal digits. See Ex. 1132, Franklin at 8:1-
`
`4, 9:65-67. Thus, as the input is longer than the output, the generation of the MAC
`
`corresponds to a many-to-one function, meaning that it is not only computationally
`
`impossible to extract a time value from the MAC code, but also theoretically
`
`impossible. Ex. 2113, Jakobsson at ¶38.
`
`This impossibility presents a problem for Petitioner’s motivation to combine
`
`argument, which is wholly premised on the purported advantages of being able to
`
`extract time information from the received code itself. Op. at 8. (“Incorporating the
`
`time information into Reber’s one-time code would have increased efficiency since
`
`it would have eliminated the need to separately receive time data with the
`
`transaction.”). But as discussed above, in Franklin the time data (e.g., “transaction
`
`time” and “transaction date”) is received separately from the transaction number
`
`containing the MAC: “The authorization request contains [1] the transaction number
`
`and [2] the transaction-specific data,” where the latter includes the time data. Ex.
`
`1132, Franklin at 5:61-63, 9:40-43; see also id. at 11:33-38. And, as also discussed
`
`above, Franklin’s one-way function based, MAC generation scheme makes it not
`
`10
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`just practically infeasible, but also theoretically impossible to extract the time data
`
`(or any other input data) from the MAC value itself. Thus, Petitioner’s proffered
`
`reason to combine Reber and Franklin to achieve this claim limitation—increased
`
`efficiency by eliminating the need to separately receive time data and instead
`
`“incorporating the time information into Reber’s one-time code”—is meritless.
`
`Consequently, Petitioner fails to establish why a POSITA would combine Reber and
`
`Franklin. Ex. 2113, Jakobsson at ¶39.
`
`For these reasons above, Petitioner has failed to show that Reber alone or in
`
`combination with Franklin discloses claim limitations 39[c] and 46[b].
`
`C.
`
`Limitations 39[e]-[f] and 44[d]-[e]: “validate an identity of the
`provider and then execute a restriction mechanism…”
`
`Petitioner incorrectly alleges that Reber alone or in view of Franklin renders
`
`obvious the limitation “validate an identity of the provider and then execute a
`
`restriction mechanism….” Op. at 8 (emphasis added); MTA at B1-B3 (39[e]-[f],
`
`44[d]-[e]).
`
`First, Petitioner fails to provide a thorough, meaningful analysis of the
`
`purported unpatentability of this claim limitation. Petitioner’s entire discussion of
`
`this limitation consists of repeated, generalized statements about what a POSITA
`
`would have understood based on Reber’s discussion of a user sending a merchant a
`
`PIN instead of a card number to prevent “interception” of the card number from
`
`11
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`eavesdroppers, (Ex. 1131, Reber at 1:46-49, 2:29-32), and Franklin’s discussion of
`
`dishonest merchants’ unauthorized re-use of credit card numbers. Ex. 1132, Franklin
`
`at 1:39-54. These portions of Reber and Franklin do not disclose a secure registry
`
`that both validates an identity of a provider and then executes a restriction
`
`mechanism to determine compliance with any access restrictions for the provider to
`
`secure data. Ex. 2113, Jakobsson at ¶41.
`
`Petitioner argues that a “POSITA would have found it obvious to use the
`
`received transaction data of Reber to ensure both that the merchant is
`
`trustworthy…and is entitled to access the data needed to conduct the transaction,”
`
`and that “[b]ecause the only data the computer 64 receives about the transaction is
`
`the transaction data (i.e., Reber’s first data element [indication of the provider] and
`
`second data element [time-varying multicharacter code]), a POSITA would have
`
`further understood that the determination of compliance could be made based on
`
`only that received transaction data.” Op. at 9. However, as Petitioner already
`
`admitted, Reber does not disclose that its computer 64 (alleged “secure registry”)
`
`determines whether a provider has complied with any access restrictions. See
`
`Petition at 36 (“Reber does not expressly mention any restriction mechanism to
`
`determine if the provider has complied with any access restrictions.”). Moreover,
`
`Petitioner’s arguments are flawed because the issue is not whether Reber’s computer
`
`12
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`64 “could” believe a merchant is “trustworthy” or “entitled to access the data needed
`
`to conduct the transaction.” Op. at 9. Instead, the issue is whether Reber teaches or
`
`discloses that its computer 64 validates the identity of a provider and then, after such
`
`validation, executes a restriction mechanism to determine compliance with access
`
`restrictions for the provider to secure data. Reber’s computer 64 does not. 3 Ex. 2113,
`
`Jakobsson at ¶42.
`
`In its Petition, Apple argued that mere merchant validation, as described in
`
`Franklin, satisfied the claim limitation “executing a restriction mechanism to
`
`determine compliance with access restrictions….” Petition at 37 (“Franklin also
`
`expressly discloses checking to ensure that the merchant has complied with access
`
`restrictions—and is therefore a valid merchant.”) (citing to Ex. 1132, Franklin at
`
`11:38-47 (“The acquiring bank validates the authorization request by verifying that
`
`the merchant is a valid merchant...”)). Substitute claims 39 and 44, however, draw
`
`an explicit distinction between provider validation and access restriction compliance
`
`by requiring both and specifying that the secure registry “validate[s] an identity of
`
`3 Petitioner also provides no arguments in its Opposition addressing motivations to
`
`combine Reber and Franklin for this limitation, and instead attempts to incorporate
`
`such arguments by reference in violation of 37 C.F.R. § 42.6(a)(3). See Op. at 8-9.
`
`13
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`the provider and then executes a restriction requirement to determine compliance
`
`with any access restrictions….” MTA at B1-B3. Petitioner’s flawed analysis treats
`
`these two different requirements as one and the same, and ignores the fact that this
`
`limitation would subject even a valid merchant to different access restrictions that
`
`limit the merchant’s ability to have certain information accessed by a third party to
`
`perform a transaction.4 Ex. 2113, Jakobsson at ¶43.
`
`D.
`
`Limitations 47[f], [g]: “public ID code”
`
`Petitioner alleges that Reber in view of Franklin further in view of Schutzer
`
`renders obvious the limitations “the information including account identifying
`
`information that includes a public ID code that identifies a financial account number
`
`associated with the entity” and “provide the account identifying information to a
`
`third party that uses the public ID code to obtain the financial account number
`
`associated with the entity to enable or deny the transaction” (referred to herein as
`
`4 As one non-limiting example, Patent Owner’s expert, Dr. Jakobsson, explains that
`
`a gas station may be a valid merchant that is authorized to submit credit card
`
`transactions to a bank. However, the gas station may be subject to an access
`
`restriction that does not allow it to submit more than one transaction per day for a
`
`given card totaling more than $500. See Ex. 1137, Jakobsson Depo. 363:4-364:12.
`
`14
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`“public ID code limitations”). Op. at 15. This is incorrect.
`
`Petitioner’s flawed reasoning as to the unpatentability of the public ID code
`
`limitations begins with a series of misstatements concerning Reber’s teachings
`
`(emphasized below):
`
`Once the one-time code is validated, the secure registry can
`“direct” a third party to credit and debit accounts associated with a
`financial transaction. Because the direction to credit or debit a particular
`account is passed to a third party, a POSITA would have understood
`that the identifying information, such as an account number, must be
`transmitted over a network connection, such as Reber’s electronic
`network 22. In Reber…the account number that is passed to the third
`party is the user’s actual account number.
`Op. at 16 (citations omitted). Thus, Petitioner incorrectly asserts that Reber’s
`
`computer 64 (alleged “secure registry”) directs a third party to credit or debit an
`
`account and that Reber’s computer 64 transmits an account number to a third party
`
`for crediting or debiting of the account. Petitioner relies on 6:25-28 of Reber for its
`
`misplaced contentions (Op. at 5, 16), but this portion of Reber says nothing about a
`
`third party or that computer 64 transmits account numbers to a third party. See Ex.
`
`1131, Reber at 6:25-28; see also Ex. 1137, Jakobsson Depo. Trans. at 434:11-18 (As
`
`to the meaning of 6:25-28 of Reber, Dr. Jakobsson testified that the 6:17-18 provides
`
`context and makes it “very clear…The direction is not the third party. The direction
`
`15
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`must be the computer performing the task or directing a portion of the computer
`
`[64].”). Ex. 2113, Jakobsson at ¶45.
`
`Next, Petitioner argues that Schutzer’s “alternate card number” is the claimed
`
`“public ID code” because it “is used in place of a user’s actual credit card number in
`
`order to protect sensitive data during transmission (including transmissions over
`
`encrypted payment networks).” Op. at 16. Petitioner fails to acknowledge one
`
`critical shortcoming here with Schutzer that this Board has already ruled on in a
`
`related proceeding: Schutzer’s alternate card number flows from the user 2 to the
`
`merchant 4, and then to the card’s issuing bank 8 (via the merchant bank 6). Ex.
`
`1130, Schutzer at [0026]-[0027], FIGS. 1, 2. Notably, the issuing bank’s server 14
`
`does not transmit the alternate card number to a third party.5 See, e.g., id. Indeed,
`
`Schutzer’s issuing bank server 14 does not need to since server 14 is already tasked
`
`5 This Board agreed and denied institution of Petitioner’s related IPR of the ’539
`
`Patent based on Schutzer where it held “We conclude Petitioner’s assertion [that
`
`Schutzer’s issuing bank server provides account-identifying information to the
`
`authorization processor] is not consistent with the claim language, which requires
`
`that the secure registry provide the information to something other than the secure
`
`registry itself.” IPR2018-00811, Paper 9 at 8-9.
`
`16
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`with linking the alternate card number to the user’s actual card number and
`
`authorizing the transaction. Id.; Ex. 2113, Jakobsson at ¶46.
`
`In applying the teachings of Schutzer to Reber, a POSITA would at best
`
`understand that the transaction data transmitted from the end user 26 to computer 20
`
`(alleged merchant) or computer 64 (alleged secure registry) would include an
`
`alternate card number in place of the end user’s 26 real card number, and that Reber’s
`
`computer 64 would link this alternate card number to the real card number before
`
`authorizing the transaction. See Ex. 1131, Reber at 4:63-6:28, FIG. 1. This makes
`
`sense because, like Schutzer, Reber already discloses that computer 64 (alleged
`
`secure registry) is tasked with authorizing the transaction after it authenticates the
`
`end user’s 26 second data element. Id. at 6:17-18 (“The computer 64 authenticates
`
`the second data element to allow or disallow the transaction.”). Ex. 2113, Jakobsson
`
`at ¶47.
`
`Petitioner, however, proposes modifying Reber in view of Schutzer in a
`
`radically different (and unsupportable) way. Petitioner argues Schutzer would
`
`motivate a POSITA to introduce a third party into Reber, and that Reber’s computer
`
`64 (alleged secure registry)—which is already tasked with authenticating the end
`
`user’s second data element and approving the transaction—would transmit
`
`Schutzer’s alternate card number to the third party for the third party to obtain a real
`
`17
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`account number and enable the transaction. See Op. at 16-17. To support its
`
`motivation to combine argument, Petitioner mischaracterizes Schutzer. Specifically,
`
`Petitioner wrongly contends that “Schutzer teaches an ‘alternate account
`
`number’…that is used in place of a user’s actual credit card number in order to
`
`protect sensitive data during transmission (including transmissions over encrypted
`
`payment networks).” Op. at 16; see also Op. at 17 (“A POSITA would have been
`
`motivated to do so based on Schutzer’s teaching that the use of proxy information
`
`can provide an additional layer of protection for sensitive user data even where the
`
`connection is otherwise secure.”). Ex. 2113, Jakobsson at ¶48.
`
`Schutzer provides no such express teaching. Instead, Schutzer makes clear
`
`that the problem its alternate account number serves to address is that a “cardholder
`
`must trust the merchant with safeguarding the card number,” which “leaves the
`
`cardholder vulnerable to a risk of fraud by a merchant or its employees or a merchant
`
`who is honest but who is nevertheless negligent in maintaining the merchant’s web
`
`site against break-ins.” Ex. 1130, Schutzer at [0004]. Its system also “eliminates
`
`transmitting the customer’s actual card number over the Internet to the merchant
`
`and likewise eliminates the need for a secure link between the customer and the
`
`merchant. Id. at [0009] (emphasis added); see also id. at [0003] (describing
`
`limitations of secure link between customer and merchant). Thus, the purpose of
`
`18
`
`
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`Schutzer’s alternate card number is to prevent the merchant from obtaining the real
`
`account number and to dispense with the need of a secure link over the Internet
`
`between the customer and the merchant. The fact that Schutzer’s alternate card
`
`number passes through a “card association network” en route from the merchant to
`
`the issuing bank 8 is a byproduct of Schutzer’s goal of preventing the merchant from
`
`having access to the real account number. In
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
