Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Fintiv, Inc. v. Apple Inc., Case No. 1:19-CV-1238-ADA (W.D. Tex.)
`
`Over-The-Air (OTA) Proxy / OTA Proxy
`
`CLAIM LIMITATIONS: “an over-the-air (OTA) proxy configured to provision the contactless card applet, a widget corresponding to the contactless
`card applet, and the WMA,” “wherein said OTA proxy is configured to capture mobile device information comprising SE information,” “wherein
`said OTA proxy is configured to transmit the mobile device information for registering the mobile wallet application” (’125 patent claim 23), and
`“receiving the contactless applet, the WMA, and the widget information through OTA proxy” (claim 16).
`
`ASSERTED CLAIMS:
`
` These limitations are present in the following asserted claim: ’125 patent claim 23 (and its dependent claims) and claim 16.
`
`DISCLOSURE/MOTIVATION TO COMBINE:
` The Court construed the “OTA proxy” limitations as “software, in conjunction with relevant hardware,
`that provisions contactless card applets, captures mobile device information (including SE information), transmits data (mobile device and SE
`specific information) to the TSM system, and receives APDU commands from the TSM and appropriately forwards them.” Markman Order (Dkt.,
`86). Even though the Court construed OTA proxy on Nov. 27, 2019, Fintiv’s proposed Amended Initial Disclosure of Asserted Claims, Accused
`Instrumentalities, and Ingringement Contentions (“Fintiv’s Proposed Amended Infringement Contentions) served on Dec. 6, 2019 do not apply the
`Court’s construction. As it relates to the OTA proxy limitation, Fintiv’s Preliminary Infringement Contentions and its Proposed Amended
`Infringement Contentions are identical. Compare, e.g., pgs. 53-55 and 96-105 of Exhibit A to both documents. For both the OTA proxy limitations,
`Fintiv’s contentions state that the OTA proxy is “software and/or hardware that enables secure communication.” See, e.g., Preliminary Infrigement
`Contentions, Exhibit A at 53 and 96. Under Fintiv’s interpretation of the OTA proxy claim limitations and the Court’s construction, mobile devices
`that satisfy this requirement were well-known to POSITA at the time of the alleged inventions. 1
`
`As noted, OTA proxy appears in claims 23 and 16. Most of the district court’s construction merely repeats other limitations of claim 23 which
`already requires that the OTA proxy is configured to “provision the contactless card applet,” “capture mobile device information comprising SE
`information,” and “transmit the mobile device information for registering the mobile wallet application.” The analogs to these in the district court
`construction are “provisions contactless card applets,” “captures mobile device information (including SE information),” and “transmits data (mobile
`device and SE specific information) to the TSM system,” respectively. Apple addressed how the prior art meets these requirements, and the
`
`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 EX2036 Page 1
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`requirement that the OTA proxy be software, in its Preliminary Invalidity Contentions (as well as in the A-charts and cover document for these Final
`Invalidity Contentions) for claim 23. Unlike claim 23, claim 16 does not recite that the OTA proxy performs the aforementioned functions. For the
`same reasons, even if claim 16 were interpreted to require everything that claim 23 requires, the prior art renders claim 16 obvious for the same
`reasons. The only new requirement imposed by the district court’s construction is that the OTA proxy “receives APDU commands from the TSM
`and appropriately forwards them.”
`
`The ’125 patent explains that APDU is an acronym for “Application Protocol Data Unit.” ’125 patent at 8:2-3. The Asserted Patent does not disclose
`any specific APDU commands nor identify any new APDU commands. To the contrary, such commands were well-known to POSITAs at the time
`of the alleged invention and it would have been obvious to modify prior art system or methods to use existing APDU commands to communicate,
`including to securely communicate, between a TSM and secure element. APDU commands were an industry standard since at least 1995. See
`ISO7816-4 Standard, 1st Edition (Sept. 1, 1995); ISO14443-4 Standard, pg. vi (applying ISO7816-4 to contactless cards). These standards defined
`the communication protocol and commands for communicating with an IC card (e.g., a smartcard) and the secure element thereon. Id., pg. iv,
`Introduction. For example, ISO7816-4 specifies how many bits of data comprise header and payload information of APDU commands. Id., §5.3.
`Thus, even if claims 16 and 23 required the OTA proxy to “receive[] APDU commands from the TSM and appropriately forward[] them” (e.g., to the
`secure element) as required by the district court’s construction, this would have been obvious. For instance, Apple already explained how Aiglstorfer
`(Chart A-3), Buhot (Charts A-1 and A-2), and Wang (Chart A-7) teach transmitting information from a TSM to the secure element of a mobile device
`via an OTA proxy. See also, e.g., IPR2020-00019, Petition at 47-50, 53-55. Aiglstorfer’s mobile device includes a “security element” in the form of
`a “subscriber identify module (SIM) card” which wirelessly receives, via the mobile device’s communication hardware and a “trusted secure agent
`(TSA) 102,” contactless “banking card information” from a TSM for provisioning on the device. Aiglstorfer at Fig. 1, ¶¶[0034]-[0036]. While
`Aiglstorfer does not explicitly state that the TSM transmits banking card information via “ADPU commands,” as of the ’125 patent’s filing date it
`was well-known in the art to use APDU commands for communicating with, and provisioning cards on, a secure element like a SIM card. This is
`evidenced by Buhot ’437 which explains that “Application Protocol Data Unit (APDU commands),” defined by “ISO 14443-4 or ISO 7816-4,” are
`transmitted to/from a secure element like a SIM card during contactless card use, or when interacting with the secure element’s summary storing
`database 316. Buhot ’437, ¶¶[0017], [0100]- [0105]. The standards in Buhot ’437 are themselves prior art to the ’125 patent and demonstrate the
`knowledge of a POSITA circa 2010. See ISO7816-4 Standards dated 1995 and 2005; ISO14443-4 Standard dated 2001; ISO14443-4 Standard dated
`2000. The ISO7816-4 Standard expressly states that APDU commands are the format used for “information exchange negotiated between the
`outside world and the integrated circuit” in a removable security element like a SIM card. See ISO7816-4 at 5, 13. Thus, when relaying new banking
`cards or other information from the TSM to a secure element (such as Aiglstorfer’s SIM card), it would have been obvious to do so via ADPU
`commands. See, e.g., U.S. Pat. Pub. 2012/0095852 to Bauer et al., ¶¶[0025], [0036] (noting that “APDU commands” are sent from a “TSM server”
`when communicating with a mobile device’s “secure element”).
`
` POSITA would have been motivated to use APDU commands for receiving communications from the TSM and forwarding them to the secure
`element because APDU commands were an industry standard format for communicating with a secure element. APDU commands could be used for
`
` A
`
`2
`
`IPR2020-00019
`Fintiv EX2036 Page 2
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`communicating a variety of different types of messages relating to a variety of different contactless card applets. This flexibility would be appealing
`to designers. It would also factilitate interoperability and flexibility which were known advantages of using industry standards. Using industry
`standard techniques can reduce development time and result in more robust communications. Indded, the ability for a TSM to communicate with a
`secure element on a mobile device in the context of mobile payments was disclosed in references such as Bauer. Bauer, ¶¶[0025], [0036] (noting that
`“APDU commands” are sent from a “TSM server” when communicating with a mobile device’s “secure element”). Using APDU commands for
`provisioning was well within the capabilities of a POSITA and would have been a mere design choice. Moreover, a POSITA would have a
`reasonable expectation of success in using APDU commands for provisioning because APDU commands were already extensively used for
`communicating with the secure element when conducting a payment transaction with a contactless card reader.
`
`Apple incorporates by reference its December 9, 2019 filing (Paper 7) in IPR2020-00019, including the prior art references and exhibits thereto (viz.,
`Ex. 2028-1032).
`
`To the extent Fintiv contends that any reference identified in Exhibit A does not disclose any portion of the OTA proxy 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 and Apple’s Final Invalidit Contentions or as identified herein.
`
`
`Reference
`
`Disclosure
`
`U.S. Pat. Pub. 2012/0095852 to Bauer et al.
`(“Bauer ’852). Bauer ’852 was filed Oct.
`15, 2010.
`
`See, e.g.:
`
`• Bauer, Abstract “A mobile payment method, system and graphical user inter face are described that facilitate efficient
`and secured pay ment transactions from an electronic wallet on a user portable electronic device with a merchant point
`of sale terminal over a contactless communications link.”
`
`3
`
`IPR2020-00019
`Fintiv EX2036 Page 3
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`
`• Bauer [0019] “The account man agement system 7 may provide for mobile payment account creation and activation,
`transaction authorization, and other related functionality, as described in the Applicant’s above referenced co-pending
`application U.S. Ser. No. 12/891,866. As will be described below, the account management system 7 may include a
`communications server 13 and a Trusted Service Manager (TSM) server 18 for facilitating communi cation between
`the middleware server 16 and the mobile device 3.”
`• Bauer [0024] “As shown, the account management system 7 may include a communications server 13, a middleware
`server 16, and a Trusted Service Manager (TSM) server 18, which com municate electronically with one another. In
`this embodi ment, the servers communicate with one another via secure network links, for example over a private
`Local Area Network (LAN), a VPN connection, or other dedicated secure connec tion. As those skilled in the art will
`appreciate, although the components of the account management system 7 in this embodiment are provided as
`
`4
`
`IPR2020-00019
`Fintiv EX2036 Page 4
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`separate servers, one or more of the servers could be provided as software and/or hardware modules in the same
`server.”
`• Bauer [0025]. “As shown in FIG. 1, data may be communicated between the mobile device 3 and the middleware
`server 16 over the cellular telephone network 11 via a cellular tele phone network interface 14 of the communications
`server 13. The TSM server 18 may perform logical data preparation of the data to be communicated to the mobile
`device, for example by forming appropriate commands to be written to the secure memory 4 of the mobile device 3.
`As those skilled in the art will appreciate, the precise form of the data may depend on the particular implementation of
`the secure memory 4 of the mobile device 3 and/or the payment asso ciation scheme program for facilitating payment.
`The TSM server 18 may also perform encryption of the data, for example of the sensitive payment account
`information in the mobile payment account data 6 Such as payment keys. The TSM server 18 may then pass the
`encrypted data to the mobile device 3 via the communications server 13 and the cellular telephone network 11.”
`• Bauer [0026] “he communications server 13 may also include a separate TSM unit 15 for securely routing the data to
`the mobile device 3, as will be known to the skilled person. In the above example, the TSM unit 15 in the
`communications server 13 would not access any of the sensitive portions of the encrypted data that is routed to the
`mobile device 3 via the cellular telephone network interface 14.”
`• Bauer [0036]. “FIG.2b is a block diagram showing the main func tional elements of the mobile device when
`configured to execute processing instructions of the payment applet 40 and the authentication applet 46, according to
`an embodiment of the invention. As will be discussed in greater detail below, the mobile payment wallet application
`module 8 may call the payment applet instance 40 to conduct a payment transaction process for example when a user
`waves the mobile device 3 past the contactless communication interface of the POS ter minal 5. As shown in FIG.2b,
`in this embodiment, the pay ment applet 40 may provide functional elements for autho rizing a transaction 4.0-1,
`generating an authorization request 40-2, transmitting an authorization request 40-3 and display ing confirmation of a
`completed payment transaction 40-4. for example. The payment applet 40 may call the authentica tion applet instance
`46 to process, authorize and allow a payment transaction to proceed. The authentication applet 46 tells the payment
`application if the PIN has been set and if it will allow the transaction to proceed based upon various PIN entry flags.
`As shown in FIG.2b, the authentication applet 46 may also provide functional elements for updating the PIN 46-1,
`locking the PIN 46-2, obtaining a user defined security word 46-3 from the secure data 6, checking if the PIN is
`currently writeable 46-4, verifying the PIN 46-5, setting a PIN-verified flag 46-6, clearing a PIN-verified flag 46-7,
`resetting the PIN 46-8, updating the security word 46-9, updating the Risk flag 46-10, resetting the Risk flag 46-11
`and retrieving the PIN-verified flag 46-12. Functional elements 46-1 to 46-7 and 46-11 are typically called by the
`mobile payment wallet application module 8, as will be described below. Functional elements 46-8 to 46-10 may be
`called by the account management system 7, for example from the middleware server 16 via the TSM server 18 in the
`form of APDU commands to execute in the secure element for remotely setting the PIN risk flag 103, as will be
`described below. Functional elements 46-12, as well as 46-7, are typi cally called by the payment applet 40.”
`
`5
`
`IPR2020-00019
`Fintiv EX2036 Page 5
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`The teachings of this reference are explicitly directed to systems and methods for communication with secure element in a
`mobile device in the context of a mobile wallet, including communications with a server, 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
`communicates with a server to provision and/or operate a mobile wallet, such as those identified in Exhibit A.
`
`ISO/IEC 7816-4 Standard, First Edition
`(Sept. 1, 1995). This standard was
`submitted on May 9, 2006 in an IDS for
`U.S. Pat. App. 10/471,883 and U.S. Pat.
`App. 12/376,360.
`
`See, e.g.:
`
`• Pg. iv
`
`
`
`• Pg. 1 “Scope - This part of ISO/IEC 7816 specifies:
`- the content of the messages, commands, and responses transmined by the interface device to the card and conversely.
`- the structure and content of the historical bytes gent by the card during the answer to reset.
`- the structure of files and data as seen at the interface when processing interindusrry commands for interchange.
` - accss methods to files and data in the card.
` - s security srchitecture defining access rights to files and data in the card.
` - methodsrhods for secure messaging.
` - access methods to the algorithms processed by the card.”
`• Pg. 1 “The lollowing standards contain provisions which through relerehce in this text, constitute provisions of this
`part of ISO/IEC 7816. At the time of psblication, the editions indicated were valid.”
`
`6
`
`IPR2020-00019
`Fintiv EX2036 Page 6
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`• Pg. 3 “Abbreviations and notations. For the purposes of this part of ISO/IEC 7816, the following abbreviations apply.
`APDU Application protocol data unit.”
`• Pg. 4
`
`7
`
`IPR2020-00019
`Fintiv EX2036 Page 7
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`8
`
`
`
`IPR2020-00019
`Fintiv EX2036 Page 8
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`• Pg. 7 (§5.3) “5.3 APDU message structure. A step in an application protocol consists of sending a cornmand,
`processing it in the receiving entity snd sending back the response. Therefore a specific response corresponds to a
`specific command, referred to as a command-response pair. An applicalion protocol data unit (APDU contains either a
`command messsge or a response message, sent from the interface device to the card or conversely. In a command-
`response pair, the command message and the response message may contain data, thus inducing four cases which are
`summarized by table 4.”
`
`9
`
`IPR2020-00019
`Fintiv EX2036 Page 9
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`
`
`10
`
`IPR2020-00019
`Fintiv EX2036 Page 10
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`
`
`11
`
`IPR2020-00019
`Fintiv EX2036 Page 11
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`12
`
`
`
`IPR2020-00019
`Fintiv EX2036 Page 12
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`• Pg. 12 “5.5 Logica. channels 5.5.1 Gcnereal concept. A logical channel, as seen at the interface, works as a logical
`link to a DF [dedicated file]. There shall be independence of activity on one togical channel frorn acrivity on another
`one. This is command inrerdependencies on one logical channel shall be independent of command interdependencies
`on anotner iogical channel. However, logical channels may share applicstion dependent security status and therefore
`may have security-related command interdependencies across logical channels (e.g., password verification comrnands
`referring to a certain logical channel carry the respective logical channel nrrmber in the CLA byte (see tables 8 and 9).
`Logical channels are numbatad from 0 to 3. lf a card supports the logical channel mechanism, than the maximum
`number of avaitable logical channels is indicated in the card capabilities.”
`• Pg. 13 (§5.6.1)
`
`
`• Pg. 31 (§8) “Historical bytes 8.1 Purpose and General Structure. The hisorical bytes tell the outside world how to use
`the card when the trsnsport protocol is ascertainsd according to part 3 ot ISOIEC 7816. The number of historical bytes
`… is specified and coded as part of ISO-7816-3. The intormation carried by the historical bytes may also be found in
`an ATR file. … If present. the historical bytes are made up ol three fields:
`
`13
`
`IPR2020-00019
`Fintiv EX2036 Page 13
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`- a mandatory category indicator [1 byte] …”
`See also §5.2 (security architecture of card), 5.3.1, 5.3.2, 5.4.2, 5.4.3, 5.4.4, 5.4.5, 5.5.2, 5.5.3, 5.6 (secure messaging),
`5.6.4, 6.10, 6.11 Annex A, B, C, D, E, and F.
`
`•
`
`The teachings of this reference are explicitly directed to using APDU-based communications on an integrated circuit card. The
`ISO14443 standard extends the APDU communication protocol to contactless cards. Common applications included cards for
`making contactless payments. A POSITA at the relevant time would have been motivated to combine these teachings with
`other systems and methods in which a mobile device communicates with a server to provision and/or operate a mobile wallet,
`such as those identified in Exhibit A.
`
`ISO/IEC 7816-4 Standard, First Edition
`(Sept. 1, 1995), Amendment 1. This
`standard was submitted in an IDS for U.S.
`Pat. App. 12/376,360.
`
`See, e.g.:
`
`• Pg. iv “Introduction The integrated circuit(s) cards with contacts are identification cards intended for information
`exchange negotiated between the outside and the integrated circuit in the card. As a result of an information exchange,
`the card delivers information (computation results. stored data), and/or modifies its content (data storage, event
`memorization).”
`
`14
`
`IPR2020-00019
`Fintiv EX2036 Page 14
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`15
`
`
`
`IPR2020-00019
`Fintiv EX2036 Page 15
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`The teachings of this reference are explicitly directed to using APDU-based communications on an integrated circuit card. The
`ISO14443 standard extends the APDU communication protocol to contactless cards. Common applications included cards for
`making contactless payments. A POSITA at the relevant time would have been motivated to combine these teachings with
`other systems and methods in which a mobile device communicates with a server to provision and/or operate a mobile wallet,
`such as those identified in Exhibit A.
`
`ISO/IEC 7816-4 Standard, Second Edition
`(Jan. 15, 2005). This standard was
`submitted on April 6, 2009 in an IDS for
`U.S. Pat. App. 12/376,360.
`
`See, e.g.:
`
`• Pg. v “Introduction ISO/IEC 7816 is a series of standards specifying integrated circuit cards and the use of such cards
`for interchange. These cards are identification cards intended for information exchange negotiated between the outside
`world and the integrated circuit in the card. As a result of an information exchange, the card delivers information
`(computation result, stored data), and I or modifies its content (data storage, event memorization).”
`• Pg. 1
`
`16
`
`IPR2020-00019
`Fintiv EX2036 Page 16
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`• Pg.5
`
`
`
`
`
`17
`
`IPR2020-00019
`Fintiv EX2036 Page 17
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`• Pg. 7
`
`• Pg. 17
`
`
`
`18
`
`IPR2020-00019
`Fintiv EX2036 Page 18
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`19
`
`
`
`IPR2020-00019
`Fintiv EX2036 Page 19
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`
`• Pg. 28 “6 Secure messaging. Secure messaging (SM) protects all or part of a command-response pair, or a
`concatenation of consecutive data fields (command chaining, see 5.1.1.1; use of SW1 set to '61'), by ensuring two
`basic security functions: data confidentiality and data authentication. Secure messaging is achieved by applying one or
`
`20
`
`IPR2020-00019
`Fintiv EX2036 Page 20
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`more security mechanisms. Possibly explicitly identified by a cryptographic mechanism identifier template (see 5.4.2)
`in the control parameters of any OF (see 5.3.3), each security mechanism involves a cryptographic algorithm, a mode
`of operation, a key, an argument (input data) and often, initial data. The transmission and reception of data fields may
`be interleaved with the processing of security mechanisms. This specification does not preclude the determination by
`sequential analysis of which mechanisms and which security items shall be used for processing the remaining part of
`the data field. Two or more security mechanisms may use the same cryptographic algorithm with different modes of
`operation. The hereafter specified padding rules do not preclude such a feature.”
`• Pg. 33
`
`
`
`
`
`21
`
`IPR2020-00019
`Fintiv EX2036 Page 21
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`• Pg. 36
`
`
`
`
`• Pg. 61 “8.2 Application identification and selection This service allows the interface device to know what application
`is active in the card, if any, as well as how to identify and select any application supported by the card.”
`• Pg. 64 (“8.3 Selection by path This service allows selection of EFs and un-named DFs by using a path, i.e., a file
`reference data element (see 5.3.1.2) consisting of three or more bytes.”)
`See also §5.1, 5.3, 5.4, 7.1-7.6, 8.2 (Application identification), 8.3 (selection by path), Annex A, B, C, and D.
`
`•
`
`The teachings of this reference are explicitly directed to using APDU-based communications on an integrated circuit card. The
`ISO14443 standard extends the APDU communication protocol to contactless cards. Common applications included cards for
`
`22
`
`IPR2020-00019
`Fintiv EX2036 Page 22
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`making contactless payments. A POSITA at the relevant time would have been motivated to combine these teachings with
`other systems and methods in which a mobile device communicates with a server to provision and/or operate a mobile wallet,
`such as those identified in Exhibit A.
`
`ISO/IEC 14443-4 Standard, First Edition
`(Feb. 2, 2001). ISO/IEC 14443-4 Standard
`(July 13, 2000). This standard was
`submitted on Feb. 1, 2005 in an IDS for
`U.S. Pat. App. 10/937,084.
`
`See, e.g.:
`
`• Pg. vi “Introduction ISO/IEC 14443 is one of a series of International Standards describing the parameters for
`identification cards as defined in ISO/IEC 7810, and the use of such cards for international interchange. The protocol
`as defined in this part of ISO/IEC 14443 is capable of transferring the application protocol data units as defined in
`ISO/IEC 7816-4. Thus application protocol data units may be mapped as defined in ISO/IEC 7816-4 and application
`selection may be used as defined ISO/IEC 7816-5. ISO/IEC 14443 is intended to allow operation of proximity cards
`in the presence of other contactless cards conforming to ISO/IEC 10536 and ISO/IEC 15693.”
`• Pg. 1 “2 Normative references. The following normative documents contain provisions, which, through reference in
`this text, constitute provisions of this part of ISO/IEC 14443. For dated references, subsequent amendments to, or
`revisions of, any of these publications do not apply. However, parties to agreements based on this part of ISO/IEC
`14443 are encouraged to investigate the possibility of applying the most recent editions of the normative documents
`indicated below. For undated references, the latest edition of the normative document referred to applies. Members of
`ISO and IEC maintain registers of currently valid International Standards. ISO/IEC 7816-3, Information technology –
`Identification cards – Integrated circuit(s) cards with contacts – Part 3: Electronic signals and transmission protocols.
`ISO/IEC 7816-4, Information technology – Identification cards – Integrated circuit(s) cards with contacts – Part 4:
`Interindustry commands for interchange.”
`
`23
`
`IPR2020-00019
`Fintiv EX2036 Page 23
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`24
`
`
`
`IPR2020-00019
`Fintiv EX2036 Page 24
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`• Pg. 15
`
`
`• Pg. 20 “7.5 Protocol operation After the activation sequence the PICC shall wait for a block as only the PCD has the
`right to send. After sending a block, the PCD shall switch to receive mode and wait for a block before switching back
`to transmit mode. The PICC may transmit blocks only in response to received blocks (it is insensitive to time delays).
`After responding, the PICC shall return to the receive mode. The PCD shall not initiate a new pair of command /
`response until the current pair of command / response has been completed or if the frame waiting time is exceeded
`with no response.”
`See also §5.1, 5.2, 5.3, 5.4, 7.1, 7.1.1
`
`•
`
`25
`
`IPR2020-00019
`Fintiv EX2036 Page 25
`
`

`

`Chart B-6
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`U.S. Patent No. 9,558,481 (“Bauer”).
`Bauer was filed on September 28, 2010.
`
`The teachings of this reference are explicitly directed to using APDU-based communications on contactless cards such as were
`commonly used for making contactless payments. A POSITA at the relevant time would have been motivated to combine
`these teachings with other systems and methods in which a mobile device communicates with a server to provision and/or
`operate a mobile wallet, such as those identified in Exhibit A.
`
`See, e.g.:
`
`•
`
`•
`
`•
`
`“The mobile device 3 also communicates with the account activation system 7 via a cellular telephone network 11.”
`Bauer at 3:11-13.
`“As shown in FIG. 1, the mobile device 3 in this embodiment includes a secure memory 4 storing payment account
`data 6 for one or more mobile payment accounts that have been set up on the mobile device 3. The secure memory 4
`may for example be a Universal Integrated Circuit Card (UICC) secure element as is known in the art. As those skilled
`in the art will appreciate, other forms of mobile handset software and/or hardware may be implemented to provide
`built-in secure electronic wallet functionality for accessing the secure memory 4, including encryption and decryption
`of the payment account data 6 as necessary. For example, the mobile device 3 may be configured with built-in
`functionality providing access to secure memory on the Subscriber Identity Module (SIM) card in the mobile device
`3.” Bauer at 3:14-28.
`“Before the user can use the mobile device 3 to carry out transactions with a merchant electronic POS terminal 5, a
`new mobile payment account may be provisioned for the user, for example in response to a user requesting a new
`mobile payment account via the mobile device 3. Payment account data 6 may be created by the account activation
`system 7 for a new mobile payment account, and the account activation system 7 may be arranged to immediately
`transmit the payment account data 6 to the mobile device 3 for storage in the secure memory 4 of the mobile device 3.
`As those skilled in the art will appreciate, this is just one way in which an inactive mobile payment account can be
`provisioned on the mobile device 3 and any other method of delivery is envisaged. A notification message may be
`displayed by the mobile device 3 to alert the user that the mobile payment account is ready but requires authentication
`via the mobile payment account module 8 before the mobile payment account can be activated. A secure activation
`process is then carried out between the mobile device 3 and the account activation system 7 to authenticate the identity
`of the user trying to activate the new mobile payment account. Once the authentication is successful, the account
`activation system 7 activates the mobile payment account. The activated mobile payment account data stored in the
`secure memory 4 of the mobile device 3 can then be used to carry out transactions with a merchant electronic POS
`terminal 5 via the contactless communication link 9, whereby