`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`DOCKET:915-606.056
`USSN: 10,937,084
`
`Re Application of: ROWSEetal.
`
`U.S. Serial No.: 10/937,084
`
`Filed: September8, 2004
`For: ELECTRONIC NEAR FIELD COMMUNICATION ENABLED
`
`MULTIFUNCTIONAL DEVICE AND METHOD OF ITS OPERATION
`
`Attorney Docket: 915-006.056
`
`Commissioner for Patents
`P.O. 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" pursuantto
`
`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
`
`Thereby certify that this correspondenceis being deposited with the United States Postal Service
`on the date shown below with sufficient postage as first class mail in an envelope addressed
`to the Commissioner far Patents, P.O. Box 1450, Alexandria, VA 22313-1450
`
`Deborah J. Clark
`
`Dated: Atcb. \ 2003
`
`Apple Ex. 1032, p. 1
`Apple Ex. 1032, p. 1
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`DOCKET:915-006.056
`USSN:16 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 1.56(a) exists.
`
`Also enclosed is a Form PTO/1449 listing the references enclosed.
`
`Respectfully submitted,
`
`WWnna /
`
`Wine
`
`Francis J. Maguire
`
`Attomey for the Applicant
`
`Registration No. 31,391
`
`FIM/djc
`Ware, Fressola, Van Der Sluys & Adoiphson 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
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`INFORMATION DISCLOSURE
`CITATION FORM FOR
`PATENT APPLICATION
`(FORM PTO-1449)
`(Substitute}
`
`Docket No.: 915-006.056
`
`Serial No.: 10/937,084
`
`Applicant(s): ROWSEetal.
`
`Filing Date: September 8, 2004
`U.S. PATENTS
`
`
`
`
`
`}teivals|Patent}PatentNumber||HssueDate|DatepoName Filing date
`
`class
`
`Customer No.: 4955
`
`OTHER DOCUMENTS(Title, Author, Date, Pages, Etc., if known
`MIFARE,Standard 4 kByte Card IC, MFI 1C S70, Functional Specification, Philips Semiconductors,
`Product Specification Rev. 3.1 October 2002, 17
`
`||fus.rarevrrusticanions |||
`Pa[RenanRR
`
`Initials
`
`Publication No.
`
`Pub. Date
`
`Name
`
`Class
`
`Sub-
`
`Filing Date
`
`FOREIGN PATENTSNR}Taitials|DocumentNumber
`Number|Datep Goumtty||encaton|anaaon|
`
`ISO/IEC FDIS 14443-4:2000(E), Identification cards - Contactless integrated circuit(s) cards -
`Proximity cards - Part 4: Transmission protocol, July 13, 2000, 44
`
`ECMA-352 Standard, Near Field Communication Interface and Protocol-2 (NFCIP-2}, December
`2003, 8 pages.
`
`Date Considered:
`Examiner’s Signature:
`Initial if reference was considered, whetheror notcitation is in conformance with MPEP. Mark throughcitation if not considered.
`Include a copy
`ofthis citation form with your next correspondence to the Applicant(s).
`
`Apple Ex. 1032, p. 3
`Apple Ex. 1032, p. 3
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`AFNPR
`
`Secrétariat CN CC/GE 8
`
`Votre correspondant: Jean-Claude HESLING
`
`Ligne diecte : + 33 142 91 57 08
`Courier électronique : jean-claude.hesling@ema'lafnor.tr
`Nos références : KIICH/AE
`
`CN CCIGE 8N 309
`
`2000-09-14
`
`TITRE:
`
`SOURCE :
`
`NOTE:
`
`Vote de la France sur I'iSO/CEl FDIS 14443-4 "Cartes
`d'identification - Cartes acircuit(s) intégrés sans contacts -
`cartes de proximité - Partie 4 : Protocole de transmission’
`
`Secrétariat Central de I'lSO
`
`Soumis au vote jusqu'au 14 novembre 2000. Une
`décision de principe de vote positif sans commentaires a
`été prise lors de la reunion GE 8 du 8 juin 2000
`(voir GE8 N 303).
`
`SUITE A DONNER:
`
`Pour examen en vue de la préparation du vote de ta France
`lors de la reunion GE 8 du 5 octobre 2000puisdécision lors
`de la réunion CNCC du 11 Octobre 2000.
`
`Association
`Frangaise de
`Nermalisation
`Tour Europe
`92049 Paris la Défense Cedex
`France
`Accés : La Défense 2
`Parking Les Corotles
`Tél: + 33.1 429155 55
`Télécopie : + 33:1 4291 56 56
`Minitel
`: 3646 AFNOR
`http: //www.sefnor.fe
`
`Association reconnue
`@utiite publique
`Goma membre frangais
`du CEN ot aa TISO
`Siro! 774720 818 00015
`Code NAF 751 E
`
`Apple Ex. 1032, p. 4
`Apple Ex. 1032, p. 4
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISO/IEC JTC1SC 17
`
`Date: 2000-97-13
`
`ISONEC FDIS 14443-4:2000(E)
`
`ISONEC JTC1SC 17AVG 8
`
`Secretariat: DIN
`
`identification cards —- Contactless integrated circuit(s) cards — Proximity
`cards — Part 4: Transmission protocol
`
`Cartes didentification — Cartes a circuit(s) intégrés sans contacts — Cartes de proximité — Partie 4 : Protocole de
`transmission
`
`international Standard
`Documenttype:
`Documentsubtype:
`Document stage:
`(50) Approval
`Document language: E
`
`GMSO_IEC\FOIS 14443-4\ISO-IEC 14443-4 (E).doc STO Versian 1.0
`
`Apple Ex. 1032, p. 5
`Apple Ex. 1032, p. 5
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`ISO/EC FDIS 14443-4:2000(E)
`
`Copyright notice —
`
`_ This 1SO document is a Draft Internationa! Standard and is copyrignt-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.
`I
`
`Requests for permission to reproduce should be addressed to ISO at the address bslow or |SO's member
`body in the country of the requester.
`
`i |'11
`
`|
`
`Copyright Manager
`ISO Central Secretariat
`7 rue de Varembé
`1211 Geneva 20 Switzerland
`tel. +41 22 7490117
`fax + 41 22 734 1079
`internet: 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
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISO/IEC FDIS 14443-4:2000(E)
`
`Contents
`
`4
`
`2
`
`SCOPE oo... ceccccseeessetsecnscseeescnessneenseaecccaseaneauerenseoneesceaeseasouseensenssscrsusiacensneasussenenrenecsssensesssnesepssessqseapesasonses 1
`
`Normative reference(s)...........:.ccscccecessesseseeenseceeeenseaeasentasseoscneesensnsensensensseancossenseensenseesnansnnessmesssonsonsevenenen 1
`
`Term(s) and definition(S)............. ees eeceeeeserceneenececeentsnnenssenersneenseneorsnenceuseeseetensoreapaaetengeeeranesroonesanensesane 1
`3
`
`Symbols (and abbreviated terms).....
`ved
`4
`
`Protocol activation of PICC Type A...
`wed
`5
`Request for answerto select ...
`6
`5.1
`
`on f
`Answerto select....................
`5.2
`
`
`Structure of the bytes..
`wel
`§.2.1
`wT
`5.2.2 Length byte...........0.
`
`wil
`5.2.3
`Format byte...
`
`we 8
`§.2.4
`Interface byte TA(1)..
`
`8
`5.2.5
`Interface byte TB(1)..
`
`9
`§.2.6
`Interface byte TC(1)..
`§.2.7 Historical bytes..........cscensessscenesesssrsssenerere
`9
`
`Protocol and parameterselection request...
`~
`we 10
`5.3
`
`a
`ws
`we 10
`Start byte...
`§.3.1
`
`.
`.
`woe 14
`Parameter 0...
`oe
`§.3.2.
`Parameter 4.0... ececereceeenecnsennersoeeusseeeeneraes
`eI
`5.3.3
`
`Protocol and parameter selection response
`11
`5.4
`
`12
`Activation frame waiting time ..........ccsecsseees
`5.5
`
`-12
`5.6
`Error detection and recovery ..
`
`5.6.1. Handling of RATS and ATS ............ccccsessesceee
`-12
`ane
`wee 12
`§.6.2 Handling of PPS request and PPS response
`§.6.3 Handling of the CID during activation. ................. secs csceneeeeceeseeneeneenrocseseeesersaresannesensauceecennesseesersesenteee 13
`6
`Protocol activation of PICC Type Bo... cccccssscassseesssensassssnanccnsensausseronesesaseeseseereeencecnrensenpecsessseusersven 14
`7
`Half-duplex block transmission Protocol ...........:sessiscssceerserssesersaeeeeeeseseecwanesseneernsieanenrensesereneanacweesnen® 15
`Block format... sstetssssessseeeseeterenssenes
`7.4
`
`Prologue field...............
`7.1.1
`
`Information field...........
`7.1.2
`
`7.1.3
`Epllogue field............
`
`Framewaiting time..............
`72
`Frame waiting time extension.
`7.3
`
`Powerlevel indication..........
`7.4
`
`
`Protocol operation.......
`7.5
`7.5.1 Multi-Activation.........
`
` Chaimirng......ccccccsseeserses
`7.5.2
`7.5.3 Block numbering rules
`
`7.5.4 Block handling rules.............
`”
`Error detection and reCOVEry .....c.scsscssccsrcsssscesenensnereneaseenenersssnenenaneusenssesnesereesesseeensensen nea reenenesenenen eye nesses 23
`7.5.5
`8
`Protocol deactivation of PICC Type A and Type Buu...ccssecssencsereesssnenseceeersnenanensananneossersanedaansacenes
`8.1
`Deactivation frame waiting time...........-.:.cccesees
`.
`8.2
`Error detection and recovery .........:cssecsrees
`
`Annex A (informative) Multi-Activation example ......cccccccssscersessserecnnareneceasrearsestsessanenerasersnneserenseanaatenssetons 26
`
`Annex B (informative) Protocol SCOMAariOS............:cccssscssssssecessensensseneensensseunenseversavenansnerssraceeuseaseversgsenseseareedees
`Notatlon..........ccessesseseecenaneseseneree ees
`B.1
`
`B.2
`Error-free operation.....
`
`Exchange of I-blocks................:000
`B.2.1
`
`B.2.2 Request for waiting time extension
`
`
`
`® ISO/IEC 2000 - All rights reserved
`
`iti
`
`Apple Ex. 1032, p. 7
`Apple Ex. 1032, p. 7
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISO/IEC FDIS 14443-4:2000(E)
`
`B.2.3 DESELECT000... cccssscsceccesenssenevsessseesensessespeassssusesespesenecssonssanessonepsoeeeeressesseensupsacsacenseecneesaneessasescaesanes 28
`B.2.4 Chaining... eeeeeececeneeseneeseesesnsensesseceaaeucessceeceassaucecesasuaaceceeesnsnssneseeaeeneuseeaeeespanseuseesenensspanseessessnecsaccares 28
`
`Emmor NANdling.............cccseeessenccenessececseeeeesseeeeectesenesenseoscsesesesensansesenseneqssensgaqeuseeeesassaeeasneasaesacensusnoeseeteese 29
`B.3
`
`B.3.1 Exchange of I-DIOCKS 20... ccesessesececesenssnascacenseenversrensstsenerensnsscsenssnssaseacoessensysneaseseagsersnesenensesenecnes 29
`
`B.3.2 Request for waiting time Extension .............::cccsssssssseesssceeessecnerecsounsesssenensessesessnsnsesereecepesssesauesssenseneness 30
`cencescssteeesceescencensesseceseestenenecnarnuaeseseasseaeeteeneceneceansansaseensees¢esecrensnastevesdecereesecensesease 32
`B.3.3) DESELECT ooo...
`
`B.3.4 Claiming... eee cecceeeescoreoseeseenavcneesssansceesseeencsseesnevecesscaecseserssereeneraseseveseevanesseensenersennensssanadceteesneesaosenee 33
`
`Annex C (informative) Block and frame Coding OVErViW...........cccsssssesesetesessacceansenerscensessceasenssuseesverreesaneaterranee 36
`
`iv
`
`@ISONEC 2000 ~ All rights reserved
`
`Apple Ex. 1032, p. 8
`Apple Ex. 1032, p. 8
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISO/IEC FDIS 14443-4:2000(E)
`
`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 !SO or IEC
`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 intemational organizations, governmental and non-governmental, in
`liaison with [SO 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, ISONEC 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 ISONEC 14443 may be tne subject of
`patent rights. SO 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 ISOMEC JTC , Information
`technology, Subcommittee SC 17, /dentification cards and related devices.
`
`ISO/IEC 14443 consists of the following parts, under the general titla identification cards — Contactless integrated
`circuit(s) cards — Proximity cards:
`
`— Part 1: Physical characteristics
`
`— Part 2: Radio frequency power and signal interface
`
`— Part 3: Initialization and anticollision
`
`— Part 4: Transmission protoco!
`
`The annexes A, B and C of this part of ISO/IEC 14443 are for information only.
`
`© ISQUEC 2000 - All rights reserved
`
`v
`
`Apple Ex. 1032, p. 9
`Apple Ex. 1032, p. 9
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISONEC FDIS 14443-4:2000(E)
`
`Introduction
`
`ISO/EC 14443 is one of a series of International Standards describing the parameters foridentification 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 in ISO/IEC 7816-5.
`
`ISONEC 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.
`
`
`
`vi
`
`®ISOEC 2000 — All rights reserved
`
`Apple Ex. 1032, p. 10
`Apple Ex. 1032, p. 10
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`
`
`FINAL DRAFT INTERNATIONAL STANDARD ISOHEC FDIS 14443-4:2000(E)
`
`identification cards — Contactless integrated circuit(s) cards —
`Proximity cards — Part 4: Transmission protocol
`
`1 Scope
`
`This part of ISONEC 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 ISONEC 14443 shall be used in conjunction with other parts of ISOAEC 14443 and is applicable to
`proximity cards of Type A and Type B.
`
`2 Normative reference(s)
`
`The following normative standards contain provisions, which, through referencein 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 onthis 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 [SO and !EC
`maintain registers of currently valid International Standards.
`
`ISONEC 7816-3, Identification cards — Integrated circuit(s) cards with contacts — Part 3: Electronic signals and
`transmission protocals.
`
`ISO/EC 7816-4, identification cards — Integrated circuit(s) cards with contacts — Part 4: Interindustry commandsfor
`interchange.
`
`|
`
`ISO/IEC 7816-5, Identification cards — Integrated circuit(s) cards with contacts — Part 5: Numbering system and
`registration procedure for application identifiers
`
`ISONEC 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
`ISOMEC 14443-3,
`tnitialization and anticollision
`
`-— Proximity cards
`
`-— Part 3:
`
`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:
`
`1 etu = 128 / (Dx fe)
`
`Theinitial value of the divisor D shall be 1. Therefore the resulting initial etu shall be:
`
`1 etu=128/ fe
`
`The carrier frequency fc is defined in ISO/IEC 14443-2
`
`@ISONEC 2000 - All rights reserved
`
`ah
`
`Apple Ex. 1032, p. 11
`Apple Ex. 1032, p. 11
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISONEC FDIS 14443-4:2000(E)
`
`3.2
`block
`a special type of frame, which contains a valid protocol data format. A valid protocol data format includes i-blocks,
`R-blocks or S-blocks
`
`3.3
`invalid block
`a type of frame, which contains an invalid protocol format. A time-out, when no frame has beenreceived, is not
`interpreted as an invalid block
`
`3.4
`frame
`a sequenceof 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
`
`positive ACKnowledgement
`
`AnswerTo Select
`
`Answer To reQuest, Type A
`
`Answer To reQuest, Type B
`
`Card |Dentifier
`
`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)
`
`Oivisor Send Integer (PICC to PCD)
`
`Error Detection Code
`
`elementary time unit
`
`carrier frequency
`
`Frame Size for proximity Card
`
`FrameSize for proximity Card Integer
`
`Frame Size for proximity coupling Device
`
`Frame Size for proximity coupling Device Integer
`
`Frame Waiting time Integer
`
`Frame Waiting Time
`
`ATS
`
`ATQA
`
`ATQB
`
`CID
`
`CRC
`
`D D
`
`R
`
`DRI
`
`DS
`
`DSI
`
`EDC
`
`etu
`
`fe
`
`FSC
`
`FSCI
`
`FSD
`
`FSDI
`
`FWl
`
`FWresp
`
`temporary Frame Waiting Time
`
`@ISONEC 2000 — At rights reserved
`
`
`
`Apple Ex. 1032, p. 12
`Apple Ex. 1032, p. 12
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISONEC FDIS 14443-4:2000(E)
`
`HLTA
`
`I-block
`
`INF
`
`MAX
`
`MIN
`
`NAD
`
`NAK
`
`OS!
`
`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 SystemsInterconnection
`
`Proteco! Contro! Byte
`
`Proximity Coupling Device
`
`Proximity Card
`
`Protoco! and Parameter Selection
`
`Protoco! and Parameter Selection Start
`
`Protoco! and Parameter Selection parameter 0
`
`Protocol! and Parameter Selection parameter 1
`
`R-block
`
`Receive ready black
`
`R(ACK)
`
`R-block containing a positive acknowiedge
`
`R(NAK)
`
`R-biock containing a negative acknowledge
`
`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
`
`@ISONEC 2000 - All rights reserved
`
`Apple Ex. 1032, p. 13
`Apple Ex. 1032, p. 13
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`ISO/IEC FDIS 14443-4:2000(E)
`
`5 Protocol activation of PICC Type A
`
`The foltowing activation sequence shall be applied:
`
`PICC activation sequence as defined in ISO/IEC 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
`ISONEC 14443-3.
`
`The PICC maybe set to HALT state, using the HLTA Command as defined in ISO/IEC 14443-3, if no ATSis
`available.
`
`The RATS may be sent by the PCD as next commandafter receiving the SAKif an ATSis available.
`
`The PICC shall send its ATS as answer to the RATS. The PICC shail only answerto the RATSif the RATSis
`received directly after the selection.
`
`If the PICC supports any changeable parameters in the ATS, a PPS request may be used by the PCD as the
`next command after receiving the ATS to change parameters.
`
`The PICC shall send a PPS Response as answerto 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 Ais shown in Figure 1.
`
`® ISONEC 2000 — All rights reserved
`
`Apple Ex. 1032, p. 14
`Apple Ex. 1032, p. 14
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISO/IEC FDIS 14443-4:2000(E)
`
`o
`or
`
`z=
`
`re3
`
`a
`
`-~>
`
`
`
`
`yi
`
`¢ :
`x
`oO
`Wl
`3
`
`:
`
`v
`
`5
`
`Apple Ex. 1032, p. 15
`Apple Ex. 1032, p. 15
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`Field On
`
`
`
`Send REQA
`
`
`
`
`Receive ATQA
`
`Send WUPA
`
`op
`
`
`
`
`
`
`
`
`Send HLTA
`
`ATS
`roNon |
`
`
`
`
`'
`available?
`1
`
`
`1.4protocol
`
`
`
`Receive ATS
`
`Send DESELECT Request
`
`Receive DESELECT Response
`
`
` yes
`
`Send RATS
`
`
`
`yes
`
`Parameter
`change?
`
`Send PPS Request
`
`Receive PPS Response
`
`
`
`
`
`
`
`
`
`Figure 1 — Activation of a PICC Type A by a PCD
`
`PPS
`supported?
`
`no
`
`
`
`Exchange
`Transparent
`Data
`
`OISONEC 2000 ~ All rights reserved
`
`
`
`

`

`ISONEC 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
`bee codes FSD! and CID
`
`Parameter
`
`The parameter byte consists of two parts (see Figure 3):
`
`Figure 2 — Request for answerto select
`
`-~ The most significant half-byte b8 to bS is called FSD! and codes FSD. The FSD defines the maximum size of a
`frame the PCD is able to receive. The coding of FSD is given in Table 1.
`
`— Theleast significant half byte b4 to b1 is named CID andit defines the logical number of the addressed PICC
`in the range from 0 to 14. The value 15 is RFU. The CID is specified by the PCD and shall be unique forall
`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 CID asits logical identifier, which is containedin thefirst error-free RATS received.
`
`[7[ossos[09]2oy]
`
`
`
`cID
`FSDI
`
`Figure 3 — Coding of RATS parameter byte
`
`Table 1— FSD! to FSD conversion
`
` RFU
`
`>256
`
`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.
`
`6
`
`@ ISO/IEC 2000 — All rights reserved
`
`
`
`Apple Ex. 1032, p. 16
`Apple Ex. 1032, p. 16
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISONEC FDIS 14443-4:2000(E)
`
`Length byte
`
`Historical bytes
`
`Format byte
`teas codes Y(1) and FSCl
`Interface bytes
`vane codes DS and DR
`
`tae codes FWI and SFGI
`
`Dene 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 numberof optional subsequent bytes in the following order:
`
`— formatbyte TO,
`
`— 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 TO is optional and is present as scon asthe length is greater than 1. The ATS can only contain the
`following optional bytes whenthis format byte is present.
`
`TO consists of three parts (see Figure 5):
`
`— The mostsignificant bit b8 shall be set to 0. The value 1 is RFU.
`
`— Thebits b7 to bS contain Y(1) indicating the presence of subsequentinterface bytes TC(1), TB(1) and TA(1).
`
`— Theleast significant half byte b4 to b1 is called FSCI and codes FSC. The FSC defines the maximum size of a
`frame accepted by the PICC. 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).
`
`© ISO/IEC 2000 ~ All rights reserved
`
`7
`
`Apple Ex. 1032, p. 17
`Apple Ex. 1032, p. 17
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`ISO/EC FDIS 14443-4:2000(E)
`
`FSCI
`
`TA(1) is transmitted, if bit is set to 1 + Y(1)
`
`TB(1) is transmitted, if bit is set to 1
`TC(1) is transmitted, if bitis set to 1
`shall be set to 0, 1 is RFU
`Figure 5 — Coding of format byte
`
`
`
`§.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 PCD, called DS. The
`default value shall be (O00}b.
`
`The bit b4 shall be set to (0)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.
`
`
`
`[68|b7|bé|65]b4|b3|62]bt]
`
`
`it}feytf
`
`
`L__- DR=2 supported, if bit is set to 1
`DR=4 supported, if bitis set to 1
`DR=8 supported, if bit is set to 1
`shall be set to 0, 1 is RFU
`DS=2 supported, if bit is set to 1
`DS=4 supported, if bit is set to 1
`DS=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 — Codingof interface byte TA(1)
`
`
`
`|
`
`The selection of a specific divisor D for each direction may be doneby the PCD using a PPS.
`
`5.2.5
`
`interface byte TB(1)
`
`The interface byte T8(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 FW! and codes FWT(see 7.2).
`
`8
`
`© ISONEC 2000 — All rights reserved
`
`Apple Ex. 1032, p. 18
`Apple Ex. 1032, p. 18
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISO/IEC FDIS 14443-4:2000(E)
`
`—— Theleast significant half byte b4 to b1 is called SFG! and codes a multiplier value used to define the SFGT.
`The SFGTdefines a specific guard time needed by the PICC beforeit is ready to receive the next frame afterit
`has sent the ATS. SFGlI 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 valuesin the range from 1 to 14 are used to calculate the SFGT with the formula given
`below. The default value of SFG} is 0.
`
`
`
`
`
`es]a7]655oa]2]
`
`CTE
`TE sro
`
`Figure 7 — Coding of interface byte TB(1)
`SFGTis calculated by the following formula:
`
`SFGT = (256 x 16/ fc)x 2°
`
`SFGTmn = minimum value as defined in ISO/IEC 14443-3
`
`SFGToerautt = minimum value as defined in ISOMEC 14443-3
`
`SFGTmax = ~4949 ms
`
`5.2.6
`
`Interface byte TC(1)
`
`The interface byte TC(1) specifies a parameter of the protoco!.
`
`The specific interface byte TC(1) consists of two parts (see Figure 8):
`
`—— The mostsignificant bits b8 to b3 shall be (000000)b andall other values are RFU.
`
`— The bits b2 and b1 define which optional fields in the prologue field a PICC does support. The PCDis allowed
`to skip fields, which are supported by the PICC, but a field not supported by the PICC shall never be
`transmitted by the PCD. The default value shall be (10)b indicating CID supported and NADnot supported.
`
`ba]e765][32m ofofojojojo|||
`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 numberof historical bytes. ISO/IEC 7816-4 specifies the content of the historical bytes.
`
`@ISONEC 2000 — All rights reserved
`
`9
`
`Apple Ex. 1032, p. 19
`Apple Ex. 1032, p. 19
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`ISO/IEC FDIS 14443-4:2000(E)
`
`5.3. Protocol and parameter selection request
`
`PPSrequest contains the start byte that is followed by two parameter bytes (see Figure 9).
`
`— The mostsignificant half byte b8 toe b5 shall be set to 'D’ and identifies the PPS.
`
`Start byte
`
`Parameter 0
`Lee codes presence of PPS1
`Parameter 1
`Lae codes DRI and DSI
`
`
`
`Figure 9 — Protocol and parameter selection request
`
`5.3.1 Start byte
`
`PPSSconsists of two parts (see Figure 10):
`
`— Theleast significant half byte b4 to b1 is named CID andit defines the logical numberof the addressed PICC.
`
`
`
`
`
`
`oa]87[26]5oe[w5[02]oy]
`
`ahfel]TfL
`| Tapshall be set to 1, 0 is RFU
`
`shall be set to 0, 1 is RFU
`shall be set to (11)b, all other values are RFU
`
`Figure 10 Coding of PPSS
`
`
`
`10
`
`© ISO/IEC 2000 — All rights reserved
`
`Apple Ex. 1032, p. 20
`Apple Ex. 1032, p. 20
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISONEC FDIS 14443-4:2000(E)
`
`§.3.2 Parameter 0
`
`PPSOindicates the presence of the optional byte PPS1 (see Figure 11).
`
`
`o8]27]6]5]be[63[52
`fotolot[efefels|
`r
`
`shall be set to 1, 0 is RFU
`shall be set to (000)b, all other values are RFU
`PPS1 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
`
`PPS1 consists of three parts (see Figure 12):
`
`—— The mostsignificant half byte 68 to b5 shail be (0000)b and all other values are RFU.
`
`— Thebits b4 and 53 are called DS! and code the selected divisor integer from PICC to PCD.
`
`— The bits b2 and b1 are called DRI and codethe selected divisor integer from PCD to PICC.
`
`
`
`
`
`8[57[e625[32
`
`
`fefele)||||
`| Te DRI
`shall be set to (Q000)b, all other values are RFU
`
`Figure 12 —- Coding of PPS1
`
`For the definition of DS and DR, see 5.2.4.
`
`The coding of Dis given in Table 2.
`
`Table 2 — DRI, DSI to D conversion
`
`ER[omTeTeOT
`
`
`
`PP
`
`
`
`5.4 Protocol and parameter selection response
`
`The PPS response acknowledgesthe received PPS request (see Figure 13) and it contains only the start byte (see
`5.3.1).
`
`@ISONEC 2000 — All rights reserved
`
`11
`
`Apple Ex. 1032, p. 21
`Apple Ex. 1032, p. 21
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`PICC rules
`
`ISO/IEC 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 recelved from the PCD and has a value of 65536/fe (~4833 ps).
`
`NOTE
`
`The minimum time between framesin any direction is defined in ISONEC 14443-3.
`
`5.6 Error detection and recovery
`
`5.6.1 Handling of RATS and ATS
`
`5.6.1.1
`
`PCDrules
`
`Whenthe PCD has sent the RATS and receives a valid ATS the PCD shall continue operation.
`
`In any other case the PCD may retransmit the RATS before it shall use the deactivation sequence as defined in
`clause 8.
`|n case offailure of this deactivation sequence it may use the HLTA Commandas defined in ISO/IEC
`14443-3.
`
`5.6.1.2
`
`Whenthe PICC has been selected with the last command and
`
`a)
`
`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.
`
`§.6.2 Handling of PPS request and PPS response
`
`5.6.2.1
`
`PCDrules
`
`When the PCD has sent a PPS request and received a valid PPS response the PCD shall activate the selected
`parameters and continue operation.
`
`In any other case the PCD mayretransmit a PPS request and continue operation.
`
`12
`
`© ISO/IEC 2000 — All rights reserved
`
`Apple Ex. 1032, p. 22
`Apple Ex. 1032, p. 22
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`ISO/IEC FDIS 14443-4:2000(E)
`
`5.6.2.2
`
`PICC rules
`
`Whenthe PICC hasreceived a RATS, sentits 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)
`
`— shall remain in receive mode.
`
`c)
`
`received a valid block, except a PPS request, the PICC
`
`— shall disable the PPS request (stop responding to received PPS requests) and
`
`received an invalid block, the PICC
`— shall disable the PPS request (stop responding to received PPS requests) and
`
`@ISONEC 2000 — All rights reserved
`
`—— shail continue operation.
`
`5.6.3 Handling of the CID during activation
`
`When the PCD has sent a RATScontaining a CID=n not equal to 0 and
`
`a)
`
`received an ATSindicating CID is supported, the PCD
`
`—-
`
`shall send blocks containing CID=n to this PICC and
`
`— shall not use the CID=n for further RATS while this PICC is in ACTIVEstate.
`
`b)
`
`received an ATSindicating 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