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
`_________________________________________
`
`DECLARATION OF DR. VICTOR SHOUP IN SUPPORT OF
`PETITIONER’S REPLY TO PATENT OWNER RESPONSE
`
`Apple 1135
`Apple v. USR
`IPR2018-00812
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`TABLE OF CONTENTS
`
`Page
`Contents
`I.
`Introduction ...........................................................................................1
`II. Legal Principles......................................................................................2
`A. Claim Construction............................................................................2
`B. Obviousness......................................................................................2
`C.
`Subject Matter Eligibility....................................................................5
`III. Argument ............................................................................................6
`A. My Prior Declaration Shows That The Challenged Claims Are Obvious....6
`1. My Declaration Shows That Reber And Franklin Both Disclose The
`“Wherein The Account Identifying Information Is Not Provided To The
`Provider ….”..........................................................................................6
`2. My Prior Declaration Shows That Reber And Franklin Both Disclose The
`“Access Restrictions For The Provider To [Secure Data / At Least One Portion
`of Secure Data].”.................................................................................. 11
`3. My Prior Declaration Shows That Reber And Franklin Both Disclose The
`“Third Party” Limitation........................................................................ 17
`4. My Prior Declaration Shows That Reber And Franklin Both Disclose The
`“Receive a Transaction Request” Limitations Of Claims 1 And 22.............. 22
`5. My Prior Declaration Shows That Reber And Franklin Both Disclose
`Claims 3 And 24................................................................................... 26
`IV. Conclusion ........................................................................................ 28
`V. Availability For Cross-Examination ........................................................ 28
`VI. Right to Supplement ........................................................................... 28
`VII. Jurat.................................................................................................. 29
`
`ii
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`I, Victor Shoup, Ph.D., declare as follows:
`I.
`Introduction
`1.
`I have been retained by Apple to provide opinions in this proceeding
`
`relating to U.S. Patent No. 8,856,539 (“’539 patent”). I submit this Declaration to
`
`address and respond to the arguments made in Patent Owner’s Response and the
`
`declaration submitted by Dr. Jakobsson in support of the Patent Owner’s Response.
`
`2. My background and qualifications are summarized in my previous
`
`declaration (Ex-1102, Shoup-Decl.) and my curriculum vitae is attached thereto as
`
`Appendix A. Since preparing my Declaration, I have reviewed the following
`
`additional materials:
`
`(cid:120) The Board’s Decision on Institution (“DOI”)
`
`(cid:120) USR’s Patent Owner Preliminary Response (“POPR”)
`
`(cid:120) USR’s Patent Owner Response (“POR”)
`
`(cid:120) Dr. Jakobsson’s Declaration in Support of USR’s POPR (Ex. 2101)
`
`(cid:120) Dr. Jakobsson’s Declaration in Support of USR’s POR (Ex. 2108)
`
`(cid:120) USR’s Conditional Motion to Amend (“CMTA”)
`
`(cid:120) Dr. Jakobsson’s Declaration in Support of USR’s CMTA (Ex. 2107)
`
`(cid:120) The transcript of Dr. Jakobsson’s April 24, 2019 deposition (Ex.
`
`1137)
`
`3.
`
`I am being compensated at my normal consulting rate for my work.
`
`1
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`My compensation is not dependent on the outcome of this IPR proceeding or the
`
`related litigation, and does not affect the substance of my statements in this
`
`Declaration.
`
`4.
`
`I have no financial interest in Petitioner. I have no financial interest in
`
`the ’539 patent.
`
`II.
`
`Legal Principles
`5.
`I am not an attorney. For purposes of this Declaration, I have been
`
`informed about certain aspects of the law that are relevant to my analysis and
`
`opinions.
`
`A.
`6.
`
`Claim Construction
`I have been informed that claim construction is a matter of law and
`
`that the final claim construction will be determined by the Board.
`
`7.
`
`I have been informed that the claim terms in an IPR review should be
`
`given their broadest reasonable construction in light of the specification as
`
`commonly understood by a person of ordinary skill in the art (“POSITA”). I have
`
`applied this standard in my analysis.
`
`B.
`8.
`
`Obviousness
`I have been informed and understand that a patent claim can be
`
`considered to have been obvious to a POSITAat the time the application was filed.
`
`This means that, even if all the requirements of a claim are not found in a single
`
`prior art reference, the claim is not patentable if the differences between the subject
`2
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`matter in the prior art and the subject matter in the claim would have been obvious
`
`to a POSITAat the time the application was filed.
`
`9.
`
`I have been informed and understand that a determination of whether
`
`a claim would have been obvious should be based upon several factors, including,
`
`among others:
`
`(cid:120) the level of ordinary skill in the art at the time the application was
`
`filed;
`
`(cid:120) the scope and content of the prior art; and
`
`(cid:120) what differences, if any, existed between the claimed invention and
`
`the prior art.
`
`10.
`
`I have been informed and understand that the teachings of two or
`
`more references may be combined in the same way as disclosed in the claims, if
`
`such a combination would have been obvious to a POSITA. In determining
`
`whether a combination based on either a single reference or multiple references
`
`would have been obvious, it is appropriate to consider, among other factors:
`
`(cid:120) whether the teachings of the prior art references disclose known
`
`concepts combined in familiar ways, and when combined, would yield
`
`predictable results;
`
`(cid:120) whether a POSITA could implement a predictable variation, and
`
`would see the benefit of doing so;
`
`3
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`(cid:120) whether the claimed elements represent one of a limited number of
`
`known design choices, and would have a reasonable expectation of
`
`success by those skilled in the art;
`
`(cid:120) whether a POSITA would have recognized a reason to combine
`
`known elements in the manner described in the claim;
`
`(cid:120) whether the proposed modification would have a reasonable
`
`expectation of success by those skilled in the art;
`
`(cid:120) whether there is some teaching or suggestion in the prior art to make
`
`the modification or combination of elements claimed in the patent;
`
`and
`
`(cid:120) whether the innovation applies a known technique that had been used
`
`to improve a similar device or method in a similar way.
`
`11.
`
`I have been informed and understand that a POSITA has ordinary
`
`creativity, and is not an automaton.
`
`12.
`
`I have been informed and understand that in considering obviousness,
`
`it is important not to determine obviousness using the benefit of hindsight derived
`
`from the patent being considered.
`
`13.
`
`I have also been informed that objective evidence is also relevant to
`
`the question of obviousness. I understand that such evidence, which is sometimes
`
`referred to as “secondary considerations,” can include evidence of commercial
`
`4
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`success, long-felt but unsolved needs, failure of others, copying by others, and
`
`unexpected results. I also understand that when considering the strength of
`
`secondary considerations, weight is not given unless a nexus is established
`
`between the rebuttal evidence and the claimed invention. In other words,
`
`secondary considerations only carry weight when the secondary considerations are
`
`attributable to the claimed invention.
`
`C.
`14.
`
`Subject Matter Eligibility
`I have been informed that laws of nature, abstract ideas, and natural
`
`phenomena are not patent eligible.
`
`15.
`
`I have been informed that an application of an abstract idea, such as a
`
`mathematical formula, may be patent eligible if the patent claims add significantly
`
`more than routine, conventional activity to the underlying concept.
`
`16.
`
`I have been informed that an important and useful clue to patent
`
`eligibility is whether a claim is tied to a particular machine or apparatus or
`
`transforms a particular article into a different state or thing, according to the so
`
`called machine-or-transformation test. I have been informed that the machine-or-
`
`transformation test is not the only test for patent eligibility.
`
`17.
`
`I have been informed that the Supreme Court’s decision in the Alice
`
`Corp. case in 2014 articulates a two-step framework for distinguishing patents that
`
`claim ineligible abstract ideas from those that claim eligible applications of those
`
`5
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`ideas. In step one, the court must determine whether the claims at issue are
`
`directed to a patent-ineligible abstract concept. If the claim is directed to an
`
`abstract idea, the analysis proceeds to step two. In step two, I understand that the
`
`elements of the claim must be searched, both individually and as an ordered
`
`combination, for an inventive concept—i.e., an element or combination of
`
`elements that is sufficient to ensure that the patent in practice amounts to
`
`significantly more than a patent upon the ineligible concept itself. I am informed
`
`that a patentee cannot circumvent the prohibition on patenting abstract ideas by
`
`limiting the idea to a particular technological environment, nor by adding
`
`insignificant postsolution activity, or well-understood, routine, conventional
`
`features.
`
`III. Argument
`A. My Prior Declaration Shows That The Challenged Claims Are
`Obvious.
`1. My Declaration Shows That Reber And Franklin Both
`Disclose The “Wherein The Account Identifying
`Information Is Not Provided To The Provider ….”
`18. As my prior declaration demonstrated, Reber and Franklin disclose
`
`that “the account identifying information is not provided to the provider”
`
`limitations of claims 1, 22, 37, and 38. See Ex-1102, Shoup-Decl., ¶¶80-125, 167-
`
`172, 183-206. In response, USR reiterates its POPR argument that the Petition
`
`fails to adequately map the “account identifying information is not provided to the
`
`6
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`provider.” POR, 27-35. Reber and Franklin disclose this limitation because both
`
`references teach that account identifying information (such as names, addresses,
`
`and account numbers) should not be provided to the provider when such
`
`information is deemed sensitive. Ex-1102, Shoup-Decl., ¶¶80-87, 119-25.
`
`a)
`
`USR’s Argument Fails to Apply the Broadest Reasonable
`Interpretation of “Account Identifying Information.”
`19. 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.
`
`20.
`
`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 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
`
`7
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`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.”)1. 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.
`
`21.
`
`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. Ex-1102,
`
`Shoup-Decl., ¶¶163-165; Ex-1137, Jakobsson-Dep., 468:2-11. For instance, Reber
`
`1 Emphasis added unless otherwise specified.
`
`8
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`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.
`
`b)
`
`Even Under USR’s Flawed Interpretation, The Account
`Identifying Information Limitation Is Obvious.
`22. 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 Ex-1102, Shoup-Decl., ¶¶88-99. Reber does
`
`not suggest that the user’s actual name or address are provided as part of a
`
`transaction. (Ex-1131, Reber, 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
`
`9
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`(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.
`
`23.
`
`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).
`
`24.
`
`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
`
`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
`
`10
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`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.
`
`25.
`
`In view of these teachings, Reber and Franklin each render obvious
`
`the “wherein the account identifying information is not provided to the provider”
`
`limitation.
`
`2. My Prior Declaration Shows That Reber And Franklin
`Both Disclose The “Access Restrictions For The Provider
`To [Secure Data / At Least One Portion of Secure Data].”
`26. Reber and Franklin render obvious the “access restrictions”
`
`limitations of claims 1, 22, 37, and 38. As explained below and in my prior
`
`declaration, 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. Ex-1102, Shoup-Decl., ¶¶112-118.
`
`a)
`
`USR’s Proposed Claim Construction of “Access
`Restrictions For the Provider” Is Unsupported.
`
`11
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`27. USR’s proposed construction of “access restrictions for the provider”
`
`is inconsistent with the intrinsic evidence. USR’s construction is incorrect.
`
`28. 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. I disagree.
`
`29.
`
`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.
`
`30. 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
`
`12
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`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
`
`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 [required] information and the
`
`access information 34 provided by the person to the USR database” (POR, 23)
`
`(emphasis omitted), 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.
`
`31. USR suggests that “access restrictions” requires “two or more” such
`
`restrictions. 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
`
`13
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`“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).”).
`
`b)
`
`Even Under USR’s Proposed Construction, The “Access
`Restrictions” Limitation is Obvious.
`Even under its incorrect construction, USR’s arguments still fail to
`
`32.
`
`rebut Apple’s showing that the “access restrictions” limitation would have been
`
`obvious.
`
`33. USR’s argument that Reber does not disclose any access restrictions
`
`(POR, 35-39) 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).
`
`34. Contrary to USR’s assertion (POR, 40-41), a POSITA would have
`
`understood that Franklin’s discussion of “merchant validation” (Ex-1132, Franklin,
`
`14
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`11:38-47) would have encompassed the claimed “compliance with any access
`
`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.
`
`35. 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
`
`POSITAwould 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
`
`15
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`issuing bank, depending on the needs of a particular implementation (for example,
`
`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).
`
`36. 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 my prior declaration explains, no combination is necessary because
`
`Reber itself renders this limitation obvious as set forth above. Ex-1102, Shoup-
`
`Decl., ¶¶112-18. With respect to the Reber-Franklin combination, my declaration
`
`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 validating a merchant before allowing it to access the
`
`16
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`database to complete a transaction. 2 Id.
`
`3. My Prior Declaration Shows That Reber And Franklin
`Both Disclose The “Third Party” Limitation.
`37. 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. Ex-1102, Shoup-Decl.,
`
`¶¶119-25.
`
`38.
`
`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
`
`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
`
`2 USR also argues that I failed to consider whether the ’539 patent was an
`
`improvement over Reber. POR at 43-44. But I understand 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 what I did in my prior declaration (Ex-1102, Shoup-Decl., ¶¶19,
`
`114) and explained at my deposition. Ex-2111, Shoup-Dep., 28:7-29:22, 35:14-22.
`
`17
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`transaction itself. 3 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
`
`party); see also, Ex-1101, ’539 patent, 12:19-46, Fig. 8.
`
`39.
`
`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
`
`3 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).
`
`18
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`(…“[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.”).
`
`40.
`
`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 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.).”).
`
`19
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`Ex-1131, Reber, Fig. 1 (annotated per Reber, 6:26-29.)
`
`20
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`Ex-1132, Franklin, Fig. 7 (annotated)
`
`41. 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
`
`21
`
`

`

`U.S. Patent No. 8,856,539
`Declaration in Support of Petitioner’s Reply
`
`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.
`
`4. My Prior Declaration Shows That Reber And Franklin
`Both Disclose The “Receive a Transaction Request”
`Limitations Of Claims 1 And 22.
`42. Reber and Franklin render obvious a “provider requesting a
`
`transaction” because they disclose instances where a tran