throbber
Paper No. 33
`
`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 SUR-REPLY
`
`

`

`TABLE OF CONTENTS
`
`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`Page
`
`II.
`
`PATENT OWNER’S LIST OF EXHIBITS ............................................................ III
`I.
`REBER AND FRANKLIN FAIL TO DISCLOSE ACCOUNT
`IDENTIFYING INFORMATION NOT PROVIDED TO A
`PROVIDER ..................................................................................................... 1
`A.
`Patent Owner Properly Applied Petitioner’s Construction ................... 1
`B.
`No Motivation to Combine Reber and Franklin ................................... 3
`REBER AND FRANKLIN FAIL TO DISCLOSE “ACCESS
`RESTRICTIONS” ........................................................................................... 5
`A.
`Intrinsic Evidence Supports Patent Owner’s Construction While
`Petitioner’s Effective Construction is Impermissibly Broad ................ 5
`Reber and Franklin Fail to Disclose “Access Restrictions” ................ 10
`Reber and Franklin Fail to Disclose Third Party Limitation .............. 16
`Reber and Franklin Fail to Disclose “Receive a Transaction
`Request…” Limitations of Claims 1 and 22 ....................................... 23
`1.
`Intrinsic Evidence Supports Patent Owner’s Construction ...... 23
`2.
`Reber and Franklin Fail to Disclose “Receive a
`Transaction Request” ................................................................ 25
`Reber and Franklin Fail to Disclose Claims 3 and 24 ......................... 28
`E.
`III. CONCLUSION .............................................................................................. 29
`
`B.
`C.
`D.
`
`i
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`TABLE OF AUTHORITIES
`
`Page
`
`Cases
`Arendi S.A.R.L. v. Apple Inc.,
`832 F.3d 1355 (Fed. Cir. 2016) .................................................................... 12, 26
`Dayco Products, Inc. v. Total Containment, Inc.,
`258 F.3d 1317 (Fed. Cir. 2001) .........................................................................8, 9
`DSS Technology Management, Inc. v. Apple, Inc.,
`885 F.3d 1367 (Fed. Cir. 2018) ...........................................................................12
`In re: Stepan Company,
`868 F.3d 1342 (Fed. Cir. 2017) ...........................................................................28
`Leggett & Platt, Inc. v. Hickory Springs Mfg. Co.,
`285 F.3d 1353 (Fed. Cir. 2002) ............................................................................. 9
`Shire Development LLC v. Osmotica Kereskedelmi És Szolgaltato KFT,
`No. 1:12-CV-00904-AT, 2013 WL 11740203 (N.D. Georgia Sept. 25, 2013)..... 9
`Versa Corp. v. Ag-Bag Int’l Ltd.,
`392 F.3d 1325 (Fed. Cir. 2004) .........................................................................8, 9
`Statutory Authorities
`35 U.S.C. § 112 ................................................................................................. 2, 7, 9
`Rules and Regulations
`37 C.F.R. § 42.23(b) ................................................................................................17
`
`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
`
`Petitioner’s Reply—which introduces new arguments in violation of the
`
`Board’s rules—fails to remedy several deficiencies in its Petition.
`
`I.
`
`REBER AND FRANKLIN FAIL TO DISCLOSE ACCOUNT
`IDENTIFYING INFORMATION NOT PROVIDED TO A PROVIDER
`
`A.
`
`Patent Owner Properly Applied Petitioner’s Construction
`
`Petitioner contradicts itself when it argues that Patent Owner (PO) “Fails to
`
`Apply
`
`the Broadest Reasonable
`
`Interpretation of
`
`‘Account
`
`Identifying
`
`Information.’” Reply at 2. It was Petitioner—not Patent Owner—who previously
`
`argued that “[u]nder the broadest reasonable construction standard, the term
`
`‘account identifying information’ as used in the ’539 patent means ‘personal
`
`information about an entity such as name, address, or account number.’” Petition at
`
`16; see also id. at 21, 37-38. In its Response (POR [Paper 25]), PO showed that,
`
`under Petitioner’s own proffered construction, both Reber and Franklin fail to
`
`disclose that account identifying information is not provided to a provider because
`
`these references each disclose name and/or address information to the provider. POR
`
`at 27-32. Thus, PO’s analysis simply applied Petitioner’s construction, and did not
`
`“improperly narrow the claims.” Reply at 2.
`
`Backtracking on its own construction, Petitioner first contends that “claim 4
`
`of the ’539 patent explicitly requires the secure registry to transmit address
`
`information to the provider,” and, consequently, “independent claim 1 must be
`
`1
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`construed broadly enough to encompass transmission of address information to the
`
`provider.” Id. However, rather than require the secure registry to transmit address
`
`information to the provider, claim 4 requires the secure registry “to obtain the
`
`appropriate address for delivery of the item by the third party.” Ex. 1101 at cl. 4.1
`
`Next, while originally arguing that its construction for account identifying
`
`information “is supported by the patent specification” (Petition at 16), Petitioner now
`
`contends that PO’s application of Petitioner’s construction “is inconsistent with the
`
`’539 specification because the secure registry, in at least some embodiments, must
`
`send personal information, such as a user’s name or address.” Reply at 2. However,
`
`whether the ’539 specification provides examples where a user’s name or address is
`
`provided to a merchant is irrelevant: the claims define the scope of the invention, not
`
`the specification. 35 U.S.C. § 112. And here the claims unequivocally require that
`
`“account identifying information is not provided to the provider.”
`
`Petitioner cannot have it both ways, relying on its proposed broad construction
`
`of “account identifying information” in its Petition in an attempt to show that Reber
`
`and Franklin render the Challenged Claims unpatentable (see Petition at 21, 37-38),
`
`1 Emphasis added unless otherwise indicated.
`
`2
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`and then later distancing itself from its construction when it no longer benefits its
`
`arguments.
`
`B.
`
`No Motivation to Combine Reber and Franklin
`
`Petitioner fails to establish that a POSITA would not be motivated to combine
`
`Reber with Franklin regarding the above limitation. First, Petitioner argues that
`
`“Reber does not suggest that the user’s actual name or address are provided as part
`
`of a transaction,” and that Reber and Franklin only “in some instances” provide a
`
`name or address to a merchant. Reply at 5. This misapprehends Reber and Franklin.
`
`Reber explicitly states, “After approving the transaction, the computer 20 creates a
`
`record of the transaction. The record of the transaction includes data representative
`
`of…the party initiating the transaction, the item, a party associated with the item.”
`
`Ex. 1131, Reber at 5:32-37. These actions are not optional; Reber does not recite
`
`“may create” or “may include.” See id.
`
`Next, Reber unambiguously states that after computer 64 authenticates the
`
`end user’s second data element, “computer 64 sends a message indicating the
`
`transaction to the first party.” Id. at 6:18-20. While Reber does describe that the
`
`message “can include data representative of…a name associated with the second
`
`party, an address associated with the second party” (Id. at 6:20-23), Reber does not
`
`teach that the specific contents of the message, such as the end user’s name/address,
`
`3
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`is in any way based on security concerns of the merchant. See id. at 6:20-25.2 Indeed,
`
`Reber expresses no concern over dishonest merchants—Reber trusts merchants (see
`
`POR at 34)—and instead is worried about interception of a user’s personal
`
`identification number (PIN) by unauthorized parties while transmitting the PIN to a
`
`merchant. See id. at 1:52-54, 2:29-32. Similarly, Franklin also does not teach that its
`
`provision of the customer-specific data (e.g., “card-holder’s name, account number,
`
`etc.”) to the merchant is optional: “these input parameters are pre-known or made
`
`available to both the customer and the merchant.” Ex. 1132, Franklin at 5:30-31,
`
`9:55-58.
`
`A POSITA would understand Reber trusts merchants and relies on the
`
`merchant having at least the purchaser’s name and address so that the purchased
`
`items and corresponding invoices/receipts are delivered to the purchaser. Ex. 2108,
`
`2 Reber also repeatedly demonstrates what features are optional by expressly using
`
`the word “optionally” when describing certain components or actions that its system
`
`may, but is not required to, include or take. See, e.g., id. at 3:59-61, 4:28-30, 4:31-
`
`33, 6:25-28, 6:58-60, 7:4-6, 7:45-48, 7:53-55, 7:66-8:1, 8:21-22, 9:33-36. Tellingly,
`
`Reber does not teach that the message it unconditionally sends to the first party, or
`
`its contents, are “optional.”
`
`4
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`Jakobsson Decl. at ¶ 66. A POSITA would not be motivated to modify Reber to
`
`eliminate this step of sending the merchant the purchaser’s name and address
`
`information because it would frustrate Reber’s end goal of effectuating a transaction
`
`if the purchaser could not receive their purchased items. Id.
`
`II.
`
`REBER AND FRANKLIN FAIL TO DISCLOSE “ACCESS
`RESTRICTIONS”
`
`A.
`
`Intrinsic Evidence Supports Patent Owner’s Construction While
`Petitioner’s Effective Construction is Impermissibly Broad
`
`Petitioner disputes Patent Owner’s construction of “access restrictions for the
`
`provider to [secure data / at least one portion of secure data]” (hereinafter referred
`
`to as “access restrictions”). Reply at 6-10. Petitioner instead construes the term so
`
`that mere merchant identity validation satisfies the detailed claim limitation of
`
`“execut[ing] a restriction mechanism to determine compliance with any access
`
`restrictions for the provider to secure data of the entity for completing the
`
`transaction.” See Petition at 37. Petitioner is wrong.3
`
`3 Petitioner also alleges that Patent Owner’s construction is “unsupported even by
`
`its own expert.” Reply at 7. This is patently false. See, e.g., Ex. 2108, Jakobsson at
`
`¶¶50-52.
`
`5
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`First, Petitioner argues that the examples Dr. Jakobsson provided during his
`
`deposition do not support construing “access restrictions” to be “specific to the
`
`provider.” Reply at 7. Dr. Jakobsson’s testimony supports such a construction and
`
`further serves to show the impropriety of Petitioner’s position that merchant identity
`
`validation alone satisfies the claim. Dr. Jakobsson’s first example describes how a
`
`particular type of provider, such as gas stations, may be subject to access restrictions
`
`specific to them that limit the amount they can charge to a card during a period of
`
`time to prevent fraud. See Ex. 1137, Jakobsson Depo. 363:4-364:12. Imposition of
`
`this access restriction is (1) different than merchant identity validation alone since
`
`the gas station—a valid merchant authorized to conduct credit card transactions—is
`
`also subject to this access restriction, and (2) “specific to the provider” because the
`
`access restriction may only apply to gas stations and not other types of merchants.
`
`Dr. Jakobsson’s second example, related to access restrictions that may be in
`
`place for off-shore, online gambling sites, also supports PO’s proffered construction.
`
`See Ex. 1137, Jakobsson Depo. at 365:25-366:20. Such sites are valid merchants
`
`authorized to accept credit card deposits from users but may nonetheless be subject
`
`to access restrictions based on the geographical location of the user desiring the
`
`transaction (e.g., U.S.-based requests denied but Canada-based requests allowed).
`
`Here to, the access restrictions are specific to the provider (off-shore gambling sites),
`
`6
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`and determining compliance with such access restrictions (determining location of
`
`requester) goes beyond merchant identity verification alone.
`
`Petitioner also fruitlessly argues that PO’s construction should be rejected
`
`because some embodiments in the ’539 patent describe examples where access to
`
`secure data is given “without the need for merchant-specific permissions.” Reply at
`
`8. However, whether the ’539 specification provides examples where secure data is
`
`accessed without satisfying merchant-specific restrictions is irrelevant: the claims
`
`define the scope of the invention, not the specification. 35 U.S.C. § 112. Here, the
`
`claims expressly require that the secure registry “execute a restriction mechanism to
`
`determine compliance with any access restrictions for the provider to secure data of
`
`the entity for completing the transaction.” See, e.g., Ex. 1101 at cl. 1.
`
`Second, Petitioner argues that “[n]othing in the ’539 claims suggests that the
`
`access restrictions determine which specific data may be accessed,” and that
`
`“[b]ecause ‘secure data’ is not limited to any specific data type, USR’s proposed
`
`limitation is improper.” Reply at 8-9. But the proposed construction is silent about
`
`“data type[s].” See POR (Paper 25) at 21. Instead, PO’s proffered construction only
`
`specifies “what secure data may or may not be accessed,” not “what type.” And
`
`ample intrinsic evidence exists that provides support for PO’s construction. For
`
`example, the ’539 patent discloses that “access information 34” stored in each entry
`
`7
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`30 of the secure registry’s database 24 allows “different levels of security to attach
`
`to different types of information stored in the entry 30” so that the user can specify
`
`which providers can have access to select, specific data such as credit card numbers,
`
`medical information, and tax information. See Ex. 1001 at 8:62-9:11; FIGS. 1, 3; see
`
`also id. at 9:1-6, 14:26-33.
`
`Third, Petitioner contends that “access restrictions” do not require “two or
`
`more” restrictions, relying on Versa Corp. v. Ag-Bag Int’l Ltd., 392 F.3d 1325, 1330
`
`(Fed. Cir. 2004) and Dayco Products, Inc. v. Total Containment, Inc., 258 F.3d 1317,
`
`1328 (Fed. Cir. 2001). Reply at 9-10. However, these two cases are readily
`
`distinguishable.
`
`In Versa Corp., the alleged infringer argued that an independent claim’s
`
`means-plus-function plural recitation of “channels” suggested the claim required
`
`both a recited perforated pipe and flutes since a perforated pipe alone did not create
`
`multiple channels. 392 F.3d at 1330. In rejecting this contention, the Court focused
`
`on the “context” of the claim language to hold that under the doctrine of claim
`
`differentiation a dependent claim also requiring flutes would be superfluous unless
`
`the independent claim were read to not require flutes. Id. at 1329-1330.
`
`The present claims’ use of “access restrictions” in the plural, however,
`
`presents no such contextual issues. Reading “access restrictions” to require “two or
`
`8
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`more restrictions” does not render any other claims superfluous under the doctrine
`
`of claim differentiation, nor are the recited claims means-plus-function claims. See
`
`Shire Development LLC v. Osmotica Kereskedelmi És Szolgaltato KFT, No. 1:12-
`
`CV-00904-AT, 2013 WL 11740203, at *14 (N.D. Georgia Sept. 25, 2013) (Holding
`
`the plural claim terms “substances” and “compounds” to mean “at least two
`
`substances” and “at
`
`least
`
`two compounds,” respectively, and expressly
`
`distinguishing Versa Corp. because of its reliance on §112, ¶6 and claim
`
`differentiation.)
`
`Dayco is similarly distinguishable. Like Versa Corp., Dayco also involved
`
`interpreting a plural term based on claim differentiation. See Dayco, 258 F.3d at
`
`1328; see also Shire Development, 2013 WL 11740203, at *14 (distinguishing
`
`Dayco for involving claim differentiation). But the ’539 patent claims do not use the
`
`terms “plurality,” “one or more,” “two or more,” or the like, as Dayco. Moreover,
`
`the context of the ’539 patent claims does not require that “access restrictions” be
`
`construed inconsistent with its ordinary and accepted meaning, as there are no claim
`
`differentiation issues. As such, the plural recitation of “access restrictions” requires
`
`construction as “two or more restrictions….” See also Leggett & Platt, Inc. v.
`
`Hickory Springs Mfg. Co., 285 F.3d 1353, 1357 (Fed. Cir. 2002) (Holding that “the
`
`9
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`claim recites ‘support wires’ in the plural, thus requiring more than one welded
`
`‘support wire.’”)
`
`Petitioner also argues that “the claim language contemplates determining
`
`compliance with ‘any’ access restrictions, compelling the conclusion that not even
`
`one access restriction is required.” Reply at 9-10. But the term “any” does not negate
`
`the requirement that “access restrictions” be construed to require “two or more
`
`restrictions.” Instead, the ordinary and accepted meaning of “any” in context of the
`
`claim limitation would mean any of the two or more restrictions specific to the
`
`provider.
`
`B.
`
`Reber and Franklin Fail to Disclose “Access Restrictions”
`
`As an initial matter, Petitioner does not dispute that under Patent Owner’s
`
`proffered construction for “access restrictions,” Reber and Franklin fail to teach or
`
`disclose two or more access restrictions. See Reply at 9-14. Rather, Petitioner only
`
`argues that PO’s construction requiring “two or more” is improper. See Reply at 9-
`
`10. Adopting PO’s proposed construction for “access restrictions” as requiring “two
`
`or more” would merit denial of the Petition as to Challenged Claims 1-3, 16, 21-24,
`
`and 37.
`
`First, Petitioner alleges that PO “wholly overlooks Reber’s express teaching
`
`that limiting merchant access to sensitive data is critical.” (Reply at 11, citing
`
`10
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`Ex. 1131, Reber at 1:46-49, 2:29-32). On the contrary, Reber does not expressly
`
`teach that merchant access to sensitive data is limited. The cited portions of Reber
`
`make clear that Reber is instead concerned with interception of a user’s credit card
`
`number and/or PIN by unauthorized parties (e.g., eavesdroppers) and not dishonest
`
`merchants. Ex. 1131, Reber at 1:46-49, 2:29-32; see also id. at 1:52-54 (addressing
`
`interception and subsequent use of PIN by unauthorized parties).
`
`Therefore, it would not “have been an obvious part of any transaction using
`
`Reber’s systems” to “determin[e] whether a transacting merchant (such as Reber’s
`
`computer 20) has one or more restrictions on its access” to secure data that “the user
`
`deems to be sensitive and not suitable for provision to a merchant” (Reply at 11,
`
`citing Ex. 1131, Reber at 6:17-29) because Reber is not concerned with dishonest
`
`merchants and does not describe limiting merchant access to user data. See id. at
`
`1:46-54, 2:29-32. Indeed, Reber describes multiple instances where its system
`
`provides sensitive data to the alleged merchant (computer 20) for processing. Id. at
`
`5:32-37 (computer 20 “creates a record of the transaction” that “includes data
`
`representative of…the party initiating the transaction.”); 5:39-43 (send item to
`
`party); 6:19-24 (computer 64 sends merchant a message that can include user’s name
`
`and address). Finally, Reber also describes how in at least one embodiment computer
`
`20 is entrusted with the database of entries to translate the received second data
`
`11
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`element (alleged time-varying code) and approve the transaction. See id. at 5:4-15.
`
`Thus, Reber fails to disclose that its system addresses dishonest merchants, instead
`
`providing numerous examples demonstrating that it trusts merchants.
`
`Second, Petitioner argues that “Franklin’s discussion of ‘merchant validation’
`
`(Ex-1132, Franklin, 11:38-47) would have encompassed the claimed ‘compliance
`
`with any access restrictions.’” Reply at 11-12. However, besides its expert’s
`
`testimony (See Ex. 1135, Shoup Decl. at ¶34), Petitioner provides no evidence to
`
`support this contention. Petitioner’s reliance on expert extrapolation to supply this
`
`missing limitation is insufficient to show obviousness.
`
`The Federal Circuit has explained that “common sense” should not typically
`
`be used to supply a missing limitation. Arendi S.A.R.L. v. Apple Inc., 832 F.3d 1355,
`
`1361–62 (Fed. Cir. 2016) (overturning obviousness determination and Board’s
`
`reliance on common sense to supply a missing limitation); DSS Technology
`
`Management, Inc. v. Apple, Inc., 885 F.3d 1367, 1374 (Fed. Cir. 2018) (same).
`
`Where “common sense is used to supply a missing limitation, as distinct from a
`
`motivation to combine,” the Board’s “search for a reasoned basis for resort to
`
`common sense must be searching.” Arendi, 832 F.3d 1361-62 (“common sense is
`
`typically invoked to provide a known motivation to combine, not to supply a missing
`
`claim limitation.”) (emphasis in the original); see also Cisco System, Inc. et al. v.
`
`12
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`Oyster Optics, LLC, IPR2017-01881, Paper No. 29, slip op. 44 (Feb. 26, 2019)
`
`(rejecting Petitioner’s attempt to “fill in the missing transmitter” limitation based
`
`upon its expert’s testimony that “a POSITA would have understood the node
`
`incorporating the receiver in [the prior art at] FIG. 2 would have also included a
`
`transmitter”).
`
`Here, Petitioner concedes that Franklin’s discussion concerning merchant
`
`validation by the acquiring bank does not expressly teach “access restrictions,” and
`
`instead Petitioner relies upon its expert’s assertion that “a POSITA would have
`
`understood that validating a merchant during a transaction…would involve not only
`
`confirming the merchant’s identity, but also ensuring that the validated merchant is
`
`entitled to the access it seeks before forwarding that request to the issuing bank for
`
`approval.” Reply at 11-12. This allegation is nothing more than the type of “common
`
`sense” argument that the Federal Circuit and Board have repeatedly rejected. Indeed,
`
`Petitioner’s contention is not proffered as a motivation to combine Franklin with
`
`Reber, but serves only to extrapolate Franklin’s teaching of merchant identity
`
`validation at an acquiring bank to something significantly more: a determination that
`
`a provider has complied with access restrictions in place for a provider before
`
`allowing access to secure data. No such teaching is made in Franklin and Petitioner’s
`
`attempt to extrapolate such a teaching from Franklin runs counter to case law.
`
`13
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`Moreover, Dr. Jakobsson explained that a POSITA would understand that
`
`merchant validation is not the same thing as determining compliance with “access
`
`restrictions,” even provided two real-world examples during his deposition
`
`highlighting this distinction. See Ex. 1137, Jakobsson Depo. 363:4-364:12, 365:25-
`
`366; see also Ex. 2108, Jakobsson Decl. at ¶¶71-72.
`
`Third, Petitioner contends “Franklin expressly discloses that the acquiring
`
`bank receives a request for authorization and subsequently validates both the
`
`merchant identity [indication of the provider] and the time-varying credit card
`
`number [time-varying multicharacter code] simultaneously.” Reply at 12 (citing
`
`Ex. 1132, Franklin at 11:33-49).4 Petitioner mischaracterizes Franklin’s teachings.
`
`In Franklin, the acquiring bank does not validate the proxy credit card number (i.e.,
`
`transaction number); that task is explicitly carried out by the issuing bank through a
`
`complex process requiring “test MAC” generation and comparison. See Ex. 1132,
`
`4 This is a new argument presented by Petitioner and it should be disregarded by
`
`the Board. In its Petition, Petitioner relied on Franklin’s discussion of merchant
`
`validation only to show that compliance with “access restrictions” was based on an
`
`“indication of the provider,” not “time-varying multicharacter code.” See Petition at
`
`37.
`
`14
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`Franklin at 11:46-12:33. A POSITA would understand that Franklin’s passing
`
`remark about the acquiring bank verifying “the credit card number represents a valid
`
`number” simply means that it checks to ensure that the card number meets certain
`
`basic requirements for credit card numbers (e.g., correct number of digits, doesn’t
`
`include letters, etc.). Indeed, the acquiring bank does not possess the customer
`
`database 62—which includes the customer’s private key and customer-related
`
`data—needed to validate the proxy credit card number. See, e.g., 12:1-26. Moreover,
`
`Franklin stresses that the merchant (and by extension the merchant’s acquiring bank)
`
`would not know that the proxy card number is not a standard credit card number.
`
`See, e.g., Ex. 1132, Franklin at 3:7-11.
`
`Furthermore, Franklin’s issuing bank, which does perform proxy card number
`
`validation, is a separate entity from the acquiring bank. See Ex. 1132, Franklin at
`
`11:39-49 (acquiring bank “not shown” in FIG. 7; “acquiring bank then
`
`forwards…request to the issuing bank”). Recognizing this deficiency, Petitioner
`
`argues for the first time that “it would have been obvious simply to perform the
`
`merchant validation procedure at the issuing bank…. One reason for organizing the
`
`system in this way would be to increase efficiency….” Reply at 12-13. The Board
`
`should ignore these new arguments since they could have been raised in the Petition
`
`and, at this stage in the proceeding, such new arguments prejudice PO who cannot
`
`15
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`introduce new evidence, such as expert testimony, to refute Petitioner’s claims. See
`
`PTAB Trial Practice Guide August 2018 Update (“TPG Update”), 14. However, to
`
`the extent these new contentions are considered, Petitioner again falls short.
`
`Petitioner’s new modification to Franklin, which rolls in merchant validation
`
`into the issuing bank, still does not address whether determination of compliance
`
`with any access restrictions for the provider is based at least in part on the time-
`
`varying multicharacter code of the transaction request. Franklin says nothing about
`
`whether the merchant who sent the transaction request complies with any access
`
`restrictions specific to the merchant.
`
`For at least these reasons above, Petitioner fails to show that Franklin and
`
`Reber render obvious “access restrictions.”
`
`C.
`
`Reber and Franklin Fail to Disclose Third Party Limitation
`
`Patent Owner advanced numerous arguments concerning why the Petition
`
`failed to show that Reber and Franklin disclosed “the account identifying
`
`information is provided to a third party to enable or deny the transaction with the
`
`provider” (hereinafter “third party limitation”), and why the Petition failed to show
`
`that it would be obvious to combine Reber and Franklin. See POR at 45-55. Instead
`
`of addressing Patent Owner’s rebuttal head-on, Petitioner chose to ignore the
`
`Petition’s contentions, and PO’s responses thereto, and instead present entirely new
`
`16
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`arguments for why Reber and Franklin disclose the third party limitation, and why a
`
`POSITA would be motivated to combine/modify Reber and Franklin to achieve this
`
`limitation. These new arguments prejudice PO and must be disregarded because they
`
`attempt to make out new theories of unpatentability that could have been presented
`
`earlier, but were not. See TPG Update, 14; See also 37 C.F.R. § 42.23(b).
`
`First, Petitioner argues for the first time that “Reber discusses the ability of
`
`the computer 64…to direct a third party (or parties) to credit and debit the provider
`
`and entity accounts…as a potential alternative to simply authenticating the
`
`transaction itself.” Reply at 14-15 (citing Ex. 1131, Reber at 6:25-28). By contrast,
`
`the Petition asserts that “Reber is described in terms of a transaction between two
`
`parties wherein a remote database performs a comparison and authentication of the
`
`transacting party’s identity,” couching its argument based on “what party controls
`
`the remote computer and database.” See Petition at 40. Now, for the first time,
`
`Petitioner pivots in an entirely new direction to argue that Reber alone discloses a
`
`third party because computer 64 “could take on a role as an intermediary…that
`
`directs” “a third party (such as a bank) to credit and debit accounts.” Reply at 14-15.
`
`The Board should disregard this new argument.
`
`Even considering Petitioner’s new position, Reber fails to satisfy the third
`
`party limitation. The cited portion of Reber (Ex. 1131, Reber at 6:25-28) does not
`
`17
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`mention a third party, or teach that computer 64 directs a third party. See id. Instead,
`
`the context of Petitioner’s citation reveals that Reber describes the various actions
`
`the computer 64 itself takes, including authenticating the second data element,
`
`sending a message indicating the transaction to a first party, and optionally, directing
`
`that accounts be credited/debited. See Ex. 1131, Reber at 6:17-28. Moreover,
`
`Dr. Jakobsson did not agree that a POSITA would understand the cited portion of
`
`Reber as teaching the computer 64 to direct a third party to credit/debit accounts.
`
`Instead, Dr. Jakobsson testified that 6:17-18 of Reber provides context to 6:25-28
`
`and makes it “very clear…[t]he direction is not the third party. The direction must
`
`be the computer performing the task or directing a portion of the computer [64].”
`
`Ex. 1137, Jakobsson Depo. at 434:11-18.
`
`Second, Petitioner’s newly presented contentions concerning Franklin—
`
`including newly annotated figures—are even more prejudicial. Petitioner’s Reply
`
`presents a combination of Reber and Franklin that sets forth an entirely new
`
`“architecture that hosts the functionality necessary to authenticate an external card
`
`number in one data center (shown in the modified Figure 1 below in red) and then
`
`involve a third party bank or other financial institution to receive sensitive user
`
`account information and conduct authentication as a traditional backend (shown
`
`18
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`below in green).” Reply at 16-17; compare Annotated FIG. 1 of Reply at 17 (shown
`
`below) with Annotated FIG. 1 of Petition at 25.
`
`Petitioner’s Reply goes on to include another newly annotated figure of
`
`Franklin to argue for the first time that Franklin’s issuing bank should be considered
`
`as two distinct entities (secure registry in red and third party in green). Reply at 16,
`
`18; compare Annotated FIG. 7 of Reply at 18 (shown below) with Annotated FIG.
`
`7 of Petition at 27.
`
`19
`
`

`

`Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`
`Petitioner also presents new motivations to combine in its Reply. See Reply
`
`at 18-19 (“minimize changes to the software running existing processing systems,”
`
`“existing infrastructure should be left

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


Or .

Accessing this document will incur an additional charge of $.

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

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket