Paper No. __
`
`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-00811
`U.S. Patent No. 8,856,539
`________________
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`PURSUANT TO 35 U.S.C. § 313 AND 37 C.F.R. § 42.107
`
`

`

`TABLE OF CONTENTS
`
`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`Page
`
`I.
`II.
`
`IV.
`V.
`
`VI.
`
`INTRODUCTION ........................................................................................... 1
`OVERVIEW OF THE ’539 PATENT ............................................................ 6
`A.
`The ’539 Patent Specification ............................................................... 6
`B.
`The ’539 Patent Claims ....................................................................... 12
`C.
`Prosecution History of the ’539 Patent ............................................... 16
`III. OVERVIEW OF THE ASSERTED PRIOR ART REFERENCE
`SCHUTZER ................................................................................................... 16
`LEVEL OF ORDINARY SKILL IN THE ART ........................................... 20
`CLAIM CONSTRUCTION .......................................................................... 21
`A.
`“Third Party” (All Challenged Claims) ............................................... 21
`THE PETITION FAILS TO DEMONSTRATE A REASONABLE
`LIKELIHOOD THAT ANY CLAIM IS INVALID BASED ON
`SCHUTZER (GROUNDS 1 AND 2) ............................................................ 24
`A.
`Petitioner Fails To Show Any Disclosure of Receiving a
`Transaction Request Including a Time-Varying Multicharacter
`Code and an Indication of the Provider (Limitations 1[b], and
`22[a]). .................................................................................................. 27
`1.
`Time-Varying Multicharacter Code and Indication of the
`Provider are Two, Separate Items. ............................................ 27
`The Alternate Card Number Alone Fails to Necessarily
`Be an Indication of the Provider. .............................................. 30
`Petitioner Fails To Show Any Disclosure of Executing a
`Restriction Mechanism to Determine Compliance with Any
`Access Restrictions for the Provider (Limitations 1[d], 22[c][d],
`and 37[e]). ........................................................................................... 37
`1.
`Schutzer’s Paragraph [0032] Fails to Support Petitioner. ........ 40
`2.
`Schutzer’s Paragraph [0063] Fails to Support Petitioner. ........ 40
`Petitioner Fails to Show that Schutzer Discloses that Account
`Identifying Information is Provided to a Third Party to Enable
`or Deny the Transaction with the Provider Without Providing
`
`2.
`
`B.
`
`C.
`
`i
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`the Account Identifying Information to the Provider
`(Limitations 1[e], 22[e], 37[g], and 38[d]). ......................................... 44
`VII. CONCLUSION .............................................................................................. 49
`
`ii
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`TABLE OF AUTHORITIES
`
`Page
`
`CASES
`C&D Zodiac, Inc. v. B/E Aerospace, Inc.,
`Case No. IPR2014-00727 (P.T.A.B. October 29, 2014) ...............................48
`Commvault Systems, Inc. v. Realtime Data LLC,
`Case No. IPR2017-02006 (P.T.A.B. March 29, 2018) .................................48
`Cuozzo Speed Techs., LLC v. Lee,
`136 S. Ct. 2131 (2016) ...................................................................................21
`Ex parte Levy,
`17 USPQ2d 1461 (Bd. Pat. App. & Inter. 1990) ........................................... 31
`In re Oelrich,
`666 F.2d 578, 212 USPQ 323 (CCPA 1981)................................................. 33
`In re Rijckaert,
`9 F.3d 1531, 28 USPQ2d 1955 (Fed. Cir. 1993) ........................................... 33
`Merck & Co., Inc. v. Teva Pharm. USA, Inc.,
`395 F.3d 1364 (Fed.Cir.2005) ................................................................ 22, 29
`Metabolite Labs., Inc. v. Lab.Corp. of Am. Holdings,
`370 F.3d 1354, 71 USPQ2d 1081 (Fed. Cir. 2004) ....................................... 42
`Verdegaal Bros. v. Union Oil Co. of California,
`814 F.2d 628, 2 USPQ2d 1051 (Fed. Cir. 1987) .......................................... 24
`
`STATUTES
`Pre-AIA 35 U.S.C. § 102 ........................................................................................... 1
`Pre-AIA 35 U.S.C. § 103 ........................................................................................... 1
`
`RULES
`37 C.F.R. § 42.24 .....................................................................................................50
`37 C.F.R. § 42.6(e) ...................................................................................................51
`37 C.F.R. § 42.100 ................................................................................................... 21
`
`iii
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`EXHIBIT TABLE
`
`Exhibit #
`2001
`
`Description
`Declaration of Markus Jakobsson
`in Support of Patent Owner’s Preliminary Response
`
`2002
`
`2003
`
`Curriculum Vitae of Markus Jakobsson
`
`Webster’s Third New International Dictionary
`
`iv
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`I.
`
`INTRODUCTION
`
`The present petition (Paper 3, IPR2018-00811, hereinafter “Petition”) is one
`
`of three petitions filed by Apple Inc. (hereinafter “Petitioner”) challenging various
`
`claims of U.S. Patent No. 8,856,539 (hereinafter “’539 patent”). See also IPR2018-
`
`00812, CBM2018-00023. The Petition requests inter partes review of the ’539
`
`patent and relies on a single reference in its attempt to invalidate the challenged
`
`claims. See Petition at 24, 63. Specifically, the Petition asserts that claims 1-3, 5-8,
`
`16-24, 26-30, 37, and 38 are anticipated by European Patent Application 1,028,401
`
`A2 (Ex. 1030, “Schutzer”) under pre-AIA 35 U.S.C. § 102, and claims 12, 31, and
`
`34 are obvious in view of Schutzer under pre-AIA 35 U.S.C. § 103 (collectively
`
`“the Challenged Claims”). Id. Patent Owner strongly disagrees and submits this
`
`Preliminary Response to the Petition requesting that the Board deny institution of
`
`inter partes review.
`
`The ’539 patent, which issued on October 7, 2014 from U.S. application No.
`
`11/768,729 filed on June 26, 2007, was subject to a thorough and rigorous
`
`examination by Examiners Beemnet Dada and Thomas Gyorfi that lasted over four
`
`years and included seven substantive office actions. See Exs. 1005-1025. During
`
`prosecution, the Applicant and the Examiners discussed the application and prior
`
`art in detail, both through paper submissions and telephonic interviews. See Exs.
`
`1005-1024. Ultimately, Examiner Gyorfi allowed the claims of the ’539 patent
`
`1
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`(Ex. 1025 at 5; Ex. 1028 at 5.) over a large body of cited prior art. See Ex. 1001 at
`
`1-3.
`
`The Board should not institute inter partes review of the ’539 patent because
`
`the Petition fails to demonstrate that there is a reasonable likelihood that at least
`
`one of the claims challenged in the Petition is unpatentable. Notwithstanding
`
`deficiencies in the Petition that are unique to the dependent claims, the Petition
`
`fails to show that each and every claim limitation found in independent claims 1,
`
`22, 37, and 38 is disclosed by Schutzer.
`
`First, regarding independent claims 1 and 22, claim limitations 1[b]1 and
`
`22[a] specify that the secure registry2 receives a “transaction request” that includes
`
`at least two distinct components: a “time-varying, multicharacter code” and “an
`
`indication of the provider requesting the transaction.” Ex. 1001 at 18:39-42; 20:9-
`
`12. The Petition, however, fails to identify two distinct components included in
`
`Schutzer’s authorization request and instead ballyhoos the notion that a single
`
`1 Patent Owner’s Preliminary Response adopts the limitation numbering
`
`format (e.g., “limitation 1[a]) used by Petitioner in its Petition.
`
`2 The term “secure registry” is used throughout this Preliminary Response
`
`to denote the “secure registry system” found in claims 1, 37, and 38 and also the
`
`“secure registry” found in claim 22.
`
`2
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`value—the alternate card number—inherently doubles as both the time-varying
`
`multicharacter code and the indication of the provider requesting the transaction.
`
`See Petition at 32, 50. Such an interpretation is improper not only because it
`
`ignores the fact that the claims recite two distinct values and not one, but also
`
`because the alternate card number fails to identify the provider requesting the
`
`transaction in every case (i.e., inherency argument fails). Ex. 2001, Jakobsson at
`
`¶¶44-45. For example, the Petition submits that the issuing bank must inherently
`
`receive an indication of the provider requesting the transaction because the
`
`authorization it sends is ultimately delivered to the merchant provider. See Petition
`
`at 33. This argument fails because the issuing bank sends the authorization not to
`
`the merchant provider, but instead to the merchant acquiring bank. The fact that the
`
`merchant acquiring bank then sends an authorization to the merchant provider does
`
`not necessarily mean that the issuing bank must know the identity of the
`
`underlying merchant provider when it sends the authorization to the acquiring bank
`
`or that it received an indication of the merchant provider when it received the
`
`transaction request. Ex. 2001, Jakobsson at ¶¶49-50. Moreover, Petitioner’s
`
`argument that the alternate card number “expressly contains an indication of who
`
`the merchant is” since the alternate card number can be used for purchase
`
`transaction tracking also fails because (a) Schutzer describes cases where receipt of
`
`the alternate card number at the secure registry would not necessarily allow the
`
`3
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`secure registry to track the merchant and (b) the alternate card number by itself
`
`cannot positively identify the merchant that actually sent the alternate card number.
`
`Consequently, Petitioner’s arguments as to this limitation, which depend on
`
`inherency, fail to establish that receipt of an indication of the provider necessarily
`
`flows from receipt of the alternate card number at the issuing bank.
`
`Second, as to independent claims 1, 22, and 37, Schutzer fails to disclose
`
`claim limitations 1[d], 22[c][d]3, and 37[e]. Limitation 37[e] specifies that a
`
`restriction mechanism is executed to determine compliance with access restrictions
`
`for a provider to secure data for completing the transaction. Id. at 22:1-4.
`
`Limitations 1[d] and 22[c][d] further specify that compliance is determined based
`
`on a time-varying multicharacter code and an indication of the provider. Ex. 1001
`
`at 18:45-50; 20:16-20. Access to the secure data is then allowed or denied based on
`
`the determined compliance of the access restrictions. Id. at 18:50-54; 20:21-24.
`
`Petitioner argues that these claim limitations are disclosed by Schutzer’s brief
`
`discussion that the issuing bank is able to track which purchases were made over
`
`which channels and with which merchants, and how such information can be used
`
`for fraud management. Petition at 36, 58-59. However, Schutzer does not elaborate
`
`3 Patent Owner uses value 22[c][d] to refer to the combination of
`
`limitations 22[c] and 22[d] identified by the Petition.
`
`4
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`on how such information is used to prevent fraud or what type of fraud is managed.
`
`Moreover, Schutzer’s passing reference regarding fraud management and merchant
`
`tracking does not disclose or teach that the issuing bank determines compliance
`
`with access restrictions for a provider to secure data or that such compliance
`
`determination is based on a time-varying multicharacter code and indication of a
`
`provider. Ex. 2001, Jakobsson at ¶¶62-65.
`
`Third, regarding all four independent claims 1, 22, 37, and 38, Schutzer
`
`fails to disclose claim limitations 1[e], 22[e], 37[g], and 38[d]. These limitations
`
`specify that the secure registry provides the account identifying information to a
`
`third party without providing the account identifying information to the provider.
`
`Ex. 1001 at 18:54-60; 20:25-28; 22:8-13; 22:31-36. By contrast, Schutzer’s issuing
`
`bank never sends account identifying information to a third party and instead keeps
`
`such information internal to itself. See Ex. 1030, Schutzer at [0027]; Ex. 2001,
`
`Jakobsson at ¶69. In an attempt to overcome this deficiency, the Petition argues
`
`that the issuing bank is itself the third party. Petition at 37. In effect, the Petition
`
`argues that the “secure registry” and the “third party” recited in the claims are in
`
`fact one and the same entity. Ergo when the secure registry provides the account
`
`identifying information to a third party, the secure registry really just provides the
`
`account identifying information back to itself. Such an interpretation runs counter
`
`to the correct claim construction of the term “third party” (See discussion infra Part
`
`5
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`V.A) and provides the bizarre result of the secure registry sending itself the
`
`account identifying information that it already has possession of. Ex. 2001,
`
`Jakobsson at ¶71. Petitioner’s failure to establish that Schutzer discloses this
`
`limitation, which is found in all of the independent claims, proves fatal.
`
`Since the Petition has failed to show that each and every claim limitation in
`
`the independent claims is disclosed by Schutzer, the Petition fails to demonstrate
`
`that there is a reasonable likelihood that at least one of the claims challenged in the
`
`Petition is unpatentable. As such, Patent Owner respectfully requests that the
`
`Board deny institution of inter partes review.
`
`II. OVERVIEW OF THE ’539 PATENT
`
`A.
`
`The ’539 Patent Specification
`
`The ’539 patent provides a unique and highly secure anonymous identification
`
`system that uses a time-varying multicharacter code for both verifying the identity
`
`of an entity and also enabling transactions between the entity and a provider without
`
`requiring the entity to share personal or otherwise sensitive information with the
`
`provider. See Ex. 1001 at 2:64-3:1, 3:24-27, 12:19-54; Ex. 2001, Jakobsson at ¶23.
`
`As one non-exclusive example, the system, referred to as a Universal Secure
`
`Registry (USR) system, allows a person to purchase goods from a brick and mortar
`
`or online merchant without publicly providing credit card information to the
`
`6
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`merchant for fear that the credit card information may be stolen or used fraudulently.
`
`See Ex. 1001 at 3:44-54; Ex. 2001, Jakobsson at ¶23. As another example, the USR
`
`system may be used by a patient to supply “insurance data, medical history data, and
`
`other appropriate medical information to a medical provider, once that medical
`
`provider has been established as an authorized recipient [of such data].” See Ex.
`
`1001 at 3:55-60; Ex. 2001, Jakobsson at ¶23.
`
`FIG. 1 depicts one possible embodiment of the USR system:
`
`7
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`The USR system’s main unit 12, which may be connected to a wide area network,
`
`includes a database 24 that stores data entries 30 related to different people or
`
`entities. Ex. 1001 at 7:11-13; 7:40-41; Ex. 2001, Jakobsson at ¶24. Each entry 30
`
`may contain different types of information such as, but not limited to, validation
`
`information, access
`
`information, publicly available
`
`information, address
`
`8
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`information, credit card information, medical information, job application
`
`information, and/or tax information. Ex. 1001 at 7:57-63; Ex. 2001, Jakobsson at
`
`¶24. “The validation information [32] is information about the user of the database
`
`to whom the data pertains and is to be used by the USR software 18 to validate that
`
`the person attempting to access the information is the person to whom the data
`
`pertains or is otherwise authorized to receive it.” Ex. 1001 at 8:10-14; Ex. 2001,
`
`Jakobsson at ¶24. In particular, the validation information 32 contains information
`
`that enables the USR software 18 to validate a person that has presented the system
`
`with a one-time nonpredictable code uniquely associated with the user. See Ex. 1001
`
`at 8:17-35; Ex. 2001, Jakobsson at ¶24. The access information 34 allows “different
`
`levels of security to attach to different types of information stored in the entry 30”
`
`so that the user can specify which particular individuals or companies can have
`
`access to what specific data such as credit card numbers, medical information, and
`
`tax information. See Ex. 1001 at 8:62-9:11; Ex. 2001, Jakobsson at ¶24.
`
`FIG. 8 depicts one possible embodiment of using the USR system “to
`
`purchase goods or services from a merchant without revealing to the merchant
`
`account information relating to the person’s bank or credit card.” Ex. 1001 at 9:46-
`
`50; Ex. 2001, Jakobsson at ¶25.
`
`9
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`A user desiring to make a purchase at a merchant without providing their financial
`
`information, such as a credit or debit card number, may enter a secret code into their
`
`electronic ID device (any type of electronic device that may be used to obtain access
`
`10
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`to the USR database (Ex. 1001 at 8:45-47)), which generates a one-time
`
`nonpredictable code that is provided to the merchant. Id. at 12:21-24; Ex. 2001,
`
`Jakobsson at ¶25. The merchant in turn may transmit the one-time nonpredictable
`
`code, a store number, and a purchase amount to the USR. Ex. 1001 at 12:24-26; Ex.
`
`2001, Jakobsson at ¶25. The USR may then determine whether the code received is
`
`valid, and if valid, accesses from the USR database the user’s actual credit card
`
`information. Ex. 1001 at 12:27-29; Ex. 2001, Jakobsson at ¶25. The USR next
`
`transmits to the credit card company the credit card number, the store number, and
`
`the purchase amount. Ex. 1001 at 12:29-31; Ex. 2001, Jakobsson at ¶25. The credit
`
`card company then processes the transaction, such as by checking the credit
`
`worthiness of the person, and either declines the card or debits the user’s account
`
`and transfers money to the merchant’s account. Ex. 1001 at 12:40-43; Ex. 2001,
`
`Jakobsson at ¶25. The credit card company notifies the USR the transaction result
`
`and the USR may in turn notify the merchant. Ex. 1001 at 12:43-46; Ex. 2001,
`
`Jakobsson at ¶25.
`
`Hence, the USR system provides a secure anonymous identification system
`
`that uses a time-varying multicharacter code for both verifying the identity of an
`
`entity and also enabling transactions between the entity and a provider, such as a
`
`merchant, without requiring the entity to share personal or otherwise sensitive
`
`information with the provider. Ex. 2001, Jakobsson at ¶26. In one case, this allows
`
`11
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`a user to purchase goods or services from a merchant without providing the
`
`merchant the user’s credit card number. Id. Advantageously, the USR system also
`
`allows such secure transactions to be transparent to the credit card company and
`
`thus requires no or minimal cooperation from the credit card company to
`
`implement. Id. As another example, a user may obtain medical treatment from a
`
`medical care provider without having to directly supply the medical care provider
`
`her medical history, which may not be with the patient herself. Id. at ¶27. In yet
`
`another example, the user may facilitate shipment of goods purchased from a
`
`merchant without having to provide the merchant their shipping address. Id.
`
`B.
`
`The ’539 Patent Claims
`
`The ’539 patent includes 38 claims, of which claims 1, 22, 37, and 38 are
`
`independent. The four independent claims of the ’539 patent are reproduced below:
`
`A secure registry system for providing information to a
`1.
`provider to enable transactions between the provider and entities with secure
`data stored in the secure registry system, the secure registry system
`comprising:
`a database including secure data for each entity, wherein each entity is
`associated with a time-varying multicharacter code for each entity having
`secure data in the secure registry system, respectively, each time-varying
`multicharacter code representing an identity of one of the respective entities;
`and
`
`a processor configured to receive a transaction request including at
`least the time-varying multicharacter code for the entity on whose behalf a
`
`12
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`transaction is to be performed and an indication of the provider requesting
`the transaction, to map the time-varying multicharacter code to the identity
`of the entity using the time-varying multicharacter code, to execute a
`restriction mechanism to determine compliance with any access restrictions
`for the provider to secure data of the entity for completing the transaction
`based at least in part on the indication of the provider and the time-varying
`multicharacter code of the transaction request, and to allow or not allow
`access to the secure data associated with the entity including information
`required to enable the transaction based on the determined compliance with
`any access restrictions for the provider, the information including account
`identifying information, wherein the account identifying information is not
`provided to the provider and the account identifying information is provided
`to a third party to enable or deny the transaction with the provider without
`providing the account identifying information to the provider.
`
`Ex. 1001 at 18:29-60.
`
`22. A method for providing information to a provider to enable
`transactions between the provider and entities who have secure data stored in
`a secure registry in which each entity is identified by a time-varying
`multicharacter code, the method comprising:
`receiving a transaction request including at least the time-varying
`multicharacter code for an entity on whose behalf a transaction is to take
`place and an indication of the provider requesting the transaction;
`mapping the time-varying multicharacter code to an identity of the
`entity using the time-varying multicharacter code;
`determining compliance with any access restrictions for the provider
`to secure data of the entity for completing the transaction based at least in
`
`13
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`part on the indication of the provider and the time-varying multicharacter
`code of the transaction request;
`accessing information of the entity required to perform the transaction
`based on the determined compliance with any access restrictions for the
`provider, the information including account identifying information;
`providing the account identifying information to a third party without
`providing the account identifying information to the provider to enable or
`deny the transaction; and
`enabling or denying the provider to perform the transaction without
`the provider's knowledge of the account identifying information.
`
`Id. at 20:4-31.
`
`37. A secure registry system for providing information to a
`provider to enable transactions between the provider and entities with secure
`data stored in the secure registry system, the secure registry system
`comprising:
`a database including secure data for each entity, wherein each entity is
`associated with a time-varying multicharacter code for each entity having
`secure data in the secure registry system, respectively, each time-varying
`multicharacter code representing an identity of one of the respective entities,
`wherein the database is configured to permit or deny access to information
`on the respective entity using the time-varying multicharacter code; and
`a processor configured to receive the time-varying multicharacter
`code for the entity on whose behalf a transaction is to be performed,
`configured to map the time-varying multicharacter code to the identity of the
`entity to identify the entity, configured to execute a restriction mechanism to
`determine compliance with any access restrictions for the provider to at least
`
`14
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`one portion of secure data for completing the transaction and to store an
`appropriate code with each such portion of secure data, configured to obtain
`from the database the secure data associated with the entity including
`information required to enable the transaction, the information including
`account identifying information, and configured to provide the account
`identifying information to a third party to enable or deny the transaction
`without providing the account identifying information to the provider.
`
`Id. at 21:25-22:13.
`
`38. A secure registry system for providing information to a
`provider to enable transactions between the provider and entities with secure
`data stored in the secure registry system, the secure registry system
`comprising:
`a database including secure data for each entity, wherein each entity is
`associated with a time-varying multicharacter code for each entity having
`secure data in the secure registry system, respectively, each time-varying
`multicharacter code representing an identity of one of the respective entities;
`and
`
`a processor configured to receive the time-varying multicharacter
`code for the entity on whose behalf a transaction is to be performed,
`configured to map the time-varying multicharacter code to the identity of the
`entity without requiring further information to identify the entity, configured
`to access from the database secure data associated with the entity including
`information required to enable the transaction, the information including
`account identifying information, and configured to provide the account
`identifying information to a third party to enable or deny the transaction
`without providing the account identifying information to the provider, and
`
`15
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`wherein enabling or denying the transaction without providing account
`identifying information to the provider includes limiting transaction
`information provided by the secure registry system to the provider to
`transaction approval information.
`
`Id. at 22:14-22:40.
`
`C.
`
`Prosecution History of the ’539 Patent
`
`The ’539 patent issued on October 7, 2014 from U.S. Application
`
`No. 11/768,729 (“’729 Application”) filed on June 26, 2007. The ’729 Application
`
`is a continuation application of U.S. Application No. 09/810,703 filed on March
`
`16, 2001, now U.S. Patent No. 7,237,117.
`
`The ’539 patent was subject to a thorough examination by Examiners
`
`Beemnet Dada and Thomas Gyorfi. See Exs. 1005-1025. During prosecution, the
`
`Applicant and the Examiners discussed the application and prior art in detail, both
`
`through paper submissions and telephonic interviews. See Exs. 1005-1024. Claim
`
`amendments were made to further distinguish the invention from the prior art.
`
`Ultimately, Examiner Gyorfi allowed the claims of the ’539 patent (Ex. 1025 at 5;
`
`Ex. 1028 at 5.) over a large body of cited prior art. See Ex. 1001 at 1-3.
`
`III. OVERVIEW OF THE ASSERTED PRIOR ART REFERENCE
`SCHUTZER
`
`Schutzer discusses “a method and system for securely performing a
`
`bankcard transaction utilizing an anonymous or alternate card number.” Ex. 1030,
`
`16
`
`

`

`Schutzer at [0002]. FIG. 1 of Schutzer shown below is instructive of this method
`
`and system.
`
`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`Referring to FIG. 1 of Schutzer above, a user 2 desiring to make an online
`
`purchase at a merchant 4, first sends a request to her financial card’s (e.g., credit
`
`card) issuing bank 8 requesting an anonymous, alternate card number that she can
`
`use to make her purchase. See, e.g., id. at [0025], [0026]; Ex. 2001, Jakobsson at
`
`¶30. The issuing bank 8 authenticates the user and sends the user 2 the alternate
`
`card number linked to the user’s actual card number, which the user 2 then
`
`17
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`forwards to the merchant 4 (e.g., merchant server 12). See Ex. 1030, Schutzer at
`
`[0026]; Ex. 2001, Jakobsson at ¶30. Alternatively, the user 2 can instruct the
`
`issuing bank 8 to send the alternate card number directly to the merchant 4. See Ex.
`
`1030, Schutzer at [0028]; Ex. 2001, Jakobsson at ¶30. In yet another embodiment,
`
`the issuing bank 8 may install software at the user’s computing device 10 that can
`
`generate the alternate card number for the user 2 after the user 2 authenticates
`
`herself with the software. See Ex. 1030, Schutzer at [0030]; Ex. 2001, Jakobsson at
`
`¶30. After obtaining the alternate card number the user 2 sends the alternate card
`
`number to the merchant 4. See Ex. 1030, Schutzer at [0031]; Ex. 2001, Jakobsson
`
`at ¶30.
`
`After receiving the alternate card number, the merchant 4 sends the alternate
`
`card number to the merchant (acquiring) bank 6 (e.g., merchant acquiring bank
`
`server 18) requesting authorization. See, e.g., Ex. 1030, Schutzer at [0027], [0031];
`
`Ex. 2001, Jakobsson at ¶31. Notably, Schutzer does not disclose that the merchant
`
`4 sends anything but the alternate card number to the acquiring bank 6 with its
`
`authorization request. The acquiring bank 6 then sends an authorization request to
`
`the issuing bank 8 (e.g., issuing bank server 14) over a card association network
`
`20. See Ex. 1030, Schutzer at [0027], [0032]; Ex. 2001, Jakobsson at ¶31. The
`
`issuing bank server 14 (e.g., server’s authorization processor 26) receives the
`
`request, links the alternate card number to the user’s actual account for
`
`18
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`authorization, and then sends an authorization for the alternate card number to the
`
`merchant acquiring bank’s server 18 over the card association network 20. Ex.
`
`1030, Schutzer at [0027]; Ex. 2001, Jakobsson at ¶31. In the case where the
`
`alternate card number was generated by software at the user’s computing device
`
`10, the issuing bank server’s number generator 24 generates the next number in
`
`sequence synchronized to the cardholder's software 30 and links the alternate card
`
`number to the actual card number before providing the actual card number to the
`
`authorization processor 26 for authorization processing. See Ex. 1030, Schutzer at
`
`[0032]; Ex. 2001, Jakobsson at ¶31.
`
`The issuing bank 8 (e.g., issuing bank server’s authorization processor 26)
`
`then sends the authorization to the merchant acquiring bank 6 (e.g., merchant
`
`acquiring bank server 18) over the card association network 20. Ex. 1030, Schutzer
`
`at [0027], [0032]; Ex. 2001, Jakobsson at ¶32. Notably, the issuing bank 8 does not
`
`send the authorization directly to the merchant 4. The acquiring bank’s server 18 in
`
`turn sends the authorization for the transaction to the merchant 4 (e.g., merchant’s
`
`server 12), which then completes the transaction with the user 2. Id.
`
`Schutzer also discusses how the alternate card number is generated on a per
`
`transaction basis, and as such, it can be used by the issuing bank 8 to “keep track of
`
`where (over what channel) and to whom (what merchant number was used).” Ex.
`
`1030, Schutzer at [0063]; Ex. 2001, Jakobsson at ¶33. For example, if the alternate
`
`19
`
`

`

`Case No. IPR2018-00811
`U.S. Patent No. 8,856,539
`
`number was requested at the user’s electronic wallet 28, and supplied to the
`
`merchant 4 over the internet, “then the issuing bank 8 can identify and keep track
`
`of which purchases were made over the Internet and with which merchants.” Id.
`
`IV. LEVEL OF ORDINARY SKILL IN THE ART
`
`A person of ordinary skill in the art (“POSITA”) relevant to the ’539 patent
`
`at the time of the invention would have a Bachelor of Science degree in electrical
`
`engineering and/or computer science, and three years of work or research
`
`experience in the fields of secure transactions and encryption, or a Master’s degree
`
`in electrical engineering and/or computer science and two years of work or
`
`research experience in related fields. Ex