Chart B-2
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Fintiv, Inc. v. Apple Inc., Case No. 1:19-CV-1238-ADA (W.D. Tex.)
`
`Retrieving/Capturing Secure Element (SE) Information
`
`CLAIM LIMITATIONS: “retrieving mobile device information comprising SE information” (’125 patent claim 14) and “wherein said OTA proxy is
`configured to capture mobile device information comprising SE information” (’125 patent claim 23).
`
`ASSERTED CLAIMS: These limitations are present in the following asserted claims: ’125 patent claims 14 and 23 (and their dependent claims).
`
`DISCLOSURE/MOTIVATION TO COMBINE:
` The Court construed “SE information” as “information that is about or related to the SE including, but
`not limited to, production life cycle, card serial number, card image number, and integrated circuit card identification” (see Markman Order, Dkt. 86)
`and Fintiv’s Infringement Contentions state that “SE info [includes] Card Production Life Cycle (CPLC), Card Serial Number (CSN), Card Image
`Number CIN), Integrated Circuit Card Identification (ICCID)) comprising SE information.” See Infringement Contentions, Ex. A at 100.”); see also
`id.at 36 (“SE information [includes] financial institution.”). Under Fintiv’s interpretation of these claim limitations and the Court’s construction,
`mobile devices that were capable of retrieving and/or capturing information about their own secure element were well-known at the time of the
`alleged inventions of the Asserted Patent.1
`
`Accordingly, known prior art systems or methods in which a mobile device retrieves and/or captures information relating to its secure element would
`teach these well-known claim limitations, and it would have been obvious to a POSITA to modify a system or method wherein software is
`provisioned on a mobile device and/or a mobile device registers a mobile wallet application with a TSM so that either of those processes involve the
`retrieval of SE information. Moreover, to the extent SIM cards, UICC (Universal Integrated Circuit Card), embedded SE, and/or micro SD
`cards/chips are secure elements, retrieving information from and/or about those componenets was also well-known to POSITA at the time of the
`alleged invention. For example, SD Card Association announced the microSD format at CTIA Wireless 2005 on March 14, 2005, and the final
`microSD details were announced on July 13, 2005. https://simple.wikipedia.org/wiki/MicroSD. And UICC/SIM cards have existed for many years
`before that. Smart cards were sold worldwide as early as 1991 by manufacturers such as Giesecke & Devrient. https://www.gi-de.com/en/us/g-d-
`group/about-us/history/. ETSI released the SIM standard, TS 11.11, shortly thereafter, and a technical specification for UICC cards in particular was
`released as early as 1999. https://www.etsi.org/deliver/etsi_ts/102200_102299/102221/03.00.00_60/ts_102221v030000p.pdf. For most, if not all,
`
`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 EX2032 Page 1
`
`

`

`Chart B-2
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`telephone calls made on GSM mobile devices, all of which require a SIM card, the mobile device receives the SIM card’s identifying number (the
`ICCID number) and/or the MSISDN (which contains the user’s telephone number) from the SE and transmits it to the carrier.
`
`As reflected by the prior art references and citations below, it was well-understood by POSITAs that software (e.g., an OTA proxy) on a mobile
`device retrieved and/or captured its own SE information. A POSITA would have been motivated to implement this standard practice to advance a
`number of goals, including: 1) ensuring secure registry of the mobile device or the SE with a TSM, 2) allowing for software to be securely
`provisioned onto the device and/or the SE; 3) to allow a TSM and the mobile device and/or SE to synchronize, backup, or otherwise maintain data; 4)
`to allow the secure verification of a removable SE when it has been transferred from one mobile device to another; and 5) to allow the recipient of a
`telephone call to verify the identity of the caller and/or their SE. See, e.g., Pesonen at 8:21-43, 11:1-11 (“….the invention can be used to securely
`generate Issuer Security Domain keys of a Global Platform Java card, whereby the initialized chip will contain Issuer Security Domain with chip-
`specific keys, which keys have been generated from issuer-specific master keys diversified with the unique chip serial number. The unique chip serial
`number may be constructed, for example, from the card production life cycle (CPLC) data on the secure element chip. It may be constructed from
`several CPLC data fields, such as the IC fabrication date, the IC serial number, and the IC batch identifier….in certain embodiments, before
`encrypted communication can take place, the issuer 230 must have the unique chip serial number and the master keys for the target device. As
`discussed above, the device vendor 220 returns the unique chip serial numbers to the issuer 230 after the successful initialization of the mobile
`device. Alternatively, an issuer without the unique chip serial number may obtain that number from other public sources, or from the device
`itself….”); Bauer at 7:29-36, 7:48-54 (“The mobile device 3 may also include one or more other third party application modules 44 stored in the
`secure memory 4, for example an application module related to third party loyalty scheme. The secure memory 4 may also stores a UICC applet 45
`which is an application to manage and hold the mobile network operator's functionality and secure information, such as a network key and GSM
`PIN…. 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.”).
`
`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.
`
`
`2
`
`IPR2020-00019
`Fintiv EX2032 Page 2
`
`

`

`Chart B-2
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`U.S. Patent No. 7,699,233 to Pesonen
`(“Pesonen”). Pesonen was filed on filed on
`November 2, 2005, published on May 3,
`2007, and issued on April 20, 2010.
`
`See, e.g.:
`
`• Pesonen at 2:46-57 (“In light of the foregoing background, embodiments of the present invention provide an improved
`method for installing and initializing secure element chips into mobile devices. In one aspect of the present invention,
`a smart card manufacturer creates smart cards with embedded but uninitialized secure element chips. The smart cards
`are shipped to a mobile device manufacturer/vendor in an uninitialized state, rather than prepersonalized to a specific
`issuer. The uninitialized smart cards may contain pre-installed encryption keys and a unique chip serial number, and
`may support an initialization routine that can be invoked by the device vendor to personalize the secure element to a
`specific issuer.”).
`• Pesonen at 5:1-22 (“According to embodiments of the present invention, the pre-installed root keys may be the same
`for each individual smart card manufactured, and will only later be diversified by the issuer-specific seed and unique
`chip serial numbers. This process is discussed in detail below. Also, note that the uninitialized smart cards contain
`other data besides the pre-installed root keys, such as the MAC seed, transfer key, and unique chip serial number,
`which are discussed in detail below…Only the unique chip serial number, which is a permanent and unchangeable
`value, might be public information accessible to the device vendor 220.”).
`• Pesonen at 5:55-63 (“In contrast, the unique chip serial number may be public information, readily available to the
`device vendor. Certain embodiments of the present invention involve occasions where the device vendor 220 is
`unsecure or untrusted, and thus the pre-installed root keys, transfer key, and MAC seed, as well as the issuer seed,
`must remain completely inaccessible to a device vendor in possession of the uninitialized smart cards, the unique chip
`serial numbers, and the encrypted initialization data.”).
`• Pesonen at 6:27-39 (“The initialization routine, discussed in further detail below, will initialize the smart card
`embedded in the mobile device, personalizing the smart card chip for the issuer 230. The issuer 230 can now securely
`manage the device and provide mobile customers with secure data transfer capabilities. In step 208, the device vendor
`220 delivers the initialized mobile devices to the issuer 230 for distribution to retailers or consumers, along with the
`corresponding chip serial numbers of the secure element in each device. The issuer 230 may store these unique chip
`serial numbers in a secure database, to facilitate future communications with the mobile device. In step 209, the issuer
`230 distributes these personalized mobile devices to customers.”).
`• Pesonen at 7:51-57 (“The EEPROM 308 in FIG. 3 illustrates the initial state of the operating system. That is, FIG. 3
`shows the state of the secure element chip 302 when it is shipped from the smart card vendor 210 to the device vendor
`220. The uninitialized chip 302 has initial key values built into the EEPROM 308: the MAC seed 310, the transfer key
`312, the root keys 314, and the unique serial number 316.”).
`• Pesonen at 8:21-43 (“Each secure element chip 302 also initially contains a unique serial number 316 written typically
`into the OS system area of the EEPROM 308. However, according to other embodiments of the present invention,
`different arrangements for storing the unique serial number 316 can be made. Each secure element chip 302 is given a
`different serial number. In certain embodiments, the unique serial number is 16 digits long, and cannot be changed
`
`3
`
`IPR2020-00019
`Fintiv EX2032 Page 3
`
`

`

`Chart B-2
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`after it is written into the EEPROM 308. While the methods presented herein do not depend on a secure element
`operating system, certain embodiments involve secure elements running a JavaCard with Global Platform operating
`system. For example, the invention can be used to securely generate Issuer Security Domain keys of a Global Platform
`Java card, whereby the initialized chip will contain Issuer Security Domain with chip-specific keys, which keys have
`been generated from issuer-specific master keys diversified with the unique chip serial number. The unique chip serial
`number may be constructed, for example, from the card production life cycle (CPLC) data on the secure element chip.
`It may be constructed from several CPLC data fields, such as the IC fabrication date, the IC serial number, and the IC
`batch identifier.”).
`• Pesonen at 10:26-35 (“After the Successful execution of the initialization routine, the EEPROM 308 contains only the
`chip keys 518 and the unique chip serial number 316. As previously mentioned, while the methods presented herein
`do not depend on a secure element operating system, certain embodiments involve secure elements running a
`JavaCard with Global Platform operating system. In such embodiments, FIG.5 may correspond to the “GP ready”
`mode of the JavaCard Global Platform operating system, and the ROM 306 may store the Global Platform OS.”).
`• Pesonen at 10:53-58 (“To generate the chip keys for a specific secure element, the issuer 230 first obtains the unique
`chip serial number, which the device vendor 220 may send to the issuer, for example, for storage in the issuer’s
`database. The issuer 230 may then diversify the master keys with the unique chip serial number.”).
`• Pesonen at 11:1-11 (“However, in certain embodiments, before encrypted communication can take place, the issuer
`230 must have the unique chip serial number and the master keys for the target device. As discussed above, the device
`vendor 220 returns the unique chip serial numbers to the issuer 230 after the successful initialization of the mobile
`device. Alternatively, an issuer without the unique chip serial number may obtain that number from other public
`sources, or from the device itself. However, the issuer 230 still needs the master keys corresponding to the serial
`numbers before communicating with the device USC.”).
`• Pesonen at 11:43-47 (“Once the chip keys are securely embedded into the mobile device, and the issuer 230 is in
`possession of the unique chip serial numbers and the corresponding master keys, encrypted over-the-air (OTA)
`transactions can take place between the issuer 230 and the mobile device.”).
`• Pesonen at Fig. 7:
`
`4
`
`IPR2020-00019
`Fintiv EX2032 Page 4
`
`

`

`Chart B-2
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`The teachings of this reference are explicitly directed to systems and methods wherein software is provisioned on a mobile
`device and/or a mobile device registers a mobile wallet application with a TSM, and a POSITA at the relevant time would have
`been motivated to combine these teachings with other systems and methods in which software is provisioned on a mobile
`device and/or a mobile device registers a mobile wallet application with a TSM, such as those identified in Exhibit A.
`
`
`
`5
`
`IPR2020-00019
`Fintiv EX2032 Page 5
`
`

`

`Chart B-2
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`GlobalPlatform Card Specification, Version
`2.2 (“GlobalPlatform Specification”) was
`published in March 2006.
`
`See, e.g.:
`
`• GlobalPlatform Specification at p. 5 (“Card Image Number (CIN) An identifier for a specific GlobalPlatform card”).
`• GlobalPlatform Specification at p. 5 (“Card Recognition Data Information that tells an external system, in particular a
`Smart Card Management System (SCMS), how to work with the card (including indicating that this is a
`GlobalPlatform card)”).
`• GlobalPlatform Specification at p. 8 (“CIN Card Image Number / Card Identification Number”).
`• GlobalPlatform Specification at p. 11 (“1.5.2.5 Card Recognition Data A concerted effort was made to ensure that
`there would be a uniform method to determine basic information about a card. The Card Recognition Data and the
`method for retrieving this data have been included in this version of the GlobalPlatform Card Specification.
`Information such as: this is a GlobalPlatform card, implemented in a particular way, and with a particular version
`number is now available.”).
`• GlobalPlatform Specification at p. 62 (“The Issuer Security Domain shall be able to handle the following data…Card
`Image Number (CIN)”).
`• GlobalPlatform Specification at p. 63 (“7.4.1.2 Card Image Number The Card Image Number (CIN) may be used by a
`Card Management System to uniquely identify a card within its card base. It is a unique value, carried by the ISO/IEC
`7816 defined tag ‘45’ (Card Issuer’s Data), which is assigned by the Card Issuer (identified itself by the IIN). The CIN
`data element is of variable length.”).
`• GlobalPlatform Specification at p. 63 (“7.4.1.3 Card Recognition Data Card Management Systems need information
`about a card before they can start to interact with it. This includes the kind of card it is and what Secure Channel
`Protocol it supports. Card Recognition Data is the mechanism for providing information about a card, and thus
`avoiding the vagaries of trial-and-error. See appendix H for details. Card Recognition Data shall be present and
`contained in a data template (tag ‘73’). This template shall in turn be contained in the “Card Data” data object (tag
`‘66’), as defined in ISO/IEC 7816-6. Card Data can be retrieved using the GET DATA command. (For contact cards
`according to ISO/IEC 7816-4, Card Data may also be accessed through the ATR, if a suitable “command to perform”
`is included in the ATR historical bytes.) Note that the information provided in Card Recognition Data should be
`enough to enable initial communication with the card without resorting to trial and error. Information not essential for
`this purpose should be supplied during subsequent interaction with the card. There is no specific requirement for Card
`Recognition Data to be updated dynamically by the card, but additional dynamic data objects are not precluded.”).
`• GlobalPlatform Specification at p. 354 (“Tag ‘63’: The OID {globalPlatform 3} indicates a GlobalPlatform card that
`is uniquely identified by the Issuer Identification Number (IIN) and Card Image Number (CIN), as defined in sections
`7.4.1.1 - Issuer Identification Number and 7.4.1.2 - Card Image Number. The objective is that an off-card entity is
`able to construct a globally unique identifier for the card by concatenating this {globalPlatform 3} OID, the IIN and
`the CIN.”).
`
`6
`
`IPR2020-00019
`Fintiv EX2032 Page 6
`
`

`

`Chart B-2
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`U.S. Patent No. 9,558,481 to Bauer
`(“Bauer”). Bauer was filed on September
`28, 2010, published on March 29, 2012, and
`issued on January 31, 2017.
`
`• GlobalPlatform Specification at p. 355 (“Tag ‘66’: this data object may contain information about the card and chip
`implementation, such as the operating system/runtime environment or a security kernel. Such information shall be
`TLV encoded and may consist of one (or more) OID(s), each OID being introduced by tag ‘06’ and indicating the
`organization responsible for specifying the operating system, runtime environment or security kernel, and the
`identification of the corresponding specification and its version number.”).
`
`The teachings of this reference are explicitly directed to systems and methods wherein software is provisioned on a mobile
`device and/or a mobile device registers a mobile wallet application with a TSM, and a POSITA at the relevant time would have
`been motivated to combine these teachings with other systems and methods in which software is provisioned on a mobile
`device and/or a mobile device registers a mobile wallet application with a TSM, such as those identified in Exhibit A.
`
`See, e.g.:
`
`•
`
`•
`
`•
`
`•
`
`•
`
`“The account creation server 17 may create the mobile payment account data 6 including data from the em-bossing
`data file received from the payment account issuer 10 as well as additional data pertaining to the mobile device 3 and
`to the mobile user requesting the new account which will be used in the mobile ac-count activation process. The
`mobile payment account data 6 may then be passed to the TSM server 18 via the middleware 16, which may perform
`logical data preparation of the received mobile payment ac-count data 6 by forming appropriate commands to be
`written to the secure memory 4 of the mobile device 3…The TSM server 18 may then passes the encrypted payment
`account data 6 of the provisioned inac-tive mobile payment account to the mobile device 3 via the communications
`server 13 and the cellular tel-ephone network 11.” Bauer at 5:9-31.
`“The mobile device 3 may also include one or more other third party application modules 44 stored in the secure
`memory 4, for example an application module related to third party loyalty scheme. The secure memory 4 may also
`stores a UICC applet 45 which is an application to manage and hold the mobile network operator's functionality and
`secure information, such as a network key and GSM PIN.” Bauer at 7:29-36.
`“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.” Bauer at 7:48-54.
`“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.” Bauer at 8:1-5.
`See also Bauer at Figs. 2, 3a.
`
`7
`
`IPR2020-00019
`Fintiv EX2032 Page 7
`
`

`

`Chart B-2
`
`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.
`
`The teachings of this reference are explicitly directed to systems and methods wherein software is provisioned on a mobile
`device and/or a mobile device registers a mobile wallet application with a TSM, and a POSITA at the relevant time would have
`been motivated to combine these teachings with other systems and methods in which software is provisioned on a mobile
`device and/or a mobile device registers a mobile wallet application with a TSM, such as those identified in Exhibit A.
`
`See, e.g.:
`
`•
`
`•
`
`•
`
`“notifyForChanges: the user interface element 224 is notified of changes occurring in the caller NFC managing
`element. The NFC managing element should have registered previously with the addManaging interface for this
`interface to be valid. Changes might be in the NFC managing element itself or in the NFC application elements in the
`NFC unit 218 associated with the NFC managing element. For example, changes might include updates, deletions, or
`even modifications of properties and may include changes made Over-The-Air (OTA).” ¶63; see also ¶107, 110, 119.
`“The OTA server 112 has the capability to update (e.g. load/install/personalize/delete) the payment application
`elements in the UICC card 220.” ¶82 (742); see also ¶68-75; 83-89.
`“A mobile phone that supports NFC, and for example the card emulation mode, contains a secure element for storing
`different NFC application elements for use in providing the NFC services. The secure element may be a dedicated
`module or chipset that is part of the mobile phone or may be a removable component, such as the UMTS Integrated
`Circuit Card (UICC) also known as the SIM card or USIM card or a removable memory card.” ¶16; see also ¶42, 45-
`46; Fig. 4.
`
`The teachings of this reference are explicitly directed to systems and methods wherein software is provisioned on a mobile
`device and/or a mobile device registers a mobile wallet application with a TSM, and a POSITA at the relevant time would have
`been motivated to combine these teachings with other systems and methods in which software is provisioned on a mobile
`device and/or a mobile device registers a mobile wallet application with a TSM, such as those identified in Exhibit A.
`
`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.:
`
`•
`
`•
`
`“A mobile phone that supports NFC, and for examplethe card emulation mode, contains a secure element for storing
`different NFC application elements for use in providing the NFC services. The secure element may be a dedicated
`module or chipset that is part of the mobile phone or may be a removable component, such as the UMTS Integrated
`Circuit Card (UICC) also known as the SIM card or USIM card or a removable memory card.” Buhot EP 481 ¶ 6.
`“As mobile phones accumulate new applications and become more advanced, Over-The-Air configuration has been
`used increasingly for distribution of new software updates to mobile phones or provisioning mobile phones with the
`
`8
`
`IPR2020-00019
`Fintiv EX2032 Page 8
`
`

`

`Chart B-2
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`“Trusted Service Manager: The Key to
`Accelerating Mobile Commerce” (“TSM”).
`TSM was published in 2009.
`
`necessary settings with which to access new services such as WAP or MMS. The updates may include software
`updates from phone manufacturers or network operators or other third parties to software held in the mobile phone.
`Typically, mobile phones are updated OTA via data packets sent to the RF sections of the mobile phones from OTA
`servers which messages can provide remote control of mobile phones for service and subscription activation,
`personalisation and programming of a new service for mobile network operators and telecom third parties.” Buhot EP
`481 ¶ 41.
`“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 ¶ 44.
`“The OTA server 112 has the capability to update (e.g. load/install/personalize/delete) the payment application
`elements in the UICC card 220.” Buhot EP 481 ¶ 61.
`See also Buhot EP 481 at Fig. 1, ¶¶ 45-54, 57, 62-64, 66, 68-69.
`
`•
`
`•
`
`•
`
`The teachings of this reference are explicitly directed to systems and methods wherein software is provisioned on a mobile
`device and/or a mobile device registers a mobile wallet application with a TSM, and a POSITA at the relevant time would have
`been motivated to combine these teachings with other systems and methods in which software is provisioned on a mobile
`device and/or a mobile device registers a mobile wallet application with a TSM, such as those identified in Exhibit A.
`
`See, e.g.:
`
`•
`
`•
`
`•
`
`“The only practical way to get personal account information into an individual’s phone is through the mobile
`operator’s wireless network. Account information is transmitted to the mobile phone by a process called over-the-air
`(OTA) provisioning. This transmission can be difficult to accomplish without the active cooperation of mobile
`network operators.” TSM at p. 4.
`“Provisioning needs to be done over the air (OTA) and in real time: With OTA provisioning, a user doesn’t have to go
`to a store or a service center to have NFC applications installed or to add personalization data. For example, users can
`search a repository of approved NFC applications using their phone (after they are authenticated), and choose to
`download the applications they want. All of these OTA updates must occur over mobile carrier networks. This means
`that whoever provisions to NFC phones also needs to have strong relationships with multiple carriers.” TSM at p. 6.
`“OTA Provisioning and Handset Management The TSM must be able to support the technical process for over-the-air
`(OTA) provisioning across different MNOs. This includes first-time provisioning of new applications to a secure
`element and post-issuance updates and content delivery. The TSM also maintains information about handsets, chipsets
`and handset software (e.g., electronic wallet) required to ensure successful OTA provisioning to a variety of devices.
`
`9
`
`IPR2020-00019
`Fintiv EX2032 Page 9
`
`

`

`Chart B-2
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`“The SIM-Based Mobile Wallet” (“SIM”).
`SIM was published in 2009.
`
`TSM systems maintain information about the life cycles of MNOs, MNO end-customers and the mobile handsets of
`MNO end-customers. The TSM role can also include the complex task of securely managing secure element and
`security domain keys, and their relationships to NFC applications and NFC application keys. All of the tasks outlined
`above that involve handling personal account information, security keys and user information will necessarily need to
`conform to industry security standards like PCI DSS.” TSM at p. 8.
`
`The teachings of this reference are explicitly directed to systems and methods wherein software is provisioned on a mobile
`device and/or a mobile device registers a mobile wallet application with a TSM, and a POSITA at the relevant time would have
`been motivated to combine these teachings with other systems and methods in which software is provisioned on a mobile
`device and/or a mobile device registers a mobile wallet application with a TSM, such as those identified in Exhibit A.
`
`See, e.g.:
`
`•
`
`•
`
`“Putting these virtual cards into one mobile wallet, hosted on the user’s mobile phone, offers a solution:
`• The next generation of SIM cards, the UICC (Universal Integrated Circuit Card) acts as a secure element being
`capable of hosting security-sensitive data and application components
`• Conceptually, there is no limitation for the number of cards. Search and sorting functions, policy-based card
`selection and other UI elements facilitate card access for the user in any application context
`• Card provision can securely be executed over the air.
`• The mobile phone accommodates multiple transmission technologies such as UMTS and NFC, thus supporting card
`application for both proximity and remote service access.” SIM at p. 1.
`“A web-based wallet application store is developed for showing the application provision process. On wallet client
`side, the user is able to get the update-to-date application list from the store, and downloads the new applications into
`his wallet. The Over-the-Air provisioning of the relevant JavaCard applet is as a part of the application download
`process.” SIM at p. 5.
`
`The teachings of this reference are explicitly directed to systems and methods wherein software is provisioned on a mobile
`device and/or a mobile device registers a mobile wallet application with a TSM, and a POSITA at the relevant time would have
`been motivated to combine these teachings with other systems and methods in which software is provisioned on a mobile
`device and/or a mobile device registers a mobile wallet application with a TSM, such as those identified in Exhibit A.
`
`U.S. Patent No. 6,832,373 to O’Neill
`(“O’Neill”). O’Neill was filed on April 1,
`
`See, e.g.:
`
`10
`
`IPR2020-00019
`Fintiv EX2032 Page 10
`
`

`

`Chart B-2
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`2003, published on October 28, 2004, and
`issued on December 14, 2004.
`
`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.
`
`Disclosure
`
`•
`
`•
`
`“One desirable feature of the update management System is that it may be readily adapted for use in wireless update
`procedures or over the air (OTA) updating.” O’Neill at 8:4-7.
`“In an exemplary application, the update management system may be used in conjunction with over the air updating
`of portable electronic devices, Such as cellular or mobile phones. Mobile communications technology is a rapidly
`changing field which strives to meet the rising demands and expectations of its users. Mobile phones are also
`microcomputing devices utilizing integrated operational system softwar