Chart B-4
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Fintiv, Inc. v. Apple Inc., Case No. 1:19-CV-1238-ADA (W.D. Tex.)
`
`Synchronizing the Mobile Wallet Application with the TSM
`
`CLAIM LIMITATIONS: “synchronizing the mobile wallet application with the TSM system” (’125 patent claim 11) and “wherein synchronizing the
`mobile wallet application with the TSM system comprises: checking for a change made to a configuration of the mobile wallet application; and
`transmitting the change to the TSM system” (’125 patent claim 13).
`
`ASSERTED CLAIMS: These limitations are present in the following asserted claims: ’125 patent claims 11 (and its dependent claims).
`
`DISCLOSURE/MOTIVATION TO COMBINE: Under Fintiv’s interpretation of these claim limitations, synchronizing a mobile wallet application with a
`TSM was well-known at the time of the alleged inventions of the asserted claims. 1
`
`Synchronization technologies and techniques were quite mature by the time of the alleged invention and would have been well-known to POSITAs,
`as evidenced by the references herein. The ’125 patent specification discusses synchronization only as a general matter, stating that “[o]nce started,
`the mobile wallet application 24 connects to the TSM system 120, which may house WMS 110, for synchronization in step 302.” ’125 patent at
`8:30-33. The same is true of the synchronization resulting from a change made to the mobile wallet application recited in claim 13. The embodiment
`of Figure 5 discusses synchronization initiated from the server (id. at 11:5-53)—the specification simply states that synchronization might result from
`a change made on the mobile device: “while mobile wallet application 24 is still active, any modifications that are made in the mobile wallet
`application 24 itself will be updated in the WMS 110 in step 505 as synchronization is a continuous one during usage.” Id. at 11:54-57. The
`Asserted Patent also states that synchronization may be updating a “change[d] user preference” or “expiration date.” Id. at 11:57-64. Little, if any,
`detail is provided with respect to how synchronization occurs and no suggestion is made that synchronization was new or not well-known, or that
`synchronization of mobile wallet software or data would be any different that synchronization of any other type of information as was well-known in
`the art.
`
`Fintiv’s Preliminary Infringement Contentions do not point to any evidence of synchronization, whether generally or with respect to the mobile
`device-initiated synchronization of claim 13. Indeed, for the synchronizing element of both claim 11 and claim 13, Fintiv’s Preliminary Infringement
`
`1 To the extent that these Invalidity Contentions rely on or otherwise embody particular constructions of terms or phrases in the Asserted Claims, including the constructions
`ordered by the Court in this action, Defendant is not proposing any such constructions as proper constructions of those terms or phrases and reserves the right to adopt different
`claim construction positions in this and other proceedings. Various positions put forth in this document are predicated on Plaintiff’s incorrect and overly broad interpretation of its
`claims as evidenced by its Preliminary Infringement Contentions, dated May 20, 2019 and proposed Amended Infringement Conventions, dated December 6, 2019 (collectively,
`the “Infringement Contentions” or “Preliminary Infringement Contentions”). Those positions are not intended to and do not necessarily reflect Defendant’s interpretation of the
`true and proper scope of Plaintiff’s claims, and Defendant reserves the right to adopt claim construction positions that differ from or even conflict with various positions put forth
`in this document.
`
`1
`
`IPR2020-00019
`Fintiv EX2034 Page 1
`
`

`

`Chart B-4
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Contentions cite only to the same evidence that it also cites with respect to activating the mobile wallet application and connecting to a TSM. See
`Preliminary Infringement Contentions Ex. A at pp. 2-5 (activating the mobile wallet application), 5-9 (same citations for connecting to a TSM), 9-13
`(same citations for synchronization element of claim 11), 20-32 (same citations for all elements of claim 13). Fintiv’s entire disclosure for the
`“synchronizing …” limitation in claim 11 is pasted below. See Preliminary Infringement Contentions, Ex. A at 9-13.
`
`
`
`
`2
`
`IPR2020-00019
`Fintiv EX2034 Page 2
`
`

`

`Chart B-4
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`
`As reflected by references below, synchronizing a mobile wallet application with a TSM system was well-known and understood by POSITAs at the
`time of the alleged invention. A POSITA would have been motivated to implement this standard practice in a mobile wallet to achieve the benefits
`of keeping financial information current and accurate, backing up and restoring information in the event of a data loss or a missing/broken device,
`and allowing both users and service providers to update information. See, e.g., Buhot EP 481 at ¶ 42 (“The instructions to update one or more
`parameters may include personalisation information to update one or more parameters of a NFC application element in accordance with details of the
`user…In the case of a payment card application element, the instructions to update one or more parameters may include instructions sent by the
`issuing bank to update the payment card expiration date, to change a security code, to set the credit card number, to set the security checks to be
`performed by the backend system during a payment transaction, to set the maximum amount for a payment transaction etc.”), ¶ 46 (“The update may
`be triggered by the user…”); AllwaySync (describing “Free File Synchronization, Backup, Data Replication, PC Sync Software, Freeware, File Sync,
`Data Synchronization Software”) https://web.archive.org/web/20090318105616/http://allwaysync.com/; Ilium Software eWallet (“With SyncPro
`Synchronization, you can make simultaneous changes to different cards on your Windows PC and Windows Mobile device and both changes will be
`
`
`
`
`
`3
`
`IPR2020-00019
`Fintiv EX2034 Page 3
`
`

`

`Chart B-4
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`synchronized.”). Accordingly, a POSITA would be motivated to combine standard file synchronization techniques in the context of synchronizing a
`mobile wallet with a TSM server.
`
`To the extent Fintiv contends that any reference identified in Exhibit A does not disclose any portion of the above limitations, such limitations are
`disclosed by the references herein. Moreover, the exemplary pincites to the prior art identified in the table below also establish that the allegedly
`missing portions would have been obvious to one of ordinary skill in the art. Further, a person of ordinary skill in the art would have been motivated
`to combine each reference identified in Exhibit A with any one or more of the following references for at least the reasons explained in the cover
`document of Apple’s Initial Invalidity Contentions or as identified herein.
`
`
`Reference
`
`“Toward a Mobile Digital
`Wallet” by Alan Cole et al.
`published October 16, 2009 in
`IBM Research Report (“Cole”).
`
`Disclosure
`
`See, e.g.:
`
`•
`
`•
`
`“[N]ative wallet applications on mobile devices could operate against replicated snapshots of the user’s wallet, enabling usage in
`situation where network connectivity to the central wallet service is unavailable or unreliable. The wallet service should support
`replication strategies where localized copies are synchronized at opportune times. … It should also be possible to transfer items from
`one wallet to another. Transfer capabilities should be in effect even if the two wallets are not managed by the same wallet host.”
`Cole at pg. 4-5.
`“Sharing. In many usages, the contents of a wallet could be shared among users - for example, family members may wish to share
`payment instruments or virtual cash. This can be realized in two ways: replication of the shared items from a base wallet, with
`periodic synchronization, or via virtualized views on a base wallet. Operations carried out on a virtualized wallet view would be
`transferred to the base wallet. Virtualization storage schemes would induce the need for virtualized access control policies, for
`example, a conservative scheme that computes and enforces the maximum access requirements among the base and virtualized
`wallets. Staged import and export. The combination of the above wallet storage, access control, and replication and transfer
`capabilities can be combined in useful ways that yield higher level policies about wallet usage.” Id.
`
`The teachings of this reference are explicitly directed to systems and methods wherein a central server administers a mobile wallet platform
`and provides mobile wallet synchronization capabilities to mobile devices. A POSITA at the relevant time would have been motivated to
`combine these teachings with other systems and methods in which servers provide software for provisioning on a mobile device, such as
`those identified in Exhibit A.
`
`“Ilium Software eWallet- Users
`Guide and Reference for
`Windows PCs and Windows
`Mobile-based Pocket PCs and
`
`See, e.g.:
`
`•
`
`“Synchronization
`
`4
`
`IPR2020-00019
`Fintiv EX2034 Page 4
`
`

`

`Chart B-4
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Smartphones, Version 4.0”
`Copyright 1997-2006, Ilium
`Software, Inc. (“Illium”).
`
`•
`
`
`eWallet 4.0 lets you choose between two ways of synchronizing your information: SyncPro™ and File Synchronization.
`
`With SyncPro Synchronization, you can make simultaneous changes to different cards on your Windows PC and Windows Mobile
`device and both changes will be synchronized. If you're using File Synchronization, however, you cannot update one record in a
`wallet (your Visa card, for example) on your Windows PC and another (your calling card) on your Pocket PC and have both changes
`take effect. Only whole files are synchronized.
`
`The Status Bar at the bottom of the Windows PC version of eWallet will show you the type of synchronization you have set for the
`currently opened wallet file.
`
`Use the picks on eWallet’s Synchronization menu to change synchronization settings for your open wallet file. To change settings
`for another wallet file, first open the file, then use the Wallet Synchronization Wizard.
`
`See Graphics and Sounds for information about the choosing the best options for using graphics and sound files in wallets that are
`synchronized.” Ilium at pg. 20-21.
`
`“SyncPro Synchronization
`
`With SyncPro™ Synchronization, you can make simultaneous changes to different cards on your Windows PC and Windows
`Mobile-based Pocket PC or Smartphone, and all changes will be synchronized. SyncPro allows two-way card synchronization with
`one Windows Mobile device as well as an automatic wallet file copy to any other connected Windows Mobile devices.
`
`SyncPro is for use only with Windows Mobile-based Pocket PCs and Smartphones. If you have a Palm Powered handheld, use
`HotSync to synchronize your eWallet information.
`
`We recommend you install the latest version of Microsoft ActiveSync for use with SyncPro.
`
`Follow the steps below to set up your Windows PC and Pocket PC or Smartphone for synchronization:
` 1. Make sure your Windows PC and your mobile device are connected using Microsoft ActiveSync.
` 2. Start the Wallet Synchronization Wizard by selecting Synchronization Setup from eWallet's Synchronize menu. When you're
`ready, press Next.
`3. Select your device in the wizard and press Next.
`4. Pick the Synchronization Action you'd like and press Next.
`5. Press Finish” Id at 21.
`
`The teachings of this reference are explicitly directed to systems and methods wherein a central server administers a mobile wallet platform
`and provides mobile wallet synchronization capabilities to mobile devices. A POSITA at the relevant time would have been motivated to
`
`5
`
`IPR2020-00019
`Fintiv EX2034 Page 5
`
`

`

`Chart B-4
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`U.S. Patent Publication No.
`2012/0136732 A1 to McMillen
`(“McMillen”).
`
`combine these teachings with other systems and methods in which servers provide software for provisioning on a mobile device, such as
`those identified in Exhibit A.
`
`See, e.g.:
`
`•
`
`•
`
`“After the user has launched the wallet application module 8 of the mobile device 3b, a wallet screen 24 may be provided to display
`the inactive mobile payment account or a list of inactive mobile payment accounts awaiting activation as shown in the exemplary
`display screen 76 in FIG. 5b. Accordingly, at step S3-47, the mobile device 3b receives a user selection 77 of an inactive mobile
`payment account stored in the secure memory 4 of the authorized user's mobile device 3b. In response, the mobile device 3b displays
`at step S3-49 a subsequent display screen 78 as shown in FIG. 5c, to prompt the authorized user to input the activation code for the
`selected mobile payment account. This is the activation code that was generated by the middleware server 16 in response to
`receiving the ‘add authorized user’ request, transmitted to the account owner's mobile device 3a, and communicated by the account
`owner to the authorized user, as described above. At step S3-51, the mobile device 3b receives the user input activation code via a
`text input field 79 of the display screen 78, and at step S3-53, the user input activation code is transmitted by the mobile device 3b to
`the middleware server 16, via the communications server 13 of the account management system 7.
`
`At step S3-55, the middleware server 16 receives the activation code as input by the authorized user to the mobile device 3b and
`compares the received user input activation code to the previously generated activation code as transmitted to the authorized user's
`mobile device 3a, at step S3-57. If the middleware server 16 determines that the two codes do not match, then the user input
`activation code is not correct and in response, the middleware server 16 may transmit an error message back to the authorized user's
`mobile device 3b at step S3-59. In such an embodiment, the authorized user's mobile device 3b may be configured to display the
`error message and return to step S3-49 where the user is prompted for the correct activation code. On the other hand, if the
`middleware server 16 determines at step S3-57 that the user input activation code is correct, then at step S3-61, the middleware
`server 16 may set the account state of the authorized user’s mobile payment account that is linked to the primary account to ‘Issuer
`PIN unblocked’ to indicate that the authorized user has been verified (by input of the correct activation code, which will only be
`known to the account owner and the authorized user) and that the mobile payment account can be configured for activation and use
`by the authorized user on the mobile device 3b. Therefore, at step S3-63, the middleware server 16 transmits a PIN unblock
`command to the authorized user's mobile device 3b, and may also transmit a message to the payment account issuer 10 with the state
`of the mobile payment account.” McMillen at paragraphs [0037] - [0038].
`
`“In response to receiving the PIN unblock command, the mobile device 3b displays a wallet display screen 80 at step S3-65 to
`prompt the authorized user to set a PIN (or passcode) for the mobile payment account. As shown in FIG. 5d, this wallet display
`screen 80 may prompt the authorized user to input the PIN a second time as confirmation of the correct PIN being set, and may also
`prompt for a secret word to be set, which may be used as a user verification in the event that the user wishes to recover a forgotten
`PIN. As those skilled in the art will appreciate, the PIN or passcode may be used for verifying or authenticating the user before
`effecting payment transactions from the associated mobile payment account, or before any servicing of the mobile payment account
`on the mobile device 3b. At step S3-67, the mobile device 3b receives and stores the user input PIN and secret word as mobile
`payment account data for the activated mobile payment account in the secure memory 4b of the mobile device 3b. At step S3-69, the
`mobile device 3b then transmits a confirmation message back to the middleware server 16 to inform the account management system
`
`6
`
`IPR2020-00019
`Fintiv EX2034 Page 6
`
`

`

`Chart B-4
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`U.S. Patent Publication No.
`2010/0041368 A1 to Kumar
`(“Kumar”).
`
`•
`
`7 that the PIN has been set by the user. In response to receiving the confirmation at step S3-71, the middleware server 16
`automatically activates the authorized user's mobile payment account by setting the state to ‘Active’. The authorized user is then able
`to use the activated mobile payment account in the electronic wallet of the authorized user's mobile device 3b, that is linked to a
`primary account belonging to another user, to carry out contactless payment transactions as described in the Applicant's above
`referenced co-pending U.S. patent applications Ser. Nos. 12/891,866 and 12/905,419.” Id at paragraph [0039].
`
`“The account management system 7 in the mobile payment system 1 will now be described in more detail with reference to FIG. 1,
`which shows the elements of the account management system 7 used in embodiments of the present invention. As shown, the
`account management system 7 may include a communications server 13, a middleware server 16, and a TSM server 18, which
`communicate electronically with one another. In this embodiment, the servers communicate with one another via secure network
`links over a private Local Area Network (LAN), a Virtual Private Network (VPN) connection, or other dedicated secure connection.
`It is appreciated that, although the components of the account management system 7 in this embodiment are provided as separate
`servers, one or more of the servers could be provided as software and/or hardware modules in the same server.” Id at paragraph
`[0019].
`
`The teachings of this reference are explicitly directed to systems and methods wherein a central server administers a mobile wallet platform
`and provides mobile wallet synchronization capabilities to mobile devices. A POSITA at the relevant time would have been motivated to
`combine these teachings with other systems and methods in which servers provide software for provisioning on a mobile device, such as
`those identified in Exhibit A.
`
`See, e.g.:
`
`•
`
`“To better illustrate the issuance of an electronic prepaid card in an NFC enabled mobile device, FIG. 3 is provided to depict a flow
`chart of an exemplary method 300 for issuing an electronic prepaid card according to an embodiment of the subject matter described
`herein.
`
`In block 302, a control short message is received by an NFC enabled handset. In one embodiment, OTA provisioning server 112
`sends a control SMS message (via SMS gateway 113) to NFC enabled mobile device 114.
`
`In block 304, the NFC enabled handset processes the control SMS message. In one embodiment, a wallet client of mobile device 114
`is instructed by the control short (binary) message to initiate a download process. Mobile device 114 may also send a message
`acknowledging receipt of the control short message to OTA provisioning server 112.
`
`In block 306, the OTA provisioning server receives an acknowledgement message from the NFC enabled handset. In one
`embodiment, OTA provisioning server 112 receives a message acknowledging the receipt of the control message from the wallet
`client in mobile device 114.
`
`In block 308, the OTA provisioning server creates a secured link with NFC enabled handset. In one embodiment, OTA provisioning
`server 112 established a secured line of communications with the wallet client and secure memory of mobile device 114.
`
`7
`
`IPR2020-00019
`Fintiv EX2034 Page 7
`
`

`

`Chart B-4
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`•
`
`
`In block 310, the OTA provisioning server provides personalization data over the secured link. In one embodiment, OTA
`provisioning server 112 uploads personalization data to the secure element in mobile device 114 over the established secured link.”
`Kumar at paragraphs [0044] - [0049]. See also Kumar at Fig. 3.
`
`“System 100 may also include a merchant server 108, a telecommunications operations server 110, and an over-the-air (OTA)
`provisioning server 112. In one embodiment, merchant server 108 may comprise a backend server that is associated with a particular
`merchant, retailer, or internet-based store. Telecommunications operator server 110 may include a server associated with a
`telecommunications service provider (e.g., a wireless phone service provider) that is capable of providing information related to a
`given mobile device and/or phone number. For example, server 110 may contain phone numbers and the type of mobile device
`associated with each phone number. OTA provisioning server 112 may include a server that is responsible for receiving and
`validating prepaid card information from various merchant servers (e.g., merchant server 108) as well as issuing electronic prepaid
`card information to mobile devices (e.g., mobile devices 114, 116, as explained below) per the instructions and information received
`from the merchant servers. In one embodiment, the functions provided by OTA provisioning server 112 may be performed by a
`plurality of servers (e.g., a control server, which provides OTA administrative services for the secure element on a mobile device,
`and an issuer server, which provides a secure local provisioning point for issuing softcards to a mobile device in order to allow an
`issuer to maintain full possession and control of softcard data).” Id at paragraph [0017].
`
`The teachings of this reference are explicitly directed to systems and methods wherein a central server administers a mobile wallet platform
`and provides mobile wallet synchronization capabilities to mobile devices. A POSITA at the relevant time would have been motivated to
`combine these teachings with other systems and methods in which servers provide software for provisioning on a mobile device, such as
`those identified in Exhibit A
`
`
`See e.g.:
`
`•
`
`•
`
`“Having a plurality of stand alone NFC application elements, particularly when there are several NFC application elements of the
`same type, for use in a mobile phone can raise a number of issues due to the fact that each NFC application element operates in
`isolation of the other elements. Such issues include, for example, difficulties for a user to manage such stand alone NFC application
`elements. For example, with stand alone application elements, when a user wishes to change dynamically the available NFC services
`which will involve changing the NFC application elements stored in the secure element, the user has to view and select each NFC
`application element separately. These issues are likely to increase as the number of available NFC services increase, and the number
`of application element providers increase.” Buhot EP 481 at paragraph [0009].
`“In an example of an embodiment of the disclosure, the updates may also include update information for one or more of the NFC
`services associated with the NFC application elements 302-312 stored in the NFC unit 218. The update information may include
`instructions to add a new NFC application element to the NFC unit 218, instructions to update one or more parameters of a NFC
`application element stored in the NFC unit 218 and/or instructions to remove one or more NFC application elements stored in the
`NFC unit 218. The instructions to update one or more parameters may include personalisation information to update one or more
`parameters of a NFC application element in accordance with details of the user. For example, in the case of a payment application
`
`8
`
`European Patent Publication
`No. EP 2211481 A1 to Buhot
`(“Buhot EP 481”).
`
`IPR2020-00019
`Fintiv EX2034 Page 8
`
`

`

`Chart B-4
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`element, the personalisation information may include information to set the personal account number, cryptographic keys, CALC or
`branding information for the end user. In the case of a payment card application element, the instructions to update one or more
`parameters may include instructions sent by the issuing bank to update the payment card expiration date, to change a security code,
`to set the credit card number, to set the security checks to be performed by the backend system during a payment transaction, to set
`the maximum amount for a payment transaction etc.. The update information may additionally or alternatively include data or
`transaction information for the NFC service, such as payment details.” Buhot EP 481 at paragraph [0042].
` “In the arrangement 100 shown in FIG. 1, an OTA server 112 provides updates to the mobile device 102 via the GSM
`communication system 104. Although one OTA server 112 is shown, there may be more than one OTA server with each OTA server
`providing different updates. In an example in accordance with an embodiment of the disclosure, the update information provided by
`the OTA server 112 include updates to NFC application elements held in the mobile device 102. The OTA server 112 may be part of
`the GSM network operator or may be separate.” Buhot EP 481 at paragraph [0044].
`“The update may be triggered by the user or the OTA server.” Buhot EP 481 at paragraph [0046].
`“If the mobile application elements 318-328 associated with the new or updated NFC application elements are already stored on the
`mobile device 102, the mobile application elements may receive a notification telling them their parameters have been updated or
`new applications have been installed as is described in more detail below. After receiving the notification, the mobile application
`element fetches the update from the NFC unit 218. If the mobile application element is not stored on the mobile device 102, or is not
`able to handle the new loaded and installed NFC application elements in the secure element, an update of this mobile application
`element can also be done OTA.” Buhot EP 481 at paragraph [0048].
`
`•
`
`•
`•
`
`The teachings of this reference are explicitly directed to systems and methods wherein a central server administers a mobile wallet platform
`and provides mobile wallet synchronization capabilities to mobile devices. A POSITA at the relevant time would have been motivated to
`combine these teachings with other systems and methods in which servers provide software for provisioning on a mobile device, such as
`those identified in Exhibit A.
`
`See e.g.:
`
`•
`
`•
`
`•
`
`•
`
`“A NFC service may be updated by adding a new application element to the NFC unit 218, by updating one or more parameters of
`the at least one associated application element and by removing the at least one associated application element stored in the NFC unit
`218.” ¶46; see also ¶¶50, 52, 53, 63, 80, 83.
`“Updating a NFC service may include deleting, updating, installing an application element in the NFC unit 218, and/or deleting,
`updating, installing an NFC managing element in the program memory 216. The user interface element 224 is updated accordingly.”
`¶55.
`“The OTA server 114 is thus able to load, install, update and personalise NFC application elements in the NFC unit 218.” ¶111; see
`generally ¶¶107-117.
`“[T]he user interface element in accordance with the examples described above provides the user the possibility to update (install,
`add, update and uninstall) the NFC managing elements and the associated application elements. The user may also have the
`
`9
`
`U.S. Pat. Pub. 2010/0190437
`(“Buhot 437”). Buhot 437 was
`filed December 23, 2009 and
`published on July 29, 2010.
`
`IPR2020-00019
`Fintiv EX2034 Page 9
`
`

`

`Chart B-4
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`U.S. Patent No. 9,558,481 to
`Bauer (“Bauer”).
`
`possibility to install new card application elements in a NFC managing element. The user may also uninstall/update NFC managing
`elements already installed as well as their content (for example, update or delete card application elements).” ¶118.
`
`The teachings of this reference are explicitly directed to systems and methods wherein a central server administers a mobile wallet platform
`and provides mobile wallet synchronization capabilities to mobile devices. A POSITA at the relevant time would have been motivated to
`combine these teachings with other systems and methods in which servers provide software for provisioning on a mobile device, such as
`those identified in Exhibit A.
`
`See e.g.:
`
`•
`
`•
`
`“The mobile device 3 also includes a payment account wallet application module 8 storing processing instructions used to control the
`operation of the mobile device 3, for example to i) request creation of a new mobile payment account, ii) handle a secure mobile
`payment account activation process, and/or iii) process a transaction with a merchant via the electronic POS terminal 5 to effectively
`transfer funds from the mobile payment account on the mobile device 3 to the merchant …
`Before the user can use the mobile device 3 to carry out transactions with a merchant electronic POS terminal 5, a new mobile
`payment account may be provisioned for the user, for example in response to a user requesting a new mobile payment account via
`the mobile device 3. Payment account data 6 may be created by the account activation system 7 for a new mobile payment account,
`and the account activation system 7 may be arranged to immediately transmits the payment account data 6 to the mobile device 3 for
`storage in the secure memory 4 of the mobile device 3.” Bauer at col. 3 ln. 41 - col. 4 ln. 6.
`“As shown in FIG. 3, the automated process begins at step S3-1 where the middleware server 16 in the account provisioning system
`7 may receive a request for a new mobile payment account from the mobile device 3 via the communications server 13, the request
`including data identifying the mobile device 3 and details entered by the user for provisioning the new mobile payment account. As
`is common under normal and customary banking processes and systems, the details may include for example the user's name,
`address and birth date. Next, at step S3-3, the middleware server 13 may initiate an account provisioning process for a new mobile
`payment account and sets the servicing state of the new mobile payment account to "Inactive" to indicate that the account has just
`been created and has yet to be transmitted to the mobile device 3 for authentication and activation. A mobile payment account with
`an "Inactive" state is not available for use by the mobile device 3 to carry out transactions. The middleware server 13 may be
`configured to store a database of created accounts to maintain the respective states for provisioning.
`As part of the account provisioning process if necessary, at step S3-5, the middleware server 16 may send an instant mobile account
`provisioning request (which includes the data identifying the mobile device 3 and the user details) to the account creation server 17.
`At step S3-7, the account creation server 17 may extract the user details from the received instant mobile account provisioning
`request and sends the extracted user details to the payment account issuer 10 to establish a new account at the payment account
`issuer 10. At step S3-9, the account creation server may receive an embossing data file for the new account from the payment
`account issuer 10 after the new account has been established at the payment account issuer 10. At step S3-11, the account creation
`server 17 may then create mobile payment account data 6 for a new mobile payment account based on the received embossing data
`file. The new mobile payment account data 6 includes the data identifying the mobile device 3 received in the instant mobile account
`provisioning request.
`
`10
`
`IPR2020-00019
`Fintiv EX2034 Page 10
`
`

`

`Chart B-4
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`U.S. Patent Publication No.
`2010/0082487 A1 to Nelsen
`(“Nelsen”). Nelsen was file
`don September 23, 2009 and
`published on April 1, 2010.
`
`At step S3-13, the account creation server 17 may then send the mobile payment account data 6 for the new provisioned mobile
`payment account to the TSM server 18 via the middleware server 16. At step S3-15, the TSM server 18 may prepare the mobile
`payment account data 6 for transmission to and storage on