Chart B-3
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Fintiv, Inc. v. Apple Inc., Case No. 1:19-CV-1238-ADA (W.D. Tex.)
`
`Wallet Management Applet
`
`CLAIM LIMITATIONS: “retrieving a…wallet management applet (WMA)” (’125 patent claim 11); “provisioning…the WMA” (’125 patent claim 11,
`16); “transmitting a request for installation of the…WMA to be installed” (’125 patent claim 16); “wherein the WMA is a software application
`configured to store account specific informattion” (’125 patent claim 16); “receiving…the WMA…through OTA proxy” (’125 patent claim 16); “a
`wallet management applet (WMA) corresponding to the contactless card applet, wherein the WMA is stored in the SE” (’125 patent claim 23); “an
`over-the-air (OTA) proxy configured to provision…the WMA” (’125 patent claim 23); and “where in the WMA is configured to store account
`information associated with the contactless card applet” (’125 patent claim 24).
`
`ASSERTED CLAIMS:
`
` These limitations are present in the following asserted claims: ’125 patent claims 11 and 23 (and their dependent claims).
`
`DISCLOSURE/MOTIVATION TO COMBINE: The Court construed “wallet management applet (MWA)” as “software that enables management of an
`electronic wallet including, but not limited to, the functionality of storing account specific information” (see Markman Order, Dkt. 86) and Fintiv’s
`Infringement Contentions state that WMA includes “a software component related to management of credit card applets.” See Infringement
`Contentions, Ex. A at 18. Under Fintiv’s interpretation of WMA and the Court’s construction, mobile devices that comprised a WMA, including
`mobile devices that stored such an applet within a secure element, were well-known to persons of ordinary skill in the art at the time of the alleged
`inventions of the Asserted Patent. 1
`
`The ’125 patent specification states that “WMA 21 may include both a WMA 21 container and one or more WMA 21 applets. WMA 21 container
`may manage the information stored in the WMA 21 applets.” ’125 patent at 7:8-11. With respect to the WMA container, the ’125 patent states that
`it may be a “software application that may reside within the SE of the mobile device 100 to manage account information related to the contactless
`card applet 23 (i.e. WMA 21 applet) that may be typically inaccessible by the user.” Id. at 7:16-20. Provisional application No. 61/428,846 which is
`incorporated by reference states: “[0042] The WMA 21 is a software application to reside within the within the secure element of the mobile device
`which stores account specific information such as a credit card number. WMA 21 is unique in that, its primary purpose is to cause contactless card
`applet 23 account information to be stored within the mobile device’s SE separate from the contactless card applets 23. As the issuers of contactless
`
`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 EX2033 Page 1
`
`

`

`Chart B-3
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`card applets 23 do not allow direct access into the applets themselves, duplicate account information may be stored separately within the WMA 21 in
`order for the mobile wallet application to view account specific information (e.g. credit card number, security code, PIN, expiration date, and etc.).”
`Provisional application No. 61/428,851 which is incorporated by reference states: “[0089] … However, as mobile devices cannot access the payment
`applets directly, a separate WMA 501 is required for the management of mobile wallet cards stored within mobile wallet application. [0090] During
`the provisioning process, WMA 501 will store duplicate payment applet account information. so that mobile wallet application may access the
`account specific information stored within the SE. Like the contactless payment applets, WMA 501 is stored in a 20 separate security domain within
`the SE.”
`
`In its Preliminary Infringement Contentions, Fintiv states that a WMA is “e.g. a software component related to management of credit card applets.”
`See, e.g., Preliminary Infringement Contentions, Ex. A at p. 18. Under Fintiv’s interpretation of WMA, “software component[s] related to
`management of credit card applets” were well-known to POSITAs at the time of the alleged invention and using such software would have been
`obvious to a POSITA in view of the references cited below. It would have been obvious to modify a system or method wherein a contactless card
`applet is provisioned on a mobile device so that a corresponding WMA is also provisioned.
`
`As reflected by the references below, it was well-understood for a mobile device to provision a WMA. A POSITA would have been motivated to
`implement this standard practice to achieve the benefits of ensuring that information stored within a contactless card applet is accessible to the mobile
`device user, allowing users electronic access to their financial information (e.g., credit card number) when travelling, to make purchases without
`needing their physical wallet, to backup and restore their information, to change or update their own financial information (e.g., upon receiving a card
`with a new expiration date), and to minimize the number of card or devices that a user must carry with them. See, e.g., Ilium eWallet (“Ilium
`Software is very pleased to announce eWallet™! Now you can have all your important information in a format that's secure, easy to access,
`centralized and portable!”) https://web.archive.org/web/19980109044321/http://iliumsoft.com/wallet.htm; Buhot EP 481 at ¶ 39 (“The database
`element 316 may interface with the user interface element 224 to provide at least some or all of the following services and APDU commands:
`Commands to set/get the Application Identifier (AID) of the different NFC application ele-ments 302-312 stored in the NFC unit 218. AID is the
`standardised way to identify ap-plications in a smart card according to the ISO 7816 and Global Platform standards. The AID may be listed per
`service, use case or activity, such as payment, transport, ticketing, loyalty, etc. The set/get commands can, for example, retrieve the list of the
`different NFC application elements for payment; Command to set/get the default AID of a NFC application element when further NFC appli-cation
`elements are related to the same use case or activity such as in the case where there are multi-card payment application elements; and Commands to
`manage a pool of Contactless Application Lock Codes (CALC) or similar se-curity codes for the NFC application elements. These commands allow
`verifying / chang-ing / activating / deactivating / unblocking the security codes.”); Aiglstorfer at ¶ 37 (“The remote server 130, in response to the
`notification 109, automatically transmits 111a second moblet software module to the first moblet software module 106. It is appreciated that the
`second moblet software module may be an application related to the first banking card infor-mation 105. The first moblet software module 106 may
`receive and install the second moblet software module 108 on the electronic device 110. As a result, the first banking card information 105 may be
`used in conjunction with the execution of the second moblet software module 108 to enable the user to interact with the second moblet software
`
`2
`
`IPR2020-00019
`Fintiv EX2033 Page 2
`
`

`

`Chart B-3
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`module 108 and the first banking card information 105 associated there-with. It is appreciated that the second moblet software module 108 may be a
`GUI type application that when executed enables user interaction therein to perform banking features.”); Kumar at ¶ [0050] (“In block 312, the NFC
`enabled handset displays the prepaid card as a softcard. In one embodiment, the wallet client in mobile device 114 displays the electronic prepaid
`card, which is a graph-ical representation associated with the stored personalization data, as a softcard.”).
`
`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
`
`European Patent Publication No. 2211481
`A1 (“Buhot EP 481”). Buhot EP 481 was
`filed on January 26, 2009 and published on
`July 28, 2010.
`
`See, e.g.:
`
`• Buhot EP 481 at ¶ 36 (“In an example shown in FIG. 3, a database element 316 is stored in the NFC unit 218 for
`storing summary information for the NFC application elements 302-312 stored in the NFC unit 218. In an example,
`the database element may be an NFC application element. The summary information may include at least one
`parameter of each of the NFC application elements 302-312 such as a graphical representation (e.g. a logo, animation
`or other brand image) or other identifier of the NFC service associated with the NFC application element (such as a
`jingle or the Application Identifier (AID)). The summary information may also or instead include personalised
`information or parameters for one or more NFC application elements in accordance with details of the user. For
`example, in the case of a payment application element, the personalised information may include the personal account
`number, cryptographic keys, or CALC. The summary information may also or instead include a list of the NFC
`services associated with the NFC application elements 302-312 stored in the NFC unit 218, a list of the NFC
`application elements 302-312 and/or a list of the available NFC services grouped according to the type of NFC
`service. For example, the summary information may include a list of the different NFC services such as payment,
`transport, ticketing or others the NFC unit 218 offers, and/or a list of the available payment cards, a list of the
`available loyalty cards and/or a list of the available transport tickets.”).
`• Buhot EP 481 at ¶ 37 (“The information provided to the user by the user interface element 224 may be obtained from
`the summary information stored in the database element 316. In an example, the user interface element 224 interfaces
`with the database element 316 through APDU commands which are defined according to the format defined in ISO
`14443-4 or ISO 7816-4.”).
`• Buhot EP 481 at ¶ 38 (“The database element 316 is a standalone application that does not interface or share data with
`other NFC application elements stored in the NFC unit 218. The summary information may be provided to the
`
`3
`
`IPR2020-00019
`Fintiv EX2033 Page 3
`
`

`

`Chart B-3
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`database element 316 (as with the user interface element 224) when the NFC application elements are stored in the
`NFC unit 218, for example when the NFC application elements are loaded and installed or personalised in the NFC
`unit 218.”).
`• Buhot EP 481 at ¶ 39 (“The database element 316 may interface with the user interface element 224 to provide at least
`some or all of the following services and APDU commands: Commands to set/get the Application Identifier (AID) of
`the different NFC application ele-ments 302-312 stored in the NFC unit 218. AID is the standardised way to identify
`ap-plications in a smart card according to the ISO 7816 and Global Platform standards. The AID may be listed per
`service, use case or activity, such as payment, transport, ticketing, loyalty, etc. The set/get commands can, for
`example, retrieve the list of the different NFC application elements for payment; Command to set/get the default AID
`of a NFC application element when further NFC appli-cation elements are related to the same use case or activity such
`as in the case where there are multi-card payment application elements; and Commands to manage a pool of
`Contactless Application Lock Codes (CALC) or similar se-curity codes for the NFC application elements. These
`commands allow verifying / chang-ing / activating / deactivating / unblocking the security codes.”).
`• Buhot EP 481 at ¶ 50 (“….The NFC unit 218 can update the content of the database element 316 and/or the NFC
`application elements 302-312 based on the received update information received from the receiving element 226. In
`the case of modifications to the NFC application elements 302-312 which should be reflected in the user interface in
`the mobile application elements 318-328, the content of the database element 316 is also updated. Thus, the database
`element 316 is updated during OTA sessions to reflect the changes in the NFC unit 218 that have an impact on the
`user interface….”).
`• Buhot EP 481 at ¶ 59 (“In this example, the user interface element 224 manages a set of three contactless payment
`application elements that are stored in the NFC unit 218 that includes, in this example, a UICC card 220. A database
`element 316 is present in the UICC card 220. This database element 316 can be dynamically
`loaded/installed/personalized. The user interface element 224 manages one CALC/security code per contactless
`payment application element in the UICC card 220. These payment application elements do not support the
`CALC/security code feature by default. The database element 316 is used to manage the security code/CALC feature
`on behalf of the payment application elements.”).
`• Buhot EP 481 at ¶ 69 (“In devices having the database element, the database element can support the dynamic storage
`of summary information for the NFC application elements stored in the NFC unit, such as a list of the NFC services, a
`list of the application elements and their properties which summary information can be dynamically updated when the
`NFC services are updated OTA.”).
`See also Buhot EP 481 at Fig. 3.
`•
`• 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
`
`4
`
`IPR2020-00019
`Fintiv EX2033 Page 4
`
`

`

`Chart B-3
`
`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.
`
`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 [0043] (“The parameters, including the personalisation information, may be stored in the
`memory 402 of the NFC unit 218 or a separate memory (not shown) of the NFC unit 218 or for example in the case of
`branding information may be stored in the mobile device 102.”).
`
`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 contactless card applets are provisioned on a mobile device, such as those identified in Exhibit
`A.
`
`See, e.g.:
`“In the example shown in FIG. 2, the program memory 216 stores specific program elements for controlling the
`•
`operation of the mobile device 102 by means of the processing unit 200 which include a user interface element 224,
`and a plurality of NFC managing elements (represented as group by 226 in FIG. 2). Each of the plurality of NFC
`managing elements is associated with at least one of the plurality of application elements stored in the NFC unit 218
`for managing the at least one associated application element of the plurality of application elements. The user
`interface element 224 is for interfacing with at least some of the NFC managing elements, and for providing
`information to a user relating to the NFC services provided by the plurality of application elements associated with the
`at least some of the NFC managing elements.” ¶46.
`“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, 93-95, 101, 11, 113, 115, 117.
`• Fig. 3
`
`•
`
`5
`
`IPR2020-00019
`Fintiv EX2033 Page 5
`
`

`

`Chart B-3
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`
`
`•
`
`“In an example, a syncML DM protocol, which is a Device Management (DM) protocol using XML for data
`exchange defined by the Open Mobile Alliance (OMA), is used to connect the mobile device 102 to the OTA server
`112. The receiving element 226 in this example therefore comprises an OMA DM engine (not shown) and an OMA
`DM NFC plug-in module (not shown) connected to the OMA DM engine to run in the processing unit 200 to control
`the data exchange between the mobile device 102 and the OTA server 112. The receiving element 226 is not part of
`the user interface element 224 and runs in a different process and so is independent from the user interface element
`224. The receiving element 226 determines that the received data from the OTA server 112 is NFC update information
`(e.g. from the format) and transfers the received update information, which comprises data packets, to the NFC unit
`218, for example via a ISO link. Before transferring the received update information to the NFC unit 218, the
`receiving element 226 may process the received update information and translate them into APDU commands. The
`processor 400 of the NFC unit 218 then processes the received data packets updates the NFC unit 218 according to the
`received update information. The NFC unit 218 can update the content of the database element 316 and/or the NFC
`application elements 302-312 based on the received update information received from the receiving element 226. In
`the case of modifications to the NFC application elements 302-312 which should be reflected in the user interface in
`the mobile application elements 318-328, the content of the database element 316 is also updated. Thus, the database
`element 316 is updated during OTA sessions to reflect the changes in the NFC unit 218 that have an impact on the
`
`6
`
`IPR2020-00019
`Fintiv EX2033 Page 6
`
`

`

`Chart B-3
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`•
`
`•
`
`•
`
`•
`
`user interface. The response from the NFC unit 218 is sent back to the OTA server 112 through the OMA DM NFC
`plug-in module and OMA DM engine.” ¶68 (742); see also ¶69-89.
`“In an example shown in FIG. 3, a database element 316 is stored in the NFC unit 218 for storing summary
`information for the NFC application elements 302-312 stored in the NFC unit 218. In an example, the database
`element may be an NFC application element. The summary information may include at least one parameter of each of
`the NFC application elements 302-312 such as a graphical representation (e.g. a logo, animation or other brand image)
`or other identifier of the NFC service associated with the NFC application element (such as a jingle or the Application
`Identifier (AID)). The summary information may also or instead include personalised information or parameters for
`one or more NFC application elements in accordance with details of the user. For example, in the case of a payment
`application element, the personalised information may include the personal account number, cryptographic keys, or
`CALC. The summary information may also or instead include a list of the NFC services associated with the NFC
`application elements 302-312 stored in the NFC unit 218, a list of the NFC application elements 302-312 and/or a list
`of the available NFC services grouped according to the type of NFC service. For example, the summary information
`may include a list of the different NFC services such as payment, transport, ticketing or others the NFC unit 218
`offers, and/or a list of the available payment cards, a list of the available loyalty cards and/or a list of the available
`transport tickets.” ¶99; see also ¶¶101, 127; Fig. 3.
`“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.” ¶111.
`“In the case of updates to a NFC service, in the example shown in FIG. 1 update information for a NFC service are
`held by a NFC service provider server 114 and sent to the OTA server 112 for transmission to the mobile device 102.
`Only one NFC service provider server 114 is shown in FIG. 1. It will however be appreciated that there may be more
`than one NFC service provider server 114 associated with the same or different service provider. The NFC service
`provider servers may be controlled and managed directly by the service provider e.g. a bank or airline, or by a third
`party managing the NFC service updates for a service provider. Although not shown in the example shown in FIG. 1,
`the update information for the NFC application elements may be sent by the OTA server 112 under the control of a
`Certification Authority (not shown) in order to enhance the security of the update process. The Certification Authority
`(not shown) manages the security of the data exchange through mutual authentication or data ciphering and signing
`based on cryptographic keys the servers share with the NFC unit 218. The Certification Authority may be part of the
`OTA server or separate. The OTA server 114 is thus able to load, install, update and personalise NFC application
`elements in the NFC unit 218.” ¶111.
` “The OTA server 112 communicates with the mobile device 102 over the RF communication link 108. For example,
`the user may receive at the RF receiving section 202 a notification message, such as a binary SMS as per the OMA-
`DM specification, that informs the user that the content of the NFC unit 218 is to be updated. The binary SMS is
`targeted to launch the OTA client on the phone (OMA DM NFC plug-in module in this case) which then connects to
`
`7
`
`IPR2020-00019
`Fintiv EX2033 Page 7
`
`

`

`Chart B-3
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`the OTA server 112. Alternatively, a OTA session update can be triggered by the user who can start it manually, for
`example, through the browser by reaching a specific URL (for example, a URL that has been bootstrapped by a OMA-
`DM server), by calling a specific phone number, by reading an NFC tag that contains the connection information, or
`by other suitable ways.” ¶84 (742); see also 82-83.
`“In an example shown in FIG. 3, a database element 316 is stored in the NFC unit 218 for storing summary
`information for the NFC application elements 302-312 stored in the NFC unit 218. In an example, the database
`element may be an NFC application element. The summary information may include at least one parameter of each of
`the NFC application elements 302-312 such as a graphical representation (e.g. a logo, animation or other brand image)
`or other identifier of the NFC service associated with the NFC application element (such as a jingle or the Application
`Identifier (AID)). The summary information may also or instead include personalised information or parameters for
`one or more NFC application elements in accordance with details of the user. For example, in the case of a payment
`application element, the personalised information may include the personal account number, cryptographic keys, or
`CALC. The summary information may also or instead include a list of the NFC services associated with the NFC
`application elements 302-312 stored in the NFC unit 218, a list of the NFC application elements 302-312 and/or a list
`of the available NFC services grouped according to the type of NFC service. For example, the summary information
`may include a list of the different NFC services such as payment, transport, ticketing or others the NFC unit 218
`offers, and/or a list of the available payment cards, a list of the available loyalty cards and/or a list of the available
`transport tickets.” ¶99; see also ¶¶101, 127; Fig. 3.
`
`“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.”
`¶108.
`“The user interface element in accordance with the examples described above may also provide a service for installing
`new NFC managing elements and/or new application elements by downloading them OTA. After a successful loading
`
`•
`
`•
`
`•
`
`8
`
`IPR2020-00019
`Fintiv EX2033 Page 8
`
`

`

`Chart B-3
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`U.S. Patent Publication No. 2010/0138518
`A1 (“Aiglstorfer”). Aiglstorfer filed on
`November 18, 2009 and published on June
`3, 2010.
`
`•
`
`the NFC managing elements may be automatically registered to the user interface element.” ¶119; see also ¶117-118,
`55, 93-95, 101, 46.
`“The user interface element in accordance with the disclosure can dynamically manage NFC application elements so
`as to trigger a NFC service, or update the NFC services provided by the mobile device. The updating of the NFC
`services may include installing a new NFC service by adding a new application element, updating an existing NFC
`service by updating one or more parameters of an existing application element or removing a NFC service by
`removing an application element.” ¶126; see also ¶113, 114.
`
`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 contactless card applets are provisioned on a mobile device, such as those identified in Exhibit
`A.
`
`See, e.g.:
`
`• Aiglstorfer at paragraph [0010] (“The method includes receiving, at the electronic wallet, card information, e.g.,
`banking information associated with the card, for an account and storing the card information into a secure memory
`within the electronic wallet. Responsive to the receiving, a first moblet software module automatically sends a
`wireless message via a wireless network to a remote server to inform the remote server of the card information being
`received at the electronic wallet. The electronic wallet receives a second moblet software module associated with the
`banking card information. The electronic wallet executes the second moblet software module that utilizes the card
`information. According to one embodiment, the first and second moblet software modules comprise device
`independent commands of a generic syntax and wherein further the commands are executed by a device dependent
`software module also resident on the electronic wallet.”).
`• Aiglstorfer at paragraph [0013] (“According to one embodiment, the electronic wallet may receive card information,
`e.g., banking information, associated with a second account and storing the card information for the second account
`into the secure memory within the electronic wallet. Responsive to the receiving, the first moblet software module
`may automatically send a wireless message, via a wireless network, to the remote server to inform the remote server
`of the card information for the second account being received at the electronic wallet. The electronic wallet further
`receives a third moblet software module associated with the banking card information for the second account. The
`electronic wallet may execute the third moblet software module that utilizes the card information for the second
`account. In one embodiment of the present invention the third moblet software module comprises device independent
`commands of the generic syntax and wherein further the commands are executed by the device dependent software
`module.”).
`
`9
`
`IPR2020-00019
`Fintiv EX2033 Page 9
`
`

`

`Chart B-3
`
`Invalidity Contentions: U.S. Patent No. 8,843