Chart B-5
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Fintiv, Inc. v. Apple Inc., Case No. 1:19-CV-1238-ADA (W.D. Tex.)
`
`Displaying and Receiving a Selection of a Contactless Card Applet
`
`CLAIM LIMITATIONS: “displaying a contactless card applet based on attributes of the mobile device” and “receiving a selection of a contactless card
`applet” (’125 patent claim 11).
`
`ASSERTED CLAIMS:
`
` These limitations are present in the following asserted claim: ’125 patent claim 11 (and its dependent claims).
`
`DISCLOSURE/MOTIVATION TO COMBINE:
` Under Fintiv’s interpretation of these claim limitations, mobile devices that displayed and received a
`selection of a contactless card applet (“CCA”) were well-known to POSITA at the time of the alleged inventions. 1
`
`For both the “displaying …” and “receiving …” limitations, the entirety of Fintiv’s Infringement Contentions is reproduced below:
`
`
`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 EX2035 Page 1
`
`

`

`Chart B-5
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`
`
`
`See Infringement Contentions Ex. A at pp. 13-18.
`
`These passages disclose nothing about “displaying a contactless card applet …” Nor do they disclose “receiving a selection of a contactless card
`applet …” from a user. Rather, the passages disclose a user manually entering credit card information (e.g., by typing in the card number) or taking
`a picture of their card for provisioning purposes. Under Fintiv’s interpretation, these claim limitations were well-known and/or would have been
`obvious to POSITAs at the time of the alleged invention as reflected by the prior art references below. The Asserted Patent does not disclose that the
`contactless card applet is displayed in any novel manner or that “receiving a selection of a contactless card applet” is accomplished in an
`unconventional or new way. See, e.g., ’125 patent at 11:2-4 (“TSM system 120 sends the list of applets to display to the mobile gateway in step 404,
`which relays it back to the mobile wallet application 24 in step 405.”); id. at 8:46-51 (“mobile device user is prompted to decide whether to update
`the mobile wallet application 24 with the changes made at the TSM system 120”). To the contrary, such activities were well-known to POSITA and
`it would have been obvious to modify prior art system or methods wherein a contactless card applet is provisioned on a mobile device so that the
`mobile device displays and receives a selection of that contactless card applet. Nothing in the Asserted Patent suggests that using similar
`“displaying” and “receiving” techniques used outside the context of contactless card applications (e.g., for displaying and selecting other types of
`software such as games apps and the like) would have required anything beyond the ordinary skill to implement in the context of contactless card
`applets.
`
`
`
`
`2
`
`IPR2020-00019
`Fintiv EX2035 Page 2
`
`

`

`Chart B-5
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`A POSITA would have been motivated to implement these standard practices to provide a simple, intuitive, and convenient way to select and install
`software such as contactless card applications. This is especially true given the proliferation of available applications (such as contactless card
`applets) from companies like Visa, Mastercard, and Discover. See, e.g., Khan at 2:43-67 (“A card number for a soft card desired to be provisioned
`on the device is obtained form the user of the device…Soft card personalization data along with branding image, marketing data, card embossing and
`imprint data, account summary data for provisioning the soft card is received from the provisioning issuer server. The soft card is provisioned for use
`on the device based on the personalization data.”); Brudnicki at Figs. 4A-4B, ¶ 53 (“As an example, FIGS. 4A and 4B, illustrate the provisioning of a
`“Charge-It Card into the wallet using one exemplary wallet user interface 410 that may be deployed on a Smartphone. Underlying either user
`interface, the card services module 420 preferably transmits the first six digits of the identified credit card (commonly referred to as the Bank
`Identification Number or BIN) to the control server, which then validates the card issuer's compliance rules and facilitates a direct key exchange
`between the OpenWallet 100 (or Card Services Module 420) on the user’s mobile device 50 and the appropriate issuer server in an encrypted fashion
`as was previously known in the art.”). Further, it would have been obvious to display to a user the contactless card applets corresponding to the
`credit card accounts a user had already setup with his/her bank. For example, if a user had a Visa and American Express cards, but not Discover or
`Mastercard cards, a POSITA would have been motivated to simplify the selection process for the user by only displaying the Visa and American
`Express options.
`
`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
`
`Disclosure
`
`U.S. Patent Publication No. 2010/0138518
`A1 (“Aiglstorfer”). Aiglstorfer was filed on
`November 18, 2009 and published on June
`3, 2010.
`
`See, e.g.:
`
`• Aiglstorfer at paragraph [0039] (“It is appreciated that additional banking card information and moblet software
`modules associated therewith may be similarly received and installed and messaged by the first moblet 106. For
`example, a second banking card information 113 may be transmitted from the TSM 120 to the TSA 102. The TSA 102
`may store the second banking card information 113 in the removable security element 104. The TSA 102 may
`subsequently automatically notify 115 the first moblet software module 106 of the transmission of the second banking
`card information. According to one embodiment, the first moblet software module 106 notifies 117 the remote server
`130 that the second banking card information 113 has been received.”).
`
`3
`
`IPR2020-00019
`Fintiv EX2035 Page 3
`
`

`

`Chart B-5
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`U.S. Pat. Pub. 2010/0190437 (“Buhot
`437”). Buhot 437 was filed December 23,
`2009 and published on July 29, 2010.
`
`• Aiglstorfer at paragraph [0042] (“According to one embodiment, the third moblet software module 112 may be
`transmitted wirelessly and installed on the electronic device 110 transparent to the user. It is appreciated that updates
`to the third moblet software module 112 may be transmitted and installed automatically. However, it is appreciated
`that the third moblet software module 112 or any update thereof may be received and installed on the electronic device
`110 responsive to a user request.”).
`
`• Aiglstorfer at paragraph [0072] (“At step 734, graphical icons of the second and the third moblet software modules are
`rendered on a display of the portable device. The graphical icons are user selectable. It is appreciated that the display
`and selection of the second and the third moblet software modules are controlled by operations of the first moblet
`software module.”).
`
`•
`
`See also Aiglstorfer at ¶¶ 51, 54.
`
`The teachings of this reference are explicitly directed to systems and methods wherein a contactless card applet is provisioned
`on a mobile device, and a POSITA at the relevant time would have been motivated to combine these teachings with other
`systems and methods in which a mobile device displays and receives a selection of a contactless card applet, such as those
`identified in Exhibit A.
`
`See, e.g.:
`
`•
`
`“The user interface element 224 also includes a user interface engine 330 for providing information relating to the
`NFC services provided by the NFC application elements 302-312 to a user via the MMI 214. The information
`presented to the user may include a list of the NFC services which may be provided by the NFC application elements
`302-312. Using the examples given above for the NFC application elements 302-312, the list may include
`PayPass.TM. payment card, VSDC.TM. payment card, train ticket, airline ticket, book shop loyalty card, airline
`loyalty card. The user interface element 224 therefore enables the user to select one of the NFC services or NFC
`application elements 302-312 from information provided to the user via the MMI 214 and once selected, the user
`interface element 224 manages the selected NFC application element via the respective managing application element
`to provide the selected service or to update a NFC service. Managing the selected NFC application by the user
`interface element 224 includes selecting and executing the managing application element which corresponds to the
`selected NFC application element and the selected managing application element then controls the respective NFC
`application element and its behaviour during the provision of the associated service. 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;
`see also ¶¶46, 21-22, 57-58, 89-90, 97, 118, 120.
`
`4
`
`IPR2020-00019
`Fintiv EX2035 Page 4
`
`

`

`Chart B-5
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`“installCard: the user interface element 224 informs a NFC managing element to check for some new card application
`elements available for installation … After a successful card installation, the NFC managing element and the user
`interface element 224 are updated accordingly. New card application elements installed are registered with the
`registration element 331 and can be selected by the user interface element 224 to proceed with a contactless
`transaction.” ¶81.
`
`“Since the user interface element 224 provides to the user information relating to the available NFC services, the user
`interface element 224 needs to be notified accordingly to take these changes into account so that it can update the
`information displayed to the user to provide the user an updated list of the available NFC services and NFC
`application elements that are present in the NFC unit 218 after an OTA update. The default NFC application element,
`the branding information, the CALC information may have changed too. Thus, the processing unit is further arranged
`to update the information provided to the user by the user interface element 224 according to the received update
`information transferred to the NFC unit 218. In a mobile device having a database element 316, the database element
`316 is updated when the received update information is transferred to the NFC unit and the information presented to
`the user may be updated from the updated information in the database element 316.” ¶115.
`
`“The mobile device 102 also has a Man Machine Interface MMI 214, including elements such as a key pad,
`microphone, speaker, display screen, for providing an interface between the mobile device 102 and a user of the
`device. The MMI 214 is also coupled to the processing unit 200.” ¶39.
`“In the above, the user interface element 224 informs a NFC managing element in response, for example, to user
`selection via a display of the mobile device 102.” ¶84; see also ¶81.
`“The user interface element enables information for the different application elements to be collected and presented to
`the user in a simple user friendly manner, for example, by a central menu which lists the different types of available
`NFC services, and enables the user to select and initiate a NFC service out of a plurality of NFC services via the
`information presented to the user which selected NFC service is then provided by the NFC managing element of the
`selected NFC service managing the appropriate application element(s).” ¶124.
`“The user selects a card application element to proceed with the contactless transaction, step 704. In response to user
`selection of a card application element, the user interface engine 330 forwards a start transaction event to the
`registration element 331, step 706. As the selected card application element belongs to the NFC managing element A,
`the registration element 331 notifies the NFC managing element by invoking the selectCardAndProcess service, step
`708. The NFC managing element A initialises itself, and activates the card application element and the NFC hardware
`(such as the NFC communication section 204), step 710. When the NFC managing element A is ready to proceed with
`the contactless transaction, the user interface element 224 is put on standby, step 712 and a user interface of the NFC
`managing element A is activated (step 714). The activated user interface notifies the user that the selection of the card
`
`5
`
`IPR2020-00019
`Fintiv EX2035 Page 5
`
`

`

`Chart B-5
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`•
`
`•
`
`application element has been successful.” ¶94. At a minimum, it would have been obvious to a POSITA to use the
`same selection process to install/updatea contactless car application. See ¶118.
`“the 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 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 user interface element in accordance with the examples described above activates or triggers a NFC managing
`element after the user selected a NFC service associated with the NFC managing element and lets the NFC managing
`element proceed with the contactless transaction or update the selected NFC service. The NFC managing element is
`responsible for the initialization (hardware and software), execution and end of transaction detection, has the control
`of the contactless transaction and has to inform the user of the progress of the contactless transaction. The user
`interface element execution stops once the NFC managing element is ready to start the transaction and restarts
`executing when the NFC managing element flow ends e.g. when the NFC managing element notifies the user of the
`end of the contactless transaction. On re-start, the user interface element may offer the user to proceed with another
`NFC service.” ¶123; see also ¶121.
`
`The teachings of this reference are explicitly directed to systems and methods wherein a contactless card applet is provisioned
`on a mobile device, and a POSITA at the relevant time would have been motivated to combine these teachings with other
`systems and methods in which a mobile device displays and receives a selection of a contactless card applet, such as those
`identified in Exhibit A.
`
`See, e.g.:
`
`• Buhot EP 481 at paragraph [0034] (“In an example, the user interface element 224 may group the NFC services
`according to the type of available NFC service. For example, the user may be presented with a list of the available
`payment cards, a list of the available loyalty cards and/or a list of the available transport tickets. The information
`provided to the user may be in the form of graphical representations or other identifier for each of the NFC services
`e.g. a logo or brand image or jingle or animation etc. for each NFC service. The user interface element 224 may in
`addition provide some options to the user(e.g. via menus on the display of the mobile device 102) such as managing a
`lock code for a particular NFC application element or selecting payment card options such as the default card to be
`used during a contactless transaction. The lock code is known as the Contactless Application Lock Code (CALC) and
`
`6
`
`European Patent Publication No. 2211481
`A1 (“Buhot EP 481”). Buhot EP 481 was
`filed on January 26, 2009 and published on
`July 28, 2010.
`
`IPR2020-00019
`Fintiv EX2035 Page 6
`
`

`

`Chart B-5
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`if used, may be provided to the NFC unit 218 when the NFC application element is stored in the NFC unit 218.
`Managing the CALC may include verifying, changing, or activating/deactivating the CALC.”).
`
`• Buhot EP 481 at paragraph [0042] (“ 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 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 [0046] (“The update may be triggered by the user or the OTA server.”).
`
`The teachings of this reference are explicitly directed to systems and methods wherein a contactless card applet is provisioned
`on a mobile device, and a POSITA at the relevant time would have been motivated to combine these teachings with other
`systems and methods in which a mobile device displays and receives a selection of a contactless card applet, such as those
`identified in Exhibit A.
`
`U.S. Patent Publication No. 2012/0123935
`(“Brudnicki”). Support for at least claim 1
`and/or claim 7 of Brudnicki is found in
`provisional application Nos. 61/414,847 and
`61/414,849, filed on Nov. 17, 2010.
`Accordingly, Brudnicki is entitled to a
`§ 102(e) prior art date of the provisional
`applications. See, e.g., Dynamic
`
`See, e.g.:
`
`• Brudnicki at ¶ 49 (“…The Card Services Module 420 may be configured to track the issuer of all card, coupon, access
`and ticket data stored in the payment subsystem 150 of the portable communication device 50 and determine on an
`application-by-application basis whether an application should have permissions to view, select, use and/or change
`secure data stored in the payment subsystem. The wallet user interface 410 provides a user interface through which a
`user may register, provision, access and/or use the information securely stored in association with the card services
`module 420 relating to the user's credentials….”).
`
`7
`
`IPR2020-00019
`Fintiv EX2035 Page 7
`
`

`

`Chart B-5
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Drinkware, LLC, v. National Graphics,
`Inc., Case No. 2015-1214 (Fed. Cir. 2015).
`
`Disclosure
`
`• Brudnicki at ¶ 50 (“Various screen shots of one exemplary wallet user interface 410 that may be deployed on a smart
`phone are shown in FIGS. 4A, 4B, 4C and 4D. Among other things these figures illustrate the functionality of
`registering, provision ing, access and/or using information securely stored in association with the card services
`module 420. FIG. 4A depicts that the wallet can hold various credentials such as cards, coupons, tickets and more.
`FIG. 4A further depicts that multiple cards may be stored in the wallet 100.”).
`
`• Brudnicki at Figs. 4A-4C:
`
`• Brudnicki at ¶ 53 (“The user interface may be generated by wallet user interface 410 or a trusted third party
`application 200 Supported by OpenWallet 100. As an example, FIGS. 4A and 4B, illustrate the provisioning of a
`“Charge-It Card into the wallet using one exemplary wallet user interface 410 that may be deployed on a Smartphone.
`Underlying either user interface, the card services module 420 preferably transmits the first six digits of the identified
`credit card (commonly referred to as the Bank Identification Number or BIN) to the control server, which then
`validates the card issuer's compliance rules and facilitates a direct key exchange between the OpenWallet 100 (or Card
`
`
`
`8
`
`IPR2020-00019
`Fintiv EX2035 Page 8
`
`

`

`Chart B-5
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`Services Module 420) on the user's mobile device 50 and the appropriate issuer server in an encrypted fashion as was
`previously known in the art.”).
`
`• Brudnicki at ¶ 54 (“Various approaches to the direct key exchange may be facilitated by a variety of off-the-shelf
`solutions provided by entities including, but not limited to, Gemalto N.V. (Amsterdam, The Netherlands), Giesecke &
`Devrient (Munich, Germany), SKC&C (Korea) (Corefire), or VIVOtech Inc. of Santa Clara, Calif. (ViVoTech Issuer
`Server). The Issuer Server authenticates the user, executes issuer rules and then initiate the personalization process.
`The Issuer Server is preferably a server operated by the issuer of the credentials that the user is seeking to provision.
`The issuer server may verify the user, for example by providing a series of Verification questions based on user
`information previously provided to the issuer (see FIG. 4B). Once verified, the issuer server passes the full 16 digit
`credit card number to the secure element 120 via the card service module 420. The issuer server may also pass
`metadata, Such as information relating to the look and design of the selected credit card to the application memory
`125. On completion, the issuer adapter would notify the control server about the completion of the transacttion.”).
`
`• Brudnicki at ¶ 55 (“As shown in FIG. 4C, following provisioning the wallet user interface 410 would include the
`Charge-It Card, which the user could select using user interface techniques that are well-known in the art of
`smartphone user interfaces.”).
`
`•
`
`See also Brudnicki at Fig. 9A.
`
`The teachings of this reference are explicitly directed to systems and methods wherein a contactless card applet is provisioned
`on a mobile device, and a POSITA at the relevant time would have been motivated to combine these teachings with other
`systems and methods in which a mobile device displays and receives a selection of a contactless card applet, such as those
`identified in Exhibit A.
`
`See, e.g.:
`
`• Khan at 2:43-67 (“According to one method, a soft card provisioning application is instantiated on a device with
`wireless communications capabilities. A card number for a soft card desired to be provisioned on the device is
`obtained form the user of the device. The first 8 digits of card number representing the issuer identification number
`(IIN) are communicated to a provisioning configuration server over an air interface. The IIN could vary from 4 digits
`to 8 digits. A provisioning issuer server network address is obtained from the provisioning configuration server
`corresponding to the issuer identification number (IIN). A connection is made to the provisioning issuer server
`corresponding to the network address. The complete card number is communicated to a provisioning issuer server.
`Card-issuer specific challenges corresponding to the card number are obtained from provisioning issuer server. The
`
`9
`
`U.S. Patent No. 8,165,635 to Khan
`(“Khan”). Khan was filed on December 19,
`2008, published on June 25, 2009, and
`issued on April 24, 2012.
`
`IPR2020-00019
`Fintiv EX2035 Page 9
`
`

`

`Chart B-5
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`challenges are presented to the user, and the user's responses to the challenges are received. The challenge responses
`are communicated to the provisioning issuer server. Soft card personalization data along with branding image,
`marketing data, card embossing and imprint data, account summary data for provisioning the soft card is received
`from the provisioning issuer server. The soft card is provisioned for use on the device based on the personalization
`data.”).
`
`• Khan at 4:57-5:4 (“Provisioning configuration server 108 may store configuration and business process information
`for a plurality of different card issuers. For example, provisioning configuration server 108 may receive soft card
`provisioning requests from provisioning and payment application 102. Provisioning configuration server 108 may
`identify the card issuer associated with the request based on an Issuer Identification Number (IIN) of card number or
`an identifier provided in the request. Provisioning configuration server 108 may provide a single point of contact for
`mobile device users to provision soft cards. In addition, provisioning configuration server 108 may be configured to
`communicate with multiple card issuers. As a result, provisioning configuration server 108 provides an easy-to-use,
`scalable solution to soft card provisioning.”).
`
`• Khan at 6:35-41 (“In step 202, the card issuer identifier is obtained from the user. The issuer identifier may be the
`Issuer identification number (IIN) of the personal account number (PAN) associated with the Soft card request. For
`manual provisioning, step 202 may be performed by provisioning and payment application 102. For automatic
`provisioning, step 202 may be performed by web provisioning application 104.”).
`
`• Khan at 7:50-63 (“In step 310, if the number of cards to be downloaded is less than the maximum number, control
`proceeds to step 316 where application 102 asks the user to enter the PAN number for the card to be downloaded.
`Once the user enters the PAN number, control proceeds to step 318 in FIG. 3B where the application starts the
`authentication process. Detailed steps for authenticating the device will be described below. In step 320, it is
`determined whether the device is authenticated. If the device is not authenticated, control proceeds to step 322 where
`application 102 indicates that the phone is not a valid phone with a secure memory and near field communication
`component. Application 102 may display to the user a message to contact customer Support. Control then proceeds to
`step 314 where the provisioning process ends.”).
`
`• Khan at 11:12-25 (“In step 702, it is determined whether automatic or manual provisioning is being performed. If
`manual provisioning is being performed, control proceeds to step 704 where the user enters the PAN and response to
`the challenge questions on the wireless-communications-enabled device. In step 706, provisioning and payment
`application 102 creates a secure channel to provisioning issuer server 110 through provisioning configuration server
`108 for direct data transfer to and from provisioning issuer server 108. In step 708, provisioning and payment
`application 102 encrypts and sends the PAN identification information and the response to the challenge questions to
`
`10
`
`IPR2020-00019
`Fintiv EX2035 Page 10
`
`

`

`Chart B-5
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`provisioning issuer server 708. In step 710, provisioning issuer server 110 communicates the PAN and the response to
`the challenge questions to the card issuer back end network.”).
`
`• Khan at 11:67-12:4 (“Referring to FIG. 8A, in step 800, a user contacts card issuer customer Support via telephone.
`The user may provide the mobile phone number, PAN number, CVV and expiration date embossed on the plastic card
`for the soft card that the user desires to provision on a mobile device.”).
`
`•
`
`See also Khan at Figs. 2, 3A-3B, 7A-7B, 8A.
`
`The teachings of this reference are explicitly directed to systems and methods wherein a contactless card applet is provisioned
`on a mobile device, and a POSITA at the relevant time would have been motivated to combine these teachings with other
`systems and methods in which a mobile device displays and receives a selection of a contactless card applet, such as those
`identified in Exhibit A.
`
`The ViVOtech System. The ViVOtech
`System was deployed at least as of 2009.
`
`The ViVOtech System included a mobile device that ran the ViVOwallet software, which displyed contactless card applets
`appropriate for the mobile device, and received contactless card apples selected by the user. See, e.g., ViVOtech RF-Based
`Contactless Payment, White Paper Version 3.0, April 2006 (“White Paper”) at p. 28:
`
`11
`
`IPR2020-00019
`Fintiv EX2035 Page 11
`
`

`

`Chart B-5
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`Id. at p. 7:
`
`
`
`12
`
`IPR2020-00019
`Fintiv EX2035 Page 12
`
`

`

`Chart B-5
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`The teachings of this reference are explicitly directed to systems and methods wherein a contactless card applet is provisioned
`on a mobile device, and a POSITA at the relevant time would have been motivated to combine these teachings with other
`systems and methods in which a mobile device displays and receives a selection of a contactless card applet, such as those
`identified in Exhibit A.
`
`
`
`The Apple App Store. The Apple App
`Store was released on July 10, 2008.
`
`When a user accessed the Apple App Store on a mobile device such as an iPhone, the App Store displayed the software
`applications that correspond to the model of that mobile device and the version of the iOS operating system installed on it. See,
`e.g., iPhone iOS 3.1 User Guide (2009) at p. 169:
`
`13
`
`IPR2020-00019
`Fintiv EX2035 Page 13
`
`

`

`Chart B-5
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`The user could then select a software application of their choice and receive a download of it. See, e.g., id. at pp. 25, 167:
`
`
`
`
`
`14
`
`IPR2020-00019
`Fintiv EX2035 Page 14
`
`

`

`Chart B-5
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`
`
`Additionally, after the user downloaded a software application onto their mobile device, which is compatiable with the device’s
`model and operating sytem, the App Store server would notify the user when an updated version of that software was available
`so that they may download it. See id. at p. 172.
`
`Further, when a newer version of an installed app on the mobile device was available, the App Store would display a new
`version that is appropriate for the model of the mobile device at issue and notify the user th