`
`IN THE UNITED STATES PATENT AND TRADELVIARK OFFICE
`
`DOCKET291 54206056
`[3853110931084
`
`Re Application of: ROWSE et al.
`
`US. Serial No.1 10/937,084
`
`Filed: September 8, 2004
`For: ELECTRONIC NEAR FIELD COMMUNICATION ENABLED
`
`MULTIFUNCTIONAL DEVICE AND METHOD OF ITS OPERATION
`
`Attorney Docket: 915—006.056
`
`Commissioner for Patents
`13.0. Box 1450
`Alexandria, VA 22313—1450
`
`INFORMATION DISCLOSURE STATEMENT
`
`Sir:
`
`Applicant submits herewith references of which they are aware, which they
`
`believe may be material to the examination of this application and which they may
`
`have a duty to disclose in accordance with 37 CFR 1.56.
`
`While this Information Disclosure Statement may be "material" pursuant to
`
`37 CFR 1.56, it is not intended to constitute an admission that any document
`
`referred to herein is "prior art" for this invention unless specifically designated as
`such.
`
`CERTIFICATE OF MAILING
`
`I hereby certify that this correspondence is being deposited with the United States Posml Service
`on the date shown below with sufficient postage as first class mail in an envelope addressed
`to the Commissioner for Parents, PVO. Box 1450. Alexandria, VA 22313-1450
`
`Deborah J. Clark
`
`l)
`
`Dated: ACT) \ Q0125
`
`Apple Ex. 1032, p. 1
`Apple Ex. 1032, p. 1
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`DOCKET:9‘. 5-”06.056
`USSN: I 0 937.084
`
`In accordance with 37 CFR 1.97(g), the filing of this Information Disclosure
`
`Statement should not be construed to mean that a search has been made or that no
`
`other material information as defined under 37 CFR 156(3) exists.
`
`Also enclosed is a Form PTO/ 1449 listing the references enclosed.
`
`Respectfully submitted,
`
`@W/ W
`
`Francis J. Maguire
`
`Attorney for the Applicant
`
`Registration No. 31,391
`
`FJM/djc
`Ware, Fressola, Van Der Sluys & Adolphson LLP
`755 Main Street, P.O. Box 224
`Monroe, CT 06468
`(203) 261—1234
`
`Apple Ex. 1032, p. 2
`Apple Ex. 1032, p. 2
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`\ {,3 ’
`'-,_,\
`INFORMATION DISCLOSURE
`CITATION FORM FOR
`
`PATENT APPLICATION
`(FORM PT0-1449)
`(Substitute)
`
`Docket No: 915-006.056
`
`Applicant(s): ROWSE et 8].
`
`Filing Date: September 8, 2004
`US. PATENTS
`
`'
`Serial No: lO/937,084
`
`of: 1
`
`class
`
`Initials
`
`Document Number
`
`FOREIGN PATENT DOCUMENTS
`Date
`Country
`
`Name
`
`Translation?
`Yes/No/n/a
`
`--- v-s- PATENT PUBLICATIONS ---
`Initials
`P 1'
`' N .
`Pub. Date
`Name
`Class
`Sub-
`Filin Date
`-———-——
`
`
`
`OTHER DOCUMENTS Title, Author, Date, Paes, Etc., if known
`MIFARE, Standard 4 kByte Card 10, MFI 1C 370, Functional Specification, Philips Semiconductors,
`Product S ecification Rev. 3.1 October 2002, 17
`
`ISO/IEC FDIS l4443-4:2000(E), Identification cards - Contactless integrated circuit(s) cards -
`Proximity cards - Part 4: Transmission rotocol, July 13, 2000, 44
`
`ECMA-352 Standard, Near Field Communication Interface and Protocol—2 (NFCIP-Z), December
`2003, 8 Haas.
`
`Date Considered:
`Examiner’s Si ature:
`Initial if reference was considered, whether or not citation is in conformance with MPEP. Mark through citation if not considered.
`Include a co: of this citation form with our next cones-ondence to the A licant s .
`Customer No.: 4955
`
`Apple Ex. 1032, p. 3
`Apple Ex. 1032, p. 3
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`Awn
`
`Secrétaria! CN COIGE B
`
`Vctre mnaspundan! : Jean-Claude HESLING
`
`L’grua (frame : + 33142 91 57 08
`Counier éfewnnique : iean-clauda,hesling@ema1afiwr.lr
`Nos réfererm: K/JCHIAE
`
`CN CC/GE 8 N 309
`
`2000-094 4
`
`TITRE :
`
`SOURCE :
`
`NOTE :
`
`Vote de la France sur I'lSO/CEI FDIS 14443-4 "Canes
`d'identification - Canes écircuit(s) intégrés sans contacts -
`canes de proximité - Panie 4 : Protocole de transmission"
`
`Secrétariat Central de I'ISO
`
`Soumis au vole jusqu'au 14 novembre 2000. Une
`décision de principe de vote positif sans commentaires a
`été prise lors de la réunion GE 8 du 8 juin 2000
`(voir GE8 N 303).
`
`SUITE A DONNER:
`
`Pour examen an we de la préparation du vote de la France
`lors de la réunion GE 8 du 5 octobre 2000 puis décision lors
`de la réunion CNCC du 11 Octobre 2000.
`
`Associatlon
`Francalse de
`Normallsatlon
`Tour Europe
`92049 Parls la Delanse Cedex
`France
`Acces : La Defense 2
`Parking Les Covoiles
`Telz~331429155 55
`Telecopie : + 33 1 42 91 58 56
`Mlnltel
`: 3616 AFNOR
`htlp:l/www.afnnr,f1
`
`Assomallon raconnue
`a'ullllle publique
`Comlm mambva Itancais
`uu GEN OI no I'ISO
`Slrol 77572fl BIB 00015
`Coda MAP 751 E
`
`Apple Ex. 1032, p. 4
`Apple Ex. 1032, p. 4
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`lSOIlEC JTC‘l/SC 1?
`
`Date: 2000-07-13
`
`[SO/IE6 FDIS 14443-4:2000(E)
`
`lSO/lEC JTCl/SC 17/WG 8
`
`Secretariat: DIN
`
`Identification cards -— Contactless integrated circuit(s) cards —-— Proximity
`cards — Part 4: Transmission protocol
`
`Cartes d'identification — Cartes a circuit(s) intégre’s sans contacts —— Canes de proximité — Partie 4 : Protocole de
`transmission
`
`international Standard
`Document type:
`Document subtype:
`Document stage:
`(50) Approval
`Document language: E
`
`G:\lSO_IEC\FDIS14443—4\lSO—IEC 14443—4 (E).doc STD Version 1.0
`
`Apple Ex. 1032, p. 5
`Apple Ex. 1032, p. 5
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`ISO/IEC FDIS 14443-4:2000(E)
`
`Copyright notice “
`
`‘ This 180 document is a Draft international Standard and is copyright-protected by ISO. Except as permitted .
`. under the applicable laws of the user‘s country. neither this ISO draft nor any extract from it may be ‘
`reproduced. stored in a retrieval system or
`transmitted in any form or by any means. electronic?
`[ photocopying. recording or otherwise. without prior written permission being secured.
`l
`
`Requests for permission to reproduce should be addressed to ISO at the address below or lSO's member
`1 body in the country of the requester.
`
`l ll
`
`ll
`.
`l
`l
`
`Copyright Manager
`ISO Central Secretariat
`1 rue de Varembé
`1211 Geneva 20 Switzerland
`tel. 1* 4122 749 0111
`fax 4» 41 22 734 7079
`intemet: iso@iso.ch
`
`Reproduction may be subject to royalty payments or a licensing agreement.
`
`Violators may be prosecuted.
`
`Apple Ex. 1032, p. 6
`Apple Ex. 1032, p. 6
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISO/IEC FDIS 14443-4:2000(E)
`
`Conte nts
`
`1
`
`2
`
`Scope ....................................................................................................................................................... 1
`
`Normative reference(s) ............................................................................................................................ 1
`
`Term(s) and definition(s) ......................................................................................................................... 1
`3
`...2
`Symbols (and abbreviated terms) .....
`4
`
`Protocol activation of PICC Type A...
`4
`5
`
`Request for answer to select
`6
`5.1
`
`Answer to select ....................
`6
`5.2
`
`Structure of the bytes..
`...7
`5.2.1
`
`5.2.2 Length byte ...............
`7
`
`5.2.3
`Format byte ...............
`7
`
`5.2.4
`Interface byte TA(1) ..
`8
`
`5.2.5
`Interface byte TB(1) ..
`8
`
`5.2.6
`Interface byte TC(1) ..
`9
`5.2.7 Historical bytes ..............................................
`9
`
`Protocol and parameter selection request...
`10
`5.3
`
`10
`Start byte....
`......
`5.3.1
`Parameter 0...
`5.3.2
`11
`
`Parameter 1 ....................................................
`5.3.3
`11
`
`5.4
`Protocol and parameter selection response
`
`Activation frame waiting time .......................
`5.5
`
`. 12
`5.6
`Error detection and recovery ..
`5.6.1 Handling of RATS and ATS ...........................
`. 12
`
`5.6.2 Handling of PPS request and PPS response
`12
`5.6.3 Handling of the CID during activation ................................................................................................... 13
`6
`Protocol activation of PICC Type B ...................................................................................................... 14
`7
`Half-duplex block transmission protocol ............................................................................................. 15
`Block format................................................
`7 1
`
`7.1.1
`Prologue field...............
`
`Information field ...........
`7.1.2
`
`71 3 Epilogue field ............
`
`Frame waiting time ...............
`7.2
`Frame waiting time extension .
`7.3
`
`Power level indication ..........
`7.4
`Protocol operation .......
`7.5
`
`7.5.1 Multi-Activation.........
`7.5.2 Chaining .......................
`
`7.5.3 Block numbering rules
`
`7.5.4 Block handling rules .............
`Error detection and recovery ................................................................................................................ 23
`7.5.5
`8
`Protocol deactivation of PICC Type A and Type B ...............................................................................
`
`.
`8.1
`Deactivation frame waiting time..........................
`8.2
`Error detection and recovery ........................
`
`Annex A (informative) Multi-Activation example ............................................................................................... 26
`Annex B (informative) Protocol scenarios .........................................................................................................
`
`Notation .......................................
`8.1
`
`8.2
`Error-free operation.....
`
`8.2.1 Exchange of I-blocks .....................
`3.2.2 Request for waiting time extension
`
`
`© ISO/IEO 2000 — All rights reserved
`
`iii
`
`Apple Ex. 1032, p. 7
`Apple Ex. 1032, p. 7
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`iSOIlEC FDIS 1 4443-4:2000(E)
`
`8.2.3 DESELECT ............................................................................................................................................. 28
`
`8.2.4 Chaining................ 28
`
`Error handling................. 29
`8.3
`
`8.3.1 Exchange of I-blocks ............................. 29
`
`5.3.2 Request for waiting 1ime extension .................... 30
`
`8.3.3 DESELECT............ 32
`
`3.3.4 Chaining ........................................................................ 33
`
`Annex C (informative) Block and frame coding overview...
`.......................................... 36
`
`iv
`
`(9 ISO/[EC 2000 - All rights reserved
`
`Apple Ex. 1032, p. 8
`Apple Ex. 1032, p. 8
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISO/IEC FDIS 144434220005)
`
`Foreword
`
`ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
`form the specialized system for worldwide standardization. National bodies that are members of ISO or IE0
`participate in the development of
`International Standards through technical committees established by the ‘
`respective organization to deal with particular fields of technical activity.
`ISO and IEC technical committees
`collaborate in fields of mutual interest. Other international organizations. governmental and non-governmental, in
`liaison with ISO and IEC, also take part in the work.
`
`International Standards are drafted in accordance with the rules given in the ISO/IEC Directives. Part 3.
`
`In the field of information technology. ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
`Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.
`Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
`
`Attention is drawn to the possibility that some of the elements of this part of ISO/IEC 14443 may be the subject of
`patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
`
`International Standard ISO/IEC 14443-4 was prepared by Joint Technical Committee ISO/IEC JTC .
`technology, Subcommittee SC 17, Identification cards and related devices.
`
`lnforrnation
`
`ISO/IEC 14443 consists of the following parts, under the general title Identification cards —— Contact/ass integrated
`circuit(s) cards ~— Proximity cards:
`
`— Pan 1: Physical characteristics
`
`— Part 2: Radio frequency power and signal interface
`
`— Part 3: Initialization and an ticollision
`
`-—- Part 4: Transmission protocol
`
`The annexes A. B and C of this part of ISO/IEC 14443 are for information only.
`
`© ISO/IEO 2000 — All rights reserved
`
`V
`
`Apple Ex. 1032, p. 9
`Apple Ex. 1032, p. 9
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISOIIEC FDIS 14443-4:2000(E)
`
`Introduction
`
`lSO/IEC 14443 is one of a series of International Standards describing the parameters for identification cards as
`defined in ISO/IEO 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 lSO/lEC 7816-4. Thus application protocol data units may be mapped as defined in lSO/lEC 7816—4
`and application selection may be used as defined in lSO/lEC 7816-5.
`
`lSO/IEC 14443 is intended to allow operation of proximity cards in the presence of other contactless cards
`conforming to lSO/lEC 10536 and ISO/IEC 15693.
`
`
`
`vi
`
`(9 ISO/IEC 2000 - All rights reserved
`
`Apple Ex. 1032, p. 10
`Apple Ex. 1032, p. 10
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`
`
`FINAL DRAFT INTERNATIONAL STANDARD lSOIlEC FDIS 14443-4:2000(E)
`
`identification cards —— Contactless integrated circuit(s) cards ——
`Proximity cards — Part 4: Transmission protocol
`
`1 Scope
`
`This part of ISO/IEC 14443 specifies a half-duplex block transmission protocol featuring the special needs of a
`contactless environment and defines the activation and deactivation sequence of the protocol.
`
`This part of iSO/lEC 14443 shall be used in conjunction with other parts of ISO/lEC 14443 and is applicable to
`proximity cards of Type A and Type B.
`
`2 Nomative reference(s)
`
`The following normative standards 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 lEC
`maintain registers of currently valid International Standards
`
`ISO/lEC 7616-3, Identification cards — Integrated circuit(s) cards with contacts — Part 3: Electronic signals and
`transmission protocols.
`
`ISO/lEC 7816-4, Identification cards — Integrated circuit(s) cards with contacts — Part 4: lnterindustry commands for
`interchange.
`
`I
`
`lSO/IEC 7816-5, Identification cards — Integrated circuit(s) cards with contacts — Part 5: Numbering system and
`registration procedure for application identifiers
`
`ISO/lEC 14443-2. identification cards -— Contactless integrated circuit(s) cards — Proximity cards — Part 2: Radio
`frequency power and signal interface
`
`Identification cards — Contactless integrated circuit(s) cards — Proximity cards — Part 3:
`ISO/lEC 14443—3.
`Initialization and anticoiiision
`
`3 Term(s) and definition(s)
`
`3.1
`bit duration
`the bit duration is defined as one elementary time unit (etu). The etu is calculated by the following formula:
`
`1etu =128/(Dx fc)
`
`The initial value of the divisor D shall be 1. Therefore the resulting initial etu shall be:
`
`1etu =128/fc
`
`The carrier frequency fc is defined in ISO/lEC 14443-2
`
`© ISO/lEC 2000 - All rights reserved
`
`1
`
`Apple Ex. 1032, p. 11
`Apple Ex. 1032, p. 11
` Apple v. Fintiv
`Apple v. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISO/[EC FDIS 14443-4:2000(E)
`
`3.2
`block
`a special type of frame. which contains a valid protocol data format. A valid protocol data fom'iat includes i-blocks.
`R-btocks or S-blocks
`
`3.3
`invalid block
`a type of frame, Which contains an invalid protocol format. A time-out, when no frame has been received, is not
`interpreted as an invalid block
`
`3.4
`frame
`
`a sequence of bits as defined in ISO/IEC 14443-3. The PICC Type A uses the standard frame defined for Type A
`and the PICC Type B uses the frame defined for Type B
`
`4 Symbols (and abbreviated terms)
`
`ACK
`
`ATS
`
`ATQA
`
`ATQB
`
`CID
`
`CRC
`
`D
`
`DR
`
`DRI
`
`DS
`
`DSI
`
`positive ACKnowledgement
`
`Answer To Select
`
`Answer To reQuest, Type A
`
`Answer To reQuest, Type B
`
`Card lDentifier
`
`Cyclic Redundancy Check. as defined for each PICC Type in ISO/IEC 14443-3
`
`Divisor
`
`Divisor Receive (PCD to PICC)
`
`Divisor Receive Integer (PCD to PICC)
`
`Divisor Send (PICC to PCD)
`
`Divisor Send Integer (PICC to PCD)
`
`EDC
`
`Error Detection Code
`
`etu
`
`fc
`
`FSC
`
`FSCI
`
`FSD
`
`FSDI
`
`FWI
`
`FWT
`
`elementary time unit
`
`carrier frequency
`
`Frame Size for proximity Card
`
`Frame Size for proximity Card Integer
`
`Frame Size for proximity coupling Device
`
`Frame Size for proximity coupling Device Integer
`
`Frame Waiting time Integer
`
`Frame Waiting Time
`
`FWTraip
`
`temporary Frame Waiting Time
`
`2
`
`© ISOIIEC 2000 —— All rights reserved
`
`
`
`Apple Ex. 1032, p. 12
`Apple Ex. 1032, p. 12
` Apple v. Fintiv
`Apple v. Fintiv
`lPR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISO/IEC FDIS 14443-4:2000(E)
`
`HLTA
`
`l-block
`
`INF
`
`MAX
`
`MIN
`
`NAD
`
`NAK
`
`OSl
`
`PCB
`
`PCD
`
`PICC
`
`PPS
`
`PPSS
`
`PPSO
`
`PPS1
`
`HALT Command, Type A
`
`Information block
`
`INformation Field
`
`Index to define a maximum value
`
`Index to define a minimum value
`
`Node ADdress
`
`Negative AcKnowledgement
`
`Open Systems Interconnection
`
`Protocol Control Byte
`
`Proximity Coupling Device
`
`Proximity Card
`
`Protocol and Parameter Selection
`
`Protocol and Parameter Selection Start
`
`Protocol and Parameter Selection parameter 0
`
`Protocol and Parameter Selection parameter 1
`
`R—block
`
`Receive ready block
`
`R(ACK)
`
`R-block containing a positive acknowledge
`
`R(NAK)
`
`R-block containing a negative acknovvledge
`
`RATS
`
`REQA
`
`RFU
`
`S—block
`
`SAK
`
`SFGI
`
`SFGT
`
`WUPA
`
`WTX
`
`WTXM
`
`Request for Answer To Select
`
`REQuest Command, Type A
`
`Reserved for Future Use
`
`Supervisory block
`
`Select AcKnoWledge
`
`Start-up Frame Guard time Integer
`
`Start-up Frame Guard Time
`
`Wake-Up Command, Type A
`
`Waiting Time eXtension
`
`Waiting Time eXtension Multiplier
`
`© ISOIIEC 2000 — All rights reserved
`
`Apple Ex. 1032, p. 13
`Apple Ex. 1032, p. 13
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`Isonec FDlS 14443-4:2000(E)
`
`5 Protocol activation of PICC Type A
`
`The following activation sequence shall be applied:
`
`PICC activation sequence as defined in ISO/lEC 14443-3 (request, anticollision loop and select).
`
`the beginning the SAK byte shall be checked for availability of an ATS. The SAK is defined in
`At
`ISO/IEO 14443-3.
`
`The PICC may be set to HALT state, using the HLTA Command as defined in ISO/IEC 14443.3, if no ATS is
`available.
`
`The RATS may be sent by the POD as next command after receiving the SAK if an ATS is available,
`
`The PICC shall send its ATS as answer to the RATS. The PICC shall only answer to the RATS if the RATS is
`received directly after the selection.
`
`if the PICC supports any changeable parameters in the ATS. a PPS request may be used by the POD as the
`next command after receiving the ATS to change parameters.
`
`The PlCC shall send a PPS Response as answer to the PPS request.
`
`A PICC does not need to implement the PPS, if it does not support any changeable parameters in the ATS.
`
`The PCD activation sequence for a PICC Type A Is shown in Figure 1.
`
`® ISO/IEC 2000 — All rights reserved
`
`Apple Ex. 1032, p. 14
`Apple Ex. 1032, p. 14
` Apple v. Fintiv
`Apple v. Fintiv
`lPR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISO/IEC FDIS 14443-4:2000(E)
`
`
`
`
`
`
`
`Send REQA
`
`Receive ATQA
`
`Anticollislon
`loop
`
`
`
`Send WUPA
`
`
`Send HLTA
`
`ATS
`
`available?
`
`I .................
`-
`protocol
`
`
`Use
`
`ISO/IEC 14443-4
`. rotocol?
`
`"0
`
`PPS
`supported?
`
`yes
`
`Send DESELECT Request
`
`
`
`yes
`
`Send RATS
`Receive DESELECT Response
`
`
`Receive ATS
`
`
`
`
`
`
`
`
`lSO/lEC14443-3
`
`~§<
`
`
`
`ISO/IEC14443-4
`
`Parameter
`
`change?
`
`Send PPS Request
`
`Receive PPS Response
`
`no
`
`
`
`Exchange
`Transparent
`Data
`
`
`
`
`
`Figure 1 —-— Activation of a PICC Type A by a POD
`
`(0 ISO/IEO 2000 — All rights reserved
`
`Apple Ex. 1032, p. 15
`Apple Ex. 1032, p. 15
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`ISO/IEC FDIS 14443-4:2000(E)
`
`5.1 Request for answer to select
`
`This clause defines the RATS with all its fields (see Figure 2).
`
`Start byte
`
`Parameter byte
`..... codes FSDI and ClD
`
`
`
`The parameter byte consists of two parts (see Figure 3):
`
`Figure 2 —— Request for answer to select
`
`—- The most significant half-byte b8 to b5 is called FSDl and codes FSD. The FSD defines the maximum size of a
`frame the POD is able to receive. The coding of FSD is given in Table 1.
`
`— The least significant half byte M to b1 is named CID and it defines the logical number of the addressed PICC
`in the range from O to 14. The value 15 is RFU. The CID is specified by the PCB and shall be unique for all
`PICCs. which are in the ACTIVE state at the same time. The CID is fixed for the time the PICC is active and
`the PICC shall use the ClD as its logical identifier, \M’lich is contained in the first error-free RATS received;
`
`aflmewnnm
`
`
`
`CID
`FSDI
`
`Figure 3 —— Coding of RATS parameter byte
`
`Table 1 —- FSDI to FSD conversion
`
`
`
`5.2 Answer to select
`
`This clause defines the ATS with all its available fields (see Figure 4).
`
`In the case that one of the defined fields is not present in an ATS sent by a PICC the default values for that field
`shall apply.
`
`5
`
`<9 ISO/[EC 2000 — All rights reserved
`
`Apple Ex. 1032, p. 16
`Apple Ex. 1032, p. 16
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`rec/rec FDIS 14443-4:2000(E)
`
`Length byte
`
`Format byte
`..... codes Y(1) and FSCI
`Interface bytes
`..... codes DS and DR
`
`..... codes FWI and SFGl
`
`Historical bytes
`
`..... codes protocol options
`
`5.2.1 Structure of the bytes
`
`Figure 4 — Structure of the ATS
`
`The length byte TL is followed by a variable number of optional subsequent bytes in the following order:
`
`— format byte T0,
`
`— interface bytes TA(1). TB(1). TC(1) and
`
`—— historical bytes T1 to Tk.
`
`5.2.2 Length byte
`
`The length byte TL is mandatory and specifies the length of the transmitted ATS including itself. The two CRC
`bytes are not included in TL. The maximum size of the ATS shall not exceed the indicated FSD. Therefore the
`maximum value of TL shall not exceed FSD-2.
`
`5.2.3 Format byte
`
`The format byte T0 is optional and is present as soon as the length is greater than 1. The ATS can only contain the
`following optional bytes when this format byte is present.
`
`TO consists of three parts (see Figure 5):
`
`— The most significant bit b8 shall be set to O. The value 1 is RFU.
`
`— The bits b7 to b5 contain Y(1) indicating the presence of subsequent interface bytes TC(1), TB(1) and TA(1).
`
`— The least significant half byte b4 to b1 is called FSCI and codes FSC. The FSC defines the maximum size of a
`frame accepted by the PlCC. The default value of FSCI is 2 and leads to a FSC of 32 bytes. The coding of
`FSC is equal to the coding of FSD (see Table 1).
`
`e) lSOllEC 2000 ~ All rights reserved
`
`7
`
`Apple Ex. 1032, p. 17
`Apple Ex. 1032, p. 17
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`lSO/IEC FDIS 1 4443-4:2000(E)
`
`FSCI
`TA(1) is transmitted. if bit is set to 1
`TB(1) is transmitted, if bit is set to 1
`TC(1) is transmitted, if bit is set to 1
`shall be set to 0, 1 is RFU
`Figure 5 — Coding of format byte
`
`3' W1)
`
`5.2.4
`
`Interface byte TA(1)
`
`The interface byte TA(1) consists of four parts (see Figure 6):
`
`— The most significant bit b8 codes the possibility to handle different divisors for each direction. When this bit is
`set to 1 the PICC is unable to handle different divisors for each direction.
`
`The bits b7 to b5 code the bit rate capability of the PICC for the direction from PICC to P00, called Ds. The
`default value shall be (000)b.
`
`
`
`The bit b4 shall be set to (O)b and the other value is RFU.
`
`The bits b3 to b1 code the bit rate capability of the PICC for the direction from PCD to PICC. called DR. The
`default value shall be (000)b.
`
`
`
`
`
`
`MIME
`
`III-III.-
`
`‘ % DR=2 supported. if bit is set to 1
`DR=4 supported. if bit is set to 1
`DR=8 supported, if bit is set to 1
`shall be set to O. 1 is RFU
`DS=2 supported. if bit is set to 1
`DS=4 supported, if bit is set to 1
`08:8 supported, if bit is set to 1
`Only the same D for both directions
`supported, if bit is set to 1
`Different D for each direction
`supported. if bit is set to 0
`Figure 6 -— Coding of interface byte TA(1)
`
`The selection of a specific divisor D for each direction may be done by the POD using a PPS.
`
`5.2.5
`
`interface byte TB(1)
`
`The interface byte TB(1) conveys information to define the frame waiting time and the start~up frame guard time.
`
`The interface byte TB(1) consists of two parts (see Figure 7):
`
`~— The most significant half-byte b8 to b5 is called FWl and codes FWT (see 7.2).
`
`8
`
`© ISO/(EC 2000 - All rights reserved
`
`
`
`1
`
`Apple Ex. 1032, p. 18
`Apple Ex. 1032, p. 18
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISO/IEC FDIS 14443-4:2000(E)
`
`—— The least significant half byte b4 to M is called SFGI and codes a multiplier value used to define the SFGT.
`The SFGT defines a specific guard time needed by the PICC before it is ready to receive the next frame after it
`has sent the ATS. SFGI is coded in the range from 0 to 14. The value of 15 is RFU. The value of 0 indicates no
`SFGT needed and the values in the range from 1 to 14 are used to calculate the SFGT with the formula given
`below. The default value of SFGl is 0.
`
`
`
`
`mammaaem
`
`
`III-III-
`QT: LT:— SFG.
`
`Figure 7 — Coding of interface byte TB(1)
`SFGT is calculated by the following formula:
`
`SFGT = (256 x 16 I fc) x 25““
`
`SFGTMIN = minimum value as defined in lSO/IEC 14443-3
`
`SFGTosnuur = minimum value as defined in lSO/lEC 14443-3
`
`SFGTMAx = ~4949 ms
`
`5.2.6
`
`Interface byte TC(1)
`
`The interface byte TC(1) specifies a parameter of the protocol.
`
`The specific interface byte TC( 1) consists of two parts (see Figure 8):
`
`— The most significant bits b8 to b3 shall be (000000)b and all other values are RFU.
`
`— The bits b2 and b1 define which optional fields in the prologue field a PICC does support. The F'CD is allowed
`to skip fields. which are supported by the PICC, but a field not supported by the PICC shall never be
`transmitted by the POD. The default value shall be (10)b indicating CID supported and NAD not supported.
`
`maafiaaan flflflflflflll
`I
`L——— NAD supported, if bit is set to 1
`
`CID supported, if bit is set to 1
`shall be set to (000000)b, all other values are RFU
`Figure 8 .. Coding of interface byte TC(1)
`
`5.2.7 Historical bytes
`
`The historical bytes T1 to Tk are optional and designate general information. The maximum length of the ATS gives
`the maximum possible number of historical bytes. lSO/lEC 7816-4 specifies the content of the historical bytes.
`
`© ISO/[EC 2000 — All rights reserved
`
`9
`
`Apple Ex. 1032, p. 19
`Apple Ex. 1032, p. 19
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`lSO/lEC FDIS 14443-4:2000(E)
`
`5.3 Protocol and parameter selection request
`
`PPS request contains the start byte that is followed by two parameter bytes (see Figure 9).
`
`Start byte
`
`Parameter 0
`..... codes presence of PPS1
`Parameter 1
`..... codes DRI and DSI
`
`
`
`Figure 9 — Protocol and parameter selection request
`
`5.3.1 Stan byte
`
`PPSS consists of two parts (see Figure 10):
`
`— The most significant half byte be to b5 shall be set to 'D' and identifies the PPS.
`
`
`
`— The least significant half byte b4 to b1 is named CH) and it defines the logical number of the addressed PlCC.
`
`
`
`mneeeeen
`
`
`llfllllll
`
`
`y t cmshall be set to 1, 0 is RFU
`
`shall be set to O, 1 is RFU
`shall be set to (11 )b, all other values are RFU
`
`Figure 10 Coding of PPSS
`
`
`
`10
`
`e lSOIlEC 2000 - All rights reserved
`
`Apple Ex. 1032, p. 20
`Apple Ex. 1032, p. 20
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`lSOIlEC FDIS 14443-4:2000(E)
`
`;
`
`l
`
`5.3.2 Parameter 0
`
`PPSO indicates the presence of the optional byte PPS1 (see Figure 11).
`
`
`
`
`
`mommnanm
`nun-nun!
`'1 shall be set to 1, 0 is RFU
`
`
`
`
`
`shall be set to (000)b. all other values are RFU
`PPSt is transmitted, if bit is set to 1
`shall be set to (000)b, all other values are RFU
`Figure 11 — Coding of PPSO
`
`5.3.3 Parameter 1
`
`PPSt consists of three parts (see Figure 12):
`
`—- The most significant half byte b8 to b5 shall be (0000)b and all other values are RFU.
`
`— The bits b4 and b3 are called DSI and code the selected divisor integer from PlCC to P00.
`
`— The bits b2 and D1 are called DRI and code the selected divisor integer from PCD to PICC.
`
`
`
`
`
`mamamaem
`flflflflllll
`l L:— DRI
`
`
`
`
`
`shall be set to (0000)b, all other values are RFU
`Flgure 12 -—- Coding of PPS1
`
`For the definition of DS and DR. see 5.2.4.
`
`The coding of D is given in Table 2.
`
`Table 2 — DRI, DSI to D conversion
`
`
`
`
`
`swrowmnormu
`Ellllllfllfll
`
`
`
`
`
`5.4 Protocol and parameter selection response
`
`The PPS response acknowledges the received PPS request (see Figure 13) and it contains only the start byte (see
`5.3.1).
`
`© lSO/IEC 2000 - All rights reserved
`
`1 1
`
`Apple Ex. 1032, p. 21
`Apple Ex. 1032, p. 21
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`iSOIIEC FDIS 14443-4:2000(E)
`
`Figure 13 -— Protocol and parameter selection response
`
`5.5 Activation frame waiting time
`
`The activation frame waiting time defines the maximum time for a PICC to start sending its response frame after
`the end of a frame received from the PCB and has a value of 65536/fc (-4833 us).
`
`NOTE
`
`The minimum time between frames in any direction is defined in ISO/IEO 14443-3.
`
`5.6 Error detection and recovery
`
`5.6.1 Handling of RATS and ATS
`
`5.6.1.1
`
`PCD rules
`
`
`
`When the POD has sent the RATS and receives a valid ATS the PCB shall continue operation.
`
`in any other case the POD may retransmit the RATS before it shall use the deactivation sequence as defined in
`clause 8. In case of failure of this deactivation sequence it may use the HLTA Command as defined in ISO/IEC
`14443-3.
`
`5.6.1.2
`
`PICC rules
`
`
`
`When the PICC has been selected with the last command and
`
`3)
`
`receives a valid RATS, the PICC
`
`— shall send back its ATS and
`
`—— shall disable the RATS (stop responding to received RATS).
`
`b)
`
`receives any other block valid or invalid, except a HLTA Command, the PICC
`
`— shall ignore the block and
`
`— shall remain in receive mode.
`
`5.6.2 Handling of PPS request and PPS response
`
`5.6.2.1
`
`PCD rules
`
`When the POD has sent a PPS request and received a valid PPS response the PCB shall activate the selected
`parameters and continue operation.
`
`in any other case the POD may retransmit a PPS request and continue operation.
`
`12
`
`G) ISO/IEC 2000 —Ail rights reserved
`
`Apple Ex. 1032, p. 22
`Apple Ex. 1032, p. 22
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`ISO/IEC FDIS 1 4443-4:2000(E)
`
`5.6.2.2
`
`PICC rules
`
`When the PICC has received a RATS, sent its ATS and
`
`a)
`
`received a valid PPS request, the PICC
`
`— shall send the PPS response,
`
`- shall disable the PPS request (stop responding to received PPS requests) and
`
`— shall activate the received parameter.
`
`b)
`
`received an invalid block, the PICC
`
`— shall disable the PPS request (stop responding to received PPS requests) and
`
`(9 ISO/IEC 2000 —- All rights reserved
`
`—-
`
`shall remain in receive mode.
`
`0)
`
`received a valid block. except a PPS request, the PICC
`
`- shall disable the PPS request (stop responding to received PPS requests) and
`
`~— shall continue operation.
`
`5.6.3 Handling of the CID during activation
`
`When the PCD has sent a RATS containing a C|D=n not equal to O and
`
`a)
`
`received an ATS indicating CID is supported. the PCD
`
`w shall send blocks containing ClD=n to this PICC and
`
`— shall not use the ClD=n for further RATS while this PICC is in ACTIVE state.
`
`b)
`
`received an ATS indicating CID is not supported, the PCD
`
`- shall send blocks containing no CID to this PICC and
`
`—— shall not activate any other PICC while this PICC is in ACTIVE state.
`
`When the PCD has sent a RATS containing a CID equal to 0 and
`
`a)
`
`received an ATS indicating CID is supported. the PCD
`
`— may send blocks containing CID equal to 0 to this PICC and
`
`-— shall not activate any other PICC while this PICC is in ACTIVE state.
`
`b)
`
`received an ATS indicating CID is not supported. the PCD shall
`
`—-
`
`send blocks containing no CID to this PICC a