`
`
`
`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
`_________________________________________
`
`PETITIONER’S REPLY TO PATENT OWNER RESPONSE
`
`
`
`
`
`
`
`
`
`
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`
`
`
`TABLE OF CONTENTS
`
` Page
`
`
`
`
`
`
`
`
`
`
`Contents
`I.
`Introduction ......................................................................................................... 1
`II. Argument ............................................................................................................. 1
`A. USR Fails To Overcome Petitioner’s Showing That The Challenged
`Claims Are Obvious. .............................................................................................. 1
`The Petition Shows That Reber And Franklin Both Disclose The
`1.
`“Wherein The Account Identifying Information Is Not Provided To The
`Provider….” Limitation ...................................................................................... 1
`The Petition Shows That Reber And Franklin Both Disclose The “Access
`2.
`Restrictions For The Provider To [Secure Data / At Least One Portion of
`Secure Data].” ..................................................................................................... 6
`The Petition Shows That Reber And Franklin Both Disclose The “Third
`3.
`Party” Limitation. .............................................................................................. 14
`The Petition Shows That Reber And Franklin Both Disclose The
`4.
`“Receive a Transaction Request” Limitations Of Claims 1 And 22. ............... 19
`The Petition Shows That Reber And Franklin Both Disclose Claims 3
`5.
`And 24. .............................................................................................................. 24
`III. Conclusion ...................................................................................................... 26
`CERTIFICATE OF SERVICE ............................................................................ 31
`
`
`
`ii
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`
`I.
`
`Introduction
`Universal Secure Registry LLC’s (“USR”) Patent Owner’s Response
`
`(“POR”) fails to rebut the obviousness showing set forth regarding U.S. Patent No.
`
`8,856,539 (“’539 patent”) in Apple’s Petition because, where it does not simply
`
`repeat arguments that the Board already rejected, it relies on unsupported claim
`
`constructions or overly-narrow reads of the claims and the prior art. Because
`
`USR’s arguments are inconsistent with the factual record, the testimony of both
`
`parties’ experts, and the law, they should be rejected.
`
`II. Argument
`A. USR Fails To Overcome Petitioner’s Showing That The
`Challenged Claims Are Obvious.
`1.
`The Petition Shows That Reber And Franklin Both Disclose
`The “Wherein The Account Identifying Information Is Not
`Provided To The Provider….” Limitation
`As the Petition demonstrated, Reber and Franklin disclose the “the account
`
`identifying information is not provided to the provider” limitations of claims 1, 22,
`
`37, and 38. See Pet., 39-42, 60, 69, 71. In response USR merely reiterates its
`
`Patent Owner Preliminary Response’s (“POPR”) argument – already rejected by
`
`the Board (DI, 8-10, 17-18) – that the Petition fails to adequately map the
`
`limitation. POR, 27-35. Reber and Franklin disclose this limitation because both
`
`references teach that account identifying information (such as names, addresses,
`
`
`
`1
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`and account numbers) should not be provided to the provider when such
`
`information is deemed sensitive. Pet., 19-23, 39-42. Ex-1135, Shoup-Decl., ¶18.
`
`a)
`
`USR’s Argument Fails to Apply the Broadest Reasonable
`Interpretation of “Account Identifying Information.”
`USR’s argument relies on the faulty premise that the challenged claims of
`
`the ’539 patent exclude any system where a user’s name or address is provided to a
`
`merchant. POR, 28. But that interpretation improperly narrows the claims and is
`
`inconsistent with the specification. First, claim 4 of the ’539 patent explicitly
`
`requires the secure registry to transmit address information to the provider. Ex-
`
`1101, ’539 patent, cl. 4. Thus, at least independent claim 1 must be construed
`
`broadly enough to encompass transmission of address information to the provider.1
`
`Shoup-Decl., ¶19.
`
`Second, USR’s position 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. For instance, in some embodiments, name and
`
`address information is made available publicly or provided along with the
`
`
`1 USR’s expert has offered no opinion to the contrary. Ex-1137, Jakobsson-Dep.,
`
`343:8-17 (“Q. So you do not have an opinion one way or the other whether the
`
`’539 patent claims are or are not limited to anonymous systems, correct? A. So as
`
`I said, this is not something I believe that I have opined on.”).
`
`
`
`2
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`transaction. Id., 17:34-38 (“[Users] can also indicate whether they wish their name
`
`given out in response to such an inquiry….”), 13:66-14:1 (“Having the USR
`
`system 10 provide the address … to the on-line merchant enables the user to
`
`purchase items….”), 12:57-62 (“In the embodiment of Fig. 9, the user initiates a
`
`purchase and writes a check to the merchant (900). The check may be a
`
`conventional check containing identifying information….”). The specification also
`
`states that the claimed invention can be used “to identify the person in many
`
`situations, and … take the place of multiple conventional forms of identification”
`
`and to “selectively provide personal … information about a person to authorized
`
`users.” Id., 3:5-9, 3:21-24. In other embodiments, personal information is
`
`withheld. The ’539 patent explains that this is sometimes necessary to prevent
`
`fraud. Ex-1101, ’539 patent, 3:47-54 (“… Enabling anonymous identification may
`
`be particularly advantageous in an unsecured environment, such as the Internet,
`
`where it has been found to be relatively trivial to intercept such credit card
`
`information.”)2. As such, the ’539 specification is clear that the types of “account
`
`identifying information” that are withheld from the provider can vary. Ex-2111,
`
`Shoup-Dep., 74:16-78:12; Shoup-Decl., ¶20.
`
`
`2 Emphasis added unless otherwise specified.
`
`
`
`3
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`Contrary to USR’s assertions (POR, 27-32), it was well known in the art
`
`(and common sense) that trusting a merchant with sensitive information is
`
`undesirable where interception of the data would be harmful to the user. Pet., 56-
`
`57; Ex-1137, Jakobsson-Dep., 468:2-11. For instance, Reber explains that the use
`
`of proxy information in transactions with “[w]eb-based merchant[s] ... prevents an
`
`interception of the end user’s credit card number by unauthorized parties.” Ex-
`
`1131, Reber, 1:43-49, see also id., 2:29-32; Ex-1137, Jakobsson-Dep., 413:14-23.
`
`Likewise, Franklin teaches that “dishonest merchants may re-use or re-distribute an
`
`individual’s credit card information” and that one of its aims is “to develop a new
`
`online commerce model that [renders] … credit card data hard to steal, and if
`
`stolen, worthless to the thief.” Ex-1132, Franklin, 1:48-54; Ex-1135, Shoup-Decl.
`
`¶21.
`
`b)
`
`Even Under USR’s Flawed Interpretation, The Account
`Identifying Information Limitation Is Obvious.
`Because Reber and Franklin both teach the selective provision of account
`
`identifying information, USR’s claim that a POSITA would not have thought to
`
`combine them is incorrect. Both references teach the use of proxy information in
`
`place of data the user deems to be sensitive, and so for at least that reason they are
`
`amenable to combination. See Ex-1131, Reber, 2:29-31, 6:17-28; Ex-1132,
`
`Franklin, 2:35-37, see also Pet. 23-31. Reber does not suggest that the user’s
`
`actual name or address are provided as part of a transaction. (Ex-1131, Reber,
`4
`
`
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`2:58-3:3, 5:45-60.) To the contrary, Reber explains that its “data elements”
`
`contain only a code number that corresponds to a specific user and that may be
`
`interpreted by the computer 64 [secure registry]. Id., 4:14-20, 5:27-32. Once the
`
`second data element is authenticated, the computer 64 may (but not must) send
`
`identifying information to the merchant. Id., 6:17-28. As such, that Reber and
`
`Franklin in some instances describe providing a name or address to a merchant
`
`(just like the ’539 patent) does not mean that a POSITA would understand them to
`
`teach providing sensitive “account identifying information” to the merchant in all
`
`instances. Ex-1135, Shoup-Decl., ¶22.
`
`Even if Reber did teach to “trust[] the merchant” in all circumstances as
`
`USR suggests (POR, 34), Franklin’s teaching that providing sensitive information
`
`to merchants can result in fraud (See Ex-1132, Franklin, 1:48-54) would have
`
`motivated a POSITA to modify Reber to withhold such information in certain
`
`contexts (e.g., where the merchant is known not to have taken adequate data
`
`security measures). Ex-1135, Shoup-Decl., ¶23.
`
`USR’s reliance on Franklin’s statement that “input parameters” used to
`
`generate the MAC including “[t]he transaction-specific data and the customer-
`
`specific data” are “pre-known or made available to both the customer and the
`
`merchant” (POR, 31-32) is also misplaced. USR’s argument that this passage
`
`suggests that Franklin always provides customer-specific data (such as a name or
`
`
`
`5
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`address) to a merchant is inconsistent with Franklin’s broader teachings that
`
`information the user deems sensitive should not be provided to merchants in order
`
`to prevent fraud. See Ex-1132, Franklin, 1:48-54. USR’s interpretation also
`
`ignores Franklin’s reference to the use of “any” customer-specific data, which
`
`suggests that such data is not “made available” to the merchant in all
`
`circumstances. See id., 9:49-58 (“The transaction wizard calls the MAC coding
`
`unit 58 and inputs the private key (or other customer-related secret), the
`
`transaction-specific data, and any customer-specific data.”). Moreover, although
`
`Franklin explains that customer-specific data shared with the merchant may (but
`
`not must) include a cardholder’s name or external account number (id., 5:30-31),
`
`that disclosure is consistent with the ’539 patent’s teaching that in some contexts,
`
`transmission of personal information is appropriate. Ex-1101, ’539 patent, 13:66-
`
`14:3, 12:57-62, 17:34-38; Ex-1135, Shoup-Decl., ¶24.
`
`In view of these teachings, Reber and Franklin each render obvious the
`
`“wherein the account identifying information is not provided to the provider”
`
`limitation. Ex-1135, Shoup-Decl., ¶25.
`
`2.
`
`The Petition Shows That Reber And Franklin Both Disclose
`The “Access Restrictions For The Provider To [Secure Data
`/ At Least One Portion of Secure Data].”
`Reber and Franklin render obvious the “access restrictions” limitations of
`
`claims 1, 22, 37, and 38. Again, the POR largely reiterates arguments that the
`
`
`
`6
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`Board has already considered and rejected. POR, 35-44; DI, 14-17. But as
`
`explained below and in the Petition, Reber in view of Franklin teaches ensuring
`
`that a merchant is valid and not subject to any restrictions prior to granting them
`
`access to sensitive information. Pet., 36-39; Ex-1135, Shoup-Decl., ¶26.
`
`a)
`
`USR’s Proposed Claim Construction of “Access
`Restrictions For the Provider” Is Unsupported.
`USR’s proposed construction of “access restrictions for the provider” is
`
`inconsistent with the intrinsic evidence, and unsupported even by its own expert.
`
`Ex-1137, Jakobsson-Dep., 364:23-24 (“I have not provided an opinion about a
`
`construction provided by the patent owner.”). USR’s construction should be
`
`rejected.
`
`First, USR reads in an unsupported limitation by suggesting that any access
`
`restrictions must be “specific to the provider,” by which USR appears to mean that
`
`each provider must have its own specific permissions. POR, 22-23. But even
`
`USR’s expert disagrees that access restrictions must be “specific to the provider,”
`
`since neither of the two examples of “access restrictions” he provided during his
`
`deposition would meet that definition. Ex-1137, Jakobsson-Dep., 363:4-365:12
`
`(describing an “access restriction” as a restriction on repeated use of a financial
`
`account from the same location); 366:5-367:1 (describing an “access restriction” as
`
`preventing an illegal transaction from taking place).
`
`
`
`7
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`Moreover, the portions of the specification that USR cites in support of its
`
`construction are limited to specific embodiments that should not be read into the
`
`claims. See Ex-1101, ’539 patent, 8:62-9:11 (discussing Fig. 3, a block diagram of
`
`“one embodiment” of the invention); 14:26-33 (describing the use of access
`
`information as part of an embodiment where the user’s address information may be
`
`accessed). USR’s proposed construction does not account for other embodiments
`
`that grant access to, e.g., financial information as part of generalized merchant
`
`validation, without the need for merchant-specific permissions. For instance, the
`
`embodiments described in Figures 7-10 each contemplate authorizing a transaction
`
`based on the validation of a single time-varying code received from a merchant,
`
`not on any specific permissions. See, e.g., id., 12:19-29 (“The USR software 18
`
`determines if the code is valid (806) and, if valid, accesses from the USR database
`
`24 the user’s credit card information (808).”); see also id., 13:3-8, 13:52-54; Ex-
`
`1135, Shoup-Decl., ¶29.
`
`Second, USR’s argument that the access restrictions must “indicate what
`
`secure data may or may not be accessed” (POR, 22-23) also finds no support in the
`
`intrinsic evidence. Nothing in the ’539 claims suggests that the access restrictions
`
`determine which specific data may be accessed. Rather, the claim language states
`
`that a restriction mechanism must be used to “determine compliance with any
`
`access restrictions for the provider to secure data.” Because “secure data” is not
`
`
`
`8
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`limited to any specific data type, USR’s proposed limitation is improper. See also
`
`Ex-1101, ’539 patent, 12:19-29, 13:3-8, 13:52-54. Nor would either of Dr.
`
`Jakobsson’s examples of “access restrictions” meet this aspect of the construction.
`
`Ex-1137, Jakobsson-Dep., 363:4-365:12, 366:21-366:1. Although USR’s points to
`
`a single statement in the ’539 specification that discusses “validating the
`
`requestor’s identity and correlating the identity, the requested information and the
`
`access information 34 provided by the person to the USR database” (POR, 23), that
`
`portion describes only an embodiment of the invention (i.e., what is “typically
`
`involve[d]”), and should not be read into the ’539 claims. DI, 15-16; Ex-1135,
`
`Shoup-Decl., ¶30.
`
`Third, USR suggests that “access restrictions” requires “two or more” such
`
`restrictions. USR’s sole support for this argument is that the term “access
`
`restrictions” in the claim language is plural. Ex-1137, Jakobsson-Dep., 367:24-
`
`369:372:14 (failing to identify any other basis). But it is well established that the
`
`use of the plural form of a word in a patent claim does not, standing alone, compel
`
`a construction requiring “two or more.” See, e.g., Versa Corp. v. Ag-Bag Int’l Ltd.,
`
`392 F.3d 1325, 1330 (Fed. Cir. 2004) (“[I]n context, the plural can describe a
`
`universe ranging from one to some higher number…”); Dayco Products, Inc. v.
`
`Total Containment, Inc., 258 F.3d 1317, 1328 (Fed. Cir. 2001) (“[I]n the present
`
`context, if the patentees had wanted to require an insert means with more than one
`
`
`
`9
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`recess, it would have been natural to limit the claimed invention to an insert means
`
`with a ‘plurality of recesses.’”); Ex-1135, Shoup-Decl., ¶31.
`
`When read in the context of the ’539 specification and claims, the broadest
`
`reasonable construction of “access restrictions” includes less than two restrictions.
`
`For instance, the claim language contemplates determining compliance with “any”
`
`access restrictions, compelling the conclusion that not even one access restriction
`
`is required. Moreover, the ’539 specification does not define “access restrictions,”
`
`provide any example of such restriction, or set a specific minimum number. See,
`
`e.g., Ex-1101, ’539 patent, 10:22-25 (“For each type of data entered, the person is
`
`asked to specify the type of access restrictions and/or whom should be allowed to
`
`access the advanced personal data (510).”). Ex-1135, Shoup-Decl., ¶28-31.
`
`b)
`
`Even Under USR’s Proposed Construction, The “Access
`Restrictions” Limitation is Obvious.
`Even under its incorrect construction, USR’s arguments still fail to rebut
`
`Apple’s showing that the “access restrictions” limitation would have been
`
`
`
`10
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`
`obvious.3
`
`First, USR’s argument that Reber does not disclose any access restrictions
`
`(POR, 35-39) wholly overlooks Reber’s express teaching that limiting merchant
`
`access to sensitive data is critical. See Ex-1131, Reber, 1:46-49; see also id., 2:29-
`
`32. As such, determining whether a transacting merchant (such as Reber’s
`
`computer 20) has one or more restrictions on its access prior to executing a
`
`transaction would have been an obvious part of any transaction using Reber’s
`
`systems, or at least obvious to implement where the secure registry contains data
`
`that the user deems to be sensitive and not suitable for provision to a merchant.
`
`See Ex-1131, Reber, 6:17-29 (optionally providing selected information to the
`
`merchant after successful authentication); Ex-1135, Shoup-Decl., ¶33.
`
`Second, contrary to USR’s assertion (POR, 40-41), a POSITA would have
`
`understood that Franklin’s discussion of “merchant validation” (Ex-1132, Franklin,
`
`11:38-47) would have encompassed the claimed “compliance with any access
`
`
`3 Notably, Dr. Jakobsson admitted at his deposition that he applied a different
`
`definition of “access restrictions” in his analysis than USR advocates in its POR.
`
`Ex-1137, Jakobsson-Dep., 365:17-20 (“Q. I’m just asking you about the two
`
`words, ‘access restrictions.’ What’s your understanding of the meaning of those
`
`words? A. It’s restrictions for access.”).
`
`
`
`11
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`restrictions.” Specifically, a POSITA would have understood that validating a
`
`merchant during a transaction, as suggested by Reber and expressly discussed in
`
`Franklin, 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. Merely validating a
`
`merchant without taking some further action to allow that merchant the appropriate
`
`access would be superfluous. Ex-1135, Shoup-Decl., ¶34.
`
`Third, USR misreads Franklin to suggest that validation does not occur
`
`“based at least in part on the indication of the provider and the time-varying
`
`multicharacter code,” as limitations 1[d] and 22[c]-[d] require. POR, 39-42.
`
`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. Ex-1132, Franklin, 11:33-49. Franklin
`
`leaves open-ended the process by which a merchant can be validated. Therefore, a
`
`POSITA would have understood that such validation could take place based on the
`
`received card number (which includes a MAC that incorporates transaction-
`
`specific data, see Ex-1132, Franklin, 9:49-57) or other means. Moreover, it would
`
`have been obvious simply to perform the merchant validation procedure at the
`
`issuing bank, depending on the needs of a particular implementation (for example,
`
`
`
`12
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`where the issuing bank and the acquiring bank are the same). DI, 15-16. One
`
`reason for organizing the system in this way would be to increase efficiency by
`
`reducing the overall number of computations (e.g., conducting only one
`
`validation/compliance operation and not two separate operations at two separate
`
`places). Ex-1135, Shoup-Decl., ¶35.
`
`Fourth, USR’s argument that Apple has not shown any motivation to
`
`combine Reber and Franklin because Apple did not identify a “base” device that
`
`would be improved by the teachings of Franklin (POR, 42-45) misconstrues
`
`Apple’s argument. As the Petition explains, no combination is necessary because
`
`Reber itself renders this limitation obvious as set forth above. Pet., 36. With
`
`respect to the Reber-Franklin combination, the Petition explains that a POSITA,
`
`using Reber’s system and its teachings about protecting sensitive information as a
`
`starting point (i.e., a base reference), would have looked to references like Franklin
`
`for guidance concerning specific methods to improve transaction security, such as
`
`
`
`13
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`validating a merchant before allowing it to access the database to complete a
`
`transaction.4 Pet., 36-37. Ex-1135, Shoup-Decl., ¶36.
`
`3.
`
`The Petition Shows That Reber And Franklin Both Disclose
`The “Third Party” Limitation.
`Both Reber and Franklin describe systems for conducting financial
`
`transactions involving a secure registry that provides information or direction to a
`
`third party, such as a card-issuing financial institution. Pet., 39-42. USR’s
`
`argument to the contrary (POR, 45-55) largely parrots arguments made in the
`
`POPR (POPR, 50-53) that the Board rejected. DI, 17-18. USR has set forth no
`
`compelling reason for the Board to reverse course at this stage of the proceeding.
`
`For instance, Reber discusses the ability of the computer 64 (which is
`
`connected to the secure registry, database 66) to direct a third party (or parties) to
`
`
`4 USR also argues that Dr. Shoup failed to consider whether the ’539 patent was an
`
`improvement over Reber. POR at 43-44. But that is not the question at issue in
`
`this proceeding. Rather, the relevant inquiry is whether a POSITA would have
`
`found it obvious to improve the Reber system (i.e., the base) using teachings from
`
`Franklin and whether that POSITA would have been motivated to do so. This is
`
`precisely what Dr. Shoup did in his declaration (Ex-1102, Shoup-Decl., ¶¶19, 114)
`
`and explained at his deposition. Ex-2111, Shoup-Dep., 28:7-29:22, 35:14-22.
`
`
`
`
`
`14
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`credit and debit the provider and entity accounts (which may be controlled by the
`
`same or different institutions) as a potential alternative to simply authenticating the
`
`transaction itself.5 Ex-1131, Reber, 6:25-28 (“[T]he computer 64 directs that an
`
`account for the first party be credited by the transaction amount, and an account for
`
`the second party be debited by the transaction amount.”) As such, a POSITA
`
`would have recognized that the computer 64 could take on a role as an
`
`intermediary between the database and a third party that directs the crediting and
`
`debiting of accounts (precisely as the secure registry does in the ’539 patent). Ex-
`
`1137, Jakobsson-Dep., 432:7-19 (Reber could be interpreted as directing a third
`
`
`5 USR points to this language as evidence that a POSITA would not have thought
`
`to combine the computer 64 of Reber with another system since the computer 64 is
`
`already capable of “directing” that certain accounts be credited and debited. POR,
`
`48-49. But that interpretation would require the computer 64 to “direct” itself to
`
`credit and debit the accounts (instead of merely doing so). Dr. Jakobsson expressly
`
`rejected this interpretation of Reber at his deposition. Ex-1137, Jakobsson-Dep.,
`
`434:19-23, 436:9-15. Dr. Jakobsson also agreed that this passage could be read to
`
`suggest that the computer 64 was “directing” a third party (such as a bank) to credit
`
`and debit accounts. Id., 432:7-19.
`
`
`
`15
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`party); see also, Ex-1101, ’539 patent, 12:19-46, Fig. 8; Ex-1135, Shoup-Decl.,
`
`¶38.
`
`Similarly, Franklin discloses a bank 26 (including bank computing center
`
`32) that could be physically distributed and controlled by different parties. See,
`
`e.g., Ex-1132, Franklin, 4:3-9 (“Although labeled as a ‘bank’, the issuing bank 26
`
`may represent other types of card-issuing institutions …. It is further noted that
`
`other participants may be involved in some phases of the transaction, such as an
`
`intermediary settlement institution, but these participants are not shown.”), 4:16-21
`
`(“…[T]he bank computing center 32 may be implemented in other forms, such as a
`
`minicomputer, a PC server, a networked set of computers, and the like.”). Ex-
`
`1135, Shoup-Decl., ¶39.
`
`In view of Franklin’s teachings, a POSITA would have found it obvious to
`
`combine the teachings of Reber and Franklin to arrive at an 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 below in green). In this
`
`combination, the secure registry would ensure that the received external transaction
`
`number was valid, while the third party would retain its traditional role of
`
`confirming the user’s credit card number and actually executing the transfer of
`
`
`
`16
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`funds. See Ex-1132, Franklin, 12:27-33 (“Once the transaction number is verified,
`
`the account manager 60 …. [s]ubmits the authorization request to the bank’s
`
`traditional processing system 84 for normal authorization processing (e.g., confirm
`
`account status, credit rating, credit line, etc.).”); Ex-1135, Shoup-Decl., ¶40.
`
`
`
`
`
`Ex-1131, Reber, Fig. 1 (annotated per Reber, 6:26-29.)
`
`
`
`17
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`
`
`
`
`
`Ex-1132, Franklin, Fig. 7 (annotated)
`
`
`
`One motivation for structuring the system in this way would be to minimize
`
`changes to the software running existing processing systems, opting instead to
`
`have a separate upstream computing unit process the received external card
`
`numbers before forwarding them to traditional processing systems. Such a
`
`
`
`18
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`modification would have been consistent with Franklin’s teachings that existing
`
`infrastructure should be left undisturbed to the extent possible. Ex-1132, Franklin,
`
`1:65-67 (invention “integrates with existing card verification and settlement
`
`systems”). This approach would also have been consistent with Reber’s teaching,
`
`discussed above, that the computer 64 at the secure registry can “direct” another
`
`party to credit or debit accounts. Reber’s teaching that the computer 64 could
`
`“direct” a third party to credit or debit accounts would have provided a POSITA
`
`with a reasonable expectation that the system could successfully validate
`
`transactions. Ex-1131, Reber, 6:25-28; see also Ex-1132, Franklin, 4:3-21; Ex-
`
`1135, Shoup-Decl., ¶41.
`
`4.
`
`The Petition Shows That Reber And Franklin Both Disclose
`The “Receive a Transaction Request” Limitations Of
`Claims 1 And 22.
`Reber and Franklin render obvious a “provider requesting a transaction”
`
`because they disclose instances where a transaction request is generated by a
`
`merchant and sent to a secure registry. USR’s arguments to the contrary (including
`
`its new claim construction6) are wrong. POR, 19-21, 54-63; Pet. 33-35, 58-59.
`
`
`6 Although USR has now offered a claim construction for “transaction request,” its
`
`argument applying that construction is essentially the same as the one it
`
`unsuccessfully advanced in its POPR. POPR, 37-43.
`
`
`
`19
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`USR’s Proposed Claim Construction Of “Provider
`Requesting The Transaction” Is Incorrect.
`Notwithstanding that the Board’s DI rejected USR’s contention that claims 1
`
`a)
`
`and 22 require the claimed “transaction request” to originate with the provider, DI,
`
`11-12, USR now argues that “provider requesting the transaction” should be
`
`construed to mean “the provider that sent the transaction request.” USR’s
`
`proposed construction should be rejected because, in addition to contravening the
`
`Board’s prior ruling, it is inconsistent with the claim language and the
`
`specification.
`
`First, USR’s position is inconsistent with both claims 1 and 22.
`
`Specifically, claims 1 and 22 both require receipt of a transaction request, but
`
`never specify from which party the transaction request is received. Had the Patent
`
`Owner intended to limit the claim to an embodiment where the merchant sends the
`
`transaction request, claim 22 could have been phrased to require “receiving a
`
`transaction request” from the provider.7 But that is not what the claim language
`
`says. Instead, the claim leaves open-ended the origin of the transaction request.
`
`See DI, 11 (“The claim language does not mandate that the provider ‘requesting a
`
`transaction’ play any role in generating the transaction request or passing it to the
`
`
`7 Indeed, USR has offered substitute claims containing just such a limitation.
`
`MTA, App’x B (claim 39[b]).
`
`
`
`20
`
`
`
`U.S. Patent No. 8,856,539
`Petitioner’s Reply to Patent Owner Response
`secure registry. Instead, it indicates simply that the provider desires to have the
`
`transaction completed.”). Although USR contends that a POSITA “would
`
`understand that the provider requesting the transaction refers to the provider that
`
`sent the transaction request,” that argument is conclusory, and unsupported even by
`
`USR’s own expert. POR, 19-20. Likewise, USR’s argument based on the
`
`language “the entity on whose behalf a transaction is to be performed” does not
`
`require the transaction request itself to originate with the merchant. Id. The secure
`
`registry can still conduct a transaction on an entity’s behalf even where that entity
`
`itself requested the transaction. Ex-1135, Shoup-Decl., ¶44.
`
`Second, the ’539 specification further undermines USR’s construction. As a
`
`threshold matter, the term “transaction request” does not appear anywhere in the
`
`’539 specification. Additionally, in Figures 7-10, the user (i.e., the entity)
`
`“initiates” a financial transaction by sending a one-time code to a merchant, who
`
`then passes information given to it by the user, on to the secure registry. See, e.g.,
`
`Ex-1101, 539 patent, 11:51-57 (“[W]hen a user initiates a purchase … the
`
`merchant [subsequently] transmits to the credit card company….”); Fig. 7 (“User
`
`Initiates Purchase”). Because the specification does not identify which party
`
`generates the “transaction request,” there is no bas
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
