`
`|
`
`|
`IN THE UNITED STATES PATENT AND TRADEMARKOFFICE
`oat
`|
`
`el
`|
`PATENT
`
`in re Application of
`Romain PALMADE
`Serial No. 10/471,883
`
`: Atty. Docket: 00-RO-379
`: Group Art Unit: 2876
`: Confirmation No. 9579
`
`.
`
`‘Examiner: Daniel A. Hess
`Filed: September 12, 2003
`For: CONTACTLESS IC CARD WITH OPERATING SYSTEM USED IN CONTACT TYPE CARDS AND
`READER FOR SUCH CONTACTLESS CARDS
`
`INFORMATION DISCLOSURE STATEMENT
`
`“Mail Stop Amendment
`COURTESY COPYof IDS with 4 non-US references;
`Commissionerfor Patents
`previously sent along with Petition to Withdraw from
` ‘
`P.O. Box 1450
`Issue and RCE faxed to MS 313(c) on May3, 20
`Alexandria, VA 22313-1450
`rind
`
`Mariah Moorhead
`/
`
`SIR:
`
`The attached Form PTO-1449 providesa listing of information which maybe relevant to the subject
`application. This IDS is not intended as a representation that better art is not available, nor that other art than
`thatidentified exists; nor that the information providedis prior art; nor that a search has been made.
`
`This IDS is submitted under:
`—XX 37 CFR 1.97(b) - No Fee.
`___... 37 CFR 1.97(c) - No Fee, with Certification.
`____. 37 CFR 1.97(c) - Fee.
`___.. 37 CFR 1.97(d) - Fee, Certification & Petition.
`
`The Commissioner is authorized to charge any required fees under 37 CFR 1.17(p) and (i) (1) to
`
`Deposit Account No. 50-1556.
`
`‘
`
`Date:
`
`: od 00 b
`
`FLEIT, KAIN, GIBBONS, GUTMAN, BONGINI & BIANCO P.L.
`551 NW 77th Street, Suite 1114
`BocaRaton, Florida 33487
`Telephone: (561) 989-981 1
`Facsimile : (561) 989-9812
`
`
`
`Apple Ex. 1029, p. 1
`Apple Ex. 1029, p. 1
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
` U.S. Dept. of Commerce|Atty. Docket: 00-RO-379
`Serial No. 10/471,883
`
`Patent & Trademark Office
` Applicant: Romain PALMADE
`.
`of Documents
`Group: 2876
`
`
`
`
`Filing Date,if
`
`ist
`
`Filing Date: September 12, 2003
`
`\y
`\
`
`applicable
`Number
`
`Document
`
`
`
`
`Rankl, W., et al., “Handbuch der Chipkarten,” 3, vdllig Uberarb. und erw. Aufl., MGnchen, Wien, Hanser, 1999,
`http:/Awww.hanser.de, ISBN 3-446-21115-2
`
`“Information technology -- Identification cards -- Integrated circuit(s) cards with contacts, Part 4: Interindustry commands
`
`for interchange,” International Standard, ISO/IEC 7816-4, First edition 1995(E), pp. 1-46
`
`
`
`“(nformation technology-- identification cards -- Integrated circuit(s) cards with contacts, Part 3: Electronic signals and
`transmission protocols,” International Standard, ISO/IEC 7816-3, Second edition 1997(E), pp. 1-27
`
`ISOMEC FCD 14443-4, 2000-03-10, pp. 1-33
` “Identification cards ~ Contactless integrated circuit(s) cards ~ Proximity cards, Part 4: Transmission protocol,” Draft
`
`
`
`
`
`Date Considered: Examiner:
`
`
` include copyof this form with next communication to applicant.
` EXAMINER:Initial if reference considered, whether or not citation is in conformance with MPEP 609; Drawline through citation if not in
`conformance and not considered.
`
`
`
`|
`
`i
`Apple Ex. 1029, p. 2
`Apple Ex. 1029, p. 2
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`|I
`
`|
`
`BEST AVAILABLE COPY
`INTERNATIONAL
`STANDARD |
`
`(os)
`ISO/IEC
`7816-4
`
`First edition
`1995-09-01
`
`——SSESSESS
`
`Information technology — Identification
`cards — Integrated circuit(s) cards with
`contacts —
`
`Part 4:
`Interindustry commandsfor interchange
`
`Technologies ce l'information — Cartes d'identification — Cares 4
`Cis) INegrais) a toniacz:s —
`Partie 4: Commandes intersectorielles pour les échanges
`
`
`
` Reference number
`
`_
`ot
`~~ wt
`.
`.
`ate
`*
`Trad VecviobStigung It. vark iSc-Geawmnmigung
`
`ISOAEC 7816-4:19951E}
`
`Apple Ex. 1029, p. 3
`Apple Ex. 1029, p. 3
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`ISO/IEC 7816-4: 1995 (E)
`
`Contents
`
`FOPOWOIG o.cceceeccsseeeeeerenseeeecerecesesesseuteranensrenssenaatsenennatmeens
`
`UMUTODUCRION oes eeceeeseceeseeseessecentsssennterecscuseses seesnenescaes eeseearseosesnsanercananacsesenstsee
`
`
`Po
`
`SCOPE ooo c cece rcteteeeeseseceteeneensnes ooneersnepestsenesenesenenenenerantisnersneneaasaventeneesaneeres
`
`QZ Normanve references oo.cpecesnesssnescnnnesesneeutsernserspsesrseeerereessnsseeeies
`
`3. Definit:ans
`
`4 Abbreviations ard Notation 20.0... eceerresteseceremecneaannennaeceees
`3
`BK Basic OFGAMIZIVOMS «.....eenseersesesseesennensenerencsteetenescescenneeacsneesnasentceeaetare testes
`3
`5.1
`Dla SULTLUSES .0.-ceesseresers
`
`6
`5.2
`Securrty erchizecture of the ca
`7
`5.3
`“POU message structure
`seeceee teeeesscteeteessennenseentans
`
`5.4
`fading conventions fer command headers,
`g
`sata fielts ara response wailers ....
`wee
`12
`Logical cnannets |...
`5.5
`
`2
`5.6
`Secure messaging ...
`GB Basic mterindustry COMMAMNAS q........esssesereneeenreneecerereerees receeneeereeaeenansnens 16
`
`atttetsserseesaneeee
`READ BIRARY command .......ccse-
`6.1
`16
`WRITE BsARY command ..
`6.2
`.
`
`UPDATE SINARY command
`6.3
`7
`SRASE BINARY command.....
`6.4
`18
`
`
`READ RELDACIS) command .
`6.5
`2
`
`WRITE RETOND command .
`6.6
`20
`
`
`APPEND SSCGAO command .
`6.7
`a
`
`UPDATE SECCRD command .
`6.8
`22
`
`ET DATS command .....
`6.3
`23
`
`SUT DATS command ..
`6.10
`24
`
`SELECT =LE command .
`6.11
`25
`SERUFY STITANG q... 2... eee reseeetneeennee
`6.12
`26
`6.13
`‘NTERN2. ALTHENTICATE command ..
`2?
`6.14°
`EXTERNS. AUTHENTICATE command...
`27
`GET CHA.LENGE commana...........
`6.15
`28
`
`29
`6.16
`MANAGE CHANNEL command ..
`
`7. Transmussion-onented interindustry commands
`7.4
`GET RESPONSE command.....
`
`ENVELOPE commanda .........-
`7.2
`
`Historical DYTES «2.0... seeeeseersersenreeneerctee sees crseneranenenen taaeansanenedeve cesessornsearsseones
`31
` Application-independent card services ........
`
`
`
`'
`
`'
`i
`
`Annexes
`Transportation of APOU messages by T=0 ...
`Transportation of APDU messages by T=1
`
`Record POINTES MANAGEMENT ........-cnccceserertereersereeee”
`Use of the basic encoding rules of ASN.1 .....-..---.----
`Examples of card profiles .....
`;
`Use of secure messaging ....
`
`amoamp
`
`
`
`
`
`
`© ISONEC 1995
`
`All. rights reserved. Uniess otherwise specified, no part of this publication may be
`reproduced or utilized in any form or by sny means, electronic or mechanical, inctuding
`photocopying and microfilm, without parmission in writing trom the publisher.
`ISOAEC Copyright Otlice * Case Postale 56 © CH-1211 Genéve 20.¢ Switzerland
`Printed in Switzerland
`
`Apple Ex. 1029, p. 4
`Apple Ex. 1029, p. 4
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`
`
`© ISOAEC
`
`ISO/IEC 7816-4: 1995 (E)
`
`Foreword
`
`tSO (the International Organization for Standardization) and |EC {the
`International Electrotechnical Commission) form the specialzed systemfor
`worldwide standardization. National bodies that 2°e members of ISO or IEC
`participate in the development of International Siansards tnrough technical
`committees established by the respective organizatio~ to dea: with particular
`fields of technical activity. [SO and {EC technical committees collaborate in
`fields of mutual interest. Other internationa! organiza:.ons, governmental and
`non-governmental, in liaison with ISO and IEC, also taxe part in the work.
`
`!SO and !EC have established a joint
`In the field of information technology,
`technical committee, ISOAEC JTC 1. Draft imernational Standards adopted by
`the joint technical commitiee are circulated to. national bodies for voting.
`Publication as an International Standard requires approval by at least 75 % of
`the nationat bodies casting a vote.
`
`International Standard ISO/IEC 7816-4 was prepered by Joint Technical
`Committee ISO/IEC JTC 1. information technology.
`
`(ISO/IEC 7816 consists of the following. parts, under the general title Informa-
`tion technology — Identification cards — Integratec circuit/s) cards with
`contacts.
`
`— Part}: Physical characteristics,
`-~ Part 2: Dimensions and location of the contacts,
`— Part 3: Electronic signals and transmissior pretocols,
`~~ Pant 4:
`interindustry commands for interchange,
`— Part 5: Numbering system and registration procedure for application
`identifiers,
`.-
`_
`— Part G:
`
`Interindustry data elements.
`
`Annexes A and B form anintegral part of this pait of [SO/EC 7816. Annexes C,
`O, E and F are for information only.
`
`Apple Ex. 1029, p. 5
`Apple Ex. 1029, p. 5
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`ISO/IEC 7816-4: 1995 (E}
`
`@ISONEC
`
`
`
`Introduction
`
`.
`
`This pat of ISO/IEC 7816 is one of a series of standards describing the
`pavameters for integrated circuits) cards with contacts and the use of such
`cards fc- international interchange.
`,
`
`These cards are identification cards intended for information exchange nego-
`tiated beiween the outside and the integrated circuit in the card. As a resutt of
`an information exchange, the card delivers information {computation results.
`sicred czia), anz/or modifies its content (data storage, event memorization).
`
`Apple Ex. 1029, p. 6
`Apple Ex. 1029, p. 6
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`
`
`

`

`
`
`
`
`ISO/IEC 7816-4: 1995 (E)
`“INTERNATIONAL STANDARD © ISONEC
`
`
`Information technology — Identification cards
`— Integrated circuit(s) cards with contacts —
`
`Part 4:
`‘ Interindustry commands for-interchange
`
`1 Scope
`_g) This part of ISO/IEC 7816 specifies
`— the content of the messages, commands and res-
`ponses, transmitted by the interface device to the
`card and conversely.
`—the structure and content of the historical bytes
`sent by the card during the answerto reset,
`—the structure of files and data, as seen at the
`interlace when processing interindustry commands
`for interchange,
`= access methods to files and data in the card,
`— 8 security architecture defining access rights to
`files and data in the card,
`— methods for secure messaging.
`= access methods to the algorithms processed by
`the card. It does not describe these algorithms.
`
`It does not cover the internal implementation within the
`card and/or the outside world.
`
`tt allows further standardization of additional interindustry
`commands and security architectures.
`
`2 Normative references
`
`The following standards contain provisions which,
`through reference in this text, constitute provisions of this
`part of ISO/IEC 7816. At the time of publication,
`the
`editions indicated were valid. All standards are subject to
`revision, and parues to agreements based on this par of
`ISO/IEC 7816 sre encouraged to investigate the possibility
`of applying the most recent editions of the standards
`indicated below. Members of
`|EC and ISO maintain
`registers of currently valid Internationa! Standards.
`ISO 3166: 1993, Codes for the representation of names:
`of countries.
`
`ISONEC 7812-1 : 1993, Identification cards — Identification
`of issuers — Part 1: Numbering system.
`
`ISONEC 7816-3 : 1989, Identification cards — Integrsted
`circuit(s) cards with contacts — Part 3: Electronic signals
`and trensmission protocols.
`
`Amendment 1:1982 to {SO/IEC 7816-3 : 1989, Protocol
`type T=1, asynchronous half duplex block transmission
`protocol.
`
`Apple Ex. 1029, p. 7
`Apple Ex. 1029, p. 7
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`
`
`

`

`
`
`
`
`
`
`. ISO/IEC 7816-4: 1935 {E)
`
`@ISOMEC
`
`Amendment2: 1994 to ISO/IEC 7816-3: 1989, Revision
`of protocol type selection.
`.
`ISO/IEC 7816-5: 1994, identification cards — Integrated
`cireuit(s) cards with contacts —- PartS: Numbering sys-
`tem and registration procedure for application identifiers.
`ISOAEC 7816-6 :—"), Identification cards — Integrated
`circuit(s) cards with contacts — Part G: Interindustry data
`elements.
`,
`
`ISO/IEC 8825: 1990 2), Information technology — Open
`Systems Interconnection — Specification af Basic Encod-
`ing Rules for Abstract Syntax Notation One (ASN.1).
`ISO/IEC 9796: 1991, Information technology -- Security
`techniques — Digital signature scheme giving message
`recovery.
`
`ISO/IEC 9797: 1994, Information technalogy ~~ Security
`techniques — Data integrity mechanism using a crypto-
`graphic check function employing a block cipher
`algorithm.
`
`ISO/IEC 9979: 1991, Dara cryptographic techniques —
`Procedures for the registration of cryptographic algo-
`rithms.
`
`Information technology — Modes of
`ISOAEC 101161981.
`operation foran n-bit o1ock cipher algorithm.
`technology —
`ISO/IEC 10118-1: 1994,
`Information
`7: General.
`Security techniques — Hash-functions —— Part
`
`.
`
`Information technology .—
`ISO/IEC 10118-2: 1994,
`Security techniques — Hash-functions — Pan 2: Hash-
`functions using an r-dit block cipher algorithm.
`
`3 Definitions
`
`For the purposes of this part of ISO/IEC 78136, the follow-
`ing definitions apply.
`,
`
`3.1 Answer-to-Reset file: Elementary file which
`indicates operating characteristics of the card.
`
`command-response pair: Set of two messages:
`3.2
`a commandfollowed by @ response.
`
` dataunit: The smallest set of bits which can be
`3.3
`unambiguously referenced.
`
`tn this pact of ISO/IEC 7816, data objects are
`element).
`referred to as BER-TLV, COMPACT-TLV and SIMPLE-TLV data
`objects.
`
`infor-
`dedicated file: File containing file control
`3.6
`mation and, optionally, memory available for allocation. It
`may be the parent of EFs and/or DFs.
`
`OF name: String of bytes which uniquely identifies
`3.7.
`8 dedicated file in the card.
`
`directory file: Elementary file defined in part 5 of
`3.8
`ISO/IEC 7816.
`
`elementary file: Set of data units or records
`3.9
`which share the same file identifier, t cannot be the
`parent of another file.
`
`3.10 fils control parameters: Logical, structural and
`security attributes of a file.
`
`3.11 file identifier: A 2-bytes binary value used to
`address a file.
`
`3.12 file management data: Any information about 3
`file except the file control pararreters (€
`s., expiration
`date, application tabel).
`
`3.13 internal elementary file: Elemeciary file tor
`storing data interpreted by the cara
`
`3:14 master file: The manda:or. unique dedicated file
`representing the root of the file structure.
`
`3.15 message: Suing of bytes transmitted by the
`interface device to the card or vice-versa, excluding
`transmissior-oriented characters as defined in part 3 of
`ISO/IEC 7816.
`
`3.16 parent file: The dedicated file immediately pre-
`ceding a given file within the hierarcny.
`
`3.17 password: Data which may be required by the
`application 10 be presented to the ced by its user.
`
`3.18 path: Concatenation of fie identifiers without
`dehmitation.
`If the path starts win the :centifier of the
`master fite, it is an absoiute path.
`
`3.39 provider: Authority who has or who obtained the
`right to create a dedicatedfile in the card.
`
`3.20 record: String of bytes which can be handled as a
`whole by the card and referenced by a record number or
`by e record identifier.
`.
`
`data element: item of information seen at the
`3.4
`interface for which are defined 8 name, 8 description of
`togical content, a format and a coding.
`
`3.21 record Identifier: Value associated with a record
`that can be used to reference. that record. Several records
`may have the sameidentifier within an elementary file.
`
`information seen at the interface
`data object:
`3.5.
`which consists of a tag, a length and a value {i.e., @ data
`
`
`3.22 record number: Sequential number assigned to
`each record which uniquely identifies the recard within its
`elementary file.
`
`U To be published.
`2) Currently under revision.
`
`3.23 working elementary file: Elementary file for
`$toring data not interpreted. by the card.
`
`Apple Ex. 1029, p. 8
`Apple Ex. 1029, p. 8
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`For the purposesof this part of ISO/EC 7816,the follow-
`ing abbreviations apply.
`APDU
`Application protocol data unit
`ATR
`Answer to reset
`The following two types of EFs are defined.
`- BER
`Basie encoding rules of ASN.1 (see annex D)
`~~ Internal EF — Those EFs are intended for storing
`CLA
`Class byte
`data interpreted by the card, i.e., data analyzed and
`;
`used by the card for management and contro!
`BIR
`Directory
`Purposes.
`.
`.
`.
`DF
`Dedicated file
`‘— Working EF — Those EFs are intended for storing
`eF
`Elementary file
`data not interpreted by the card, i.e., data to be used
`FCI
`Fiie control information
`by the outside world exclusively.
`FCP
`File control parameter
`
`FMD Figure1illustrates an example of the logicalfile organiza-File management data
`
`) INS
`Instruction byte
`tion in a card.
`MF
`Masterfile
`P1-P2
`Parameter bytes
`PTS
`Protocol type selection
`REU
`Reserved for future use
`SM
`Secure messaging
`Swi-§.V2
`Status bytes
`TLV
`Tag. length, value
`TFOU
`Transmission protocol data unit
`
`For the purposes of this pam of ISO/IEC 7816, the follow-
`ing notation applies.
`‘O' to ‘S' and ‘A’ to ‘F’ The sixteen hexadecimal digits
`(By)
`Value of byte B,
`B.1B;
`Conceatenation of bytes B, (the most significant
`,
`ignificant
`byte) and B2 {theleast sign! icant byte)
`(B; 1&2) Value of the concatenation of bytes B, and Bz
`Number
`*
`
`5 Basic organizations
`
`5.1 Data structures
`
`This clause contains information on the logical structure
`of data as seen at
`the interface, when processing
`interindustry commands for
`interchange. The actual
`storage location of data and structural
`information
`beyond what is described in this clause are outside the
`scope of ISO/IEC 7816.
`
`. 5.1.1
`
`File organization
`
`This part of ISO/IEC 7816 supports the following two cate-
`gories offiles.
`.
`— Dedicated file (OF).
`
`— Elernemary file (EF).
`
`5.1.2
`
`File referencing methods
`
`Whena file cannot be implicitly selected, nt shall be possi-
`ble to select it by at least one of the following methods.
`.
`.
`.
`;
`— Referencing byfile identifier — Any file may be ref-
`erencedby a file identifier coded on 2 bytes. If the MF is
`referenced by a file identifier,
`‘3FOO' shall be used
`(reserved value}. The value 'FFFF'
`is reserved for future
`use. The value '3FFF’
`is reserved (see referencing by
`path).
`In order to select unambiguously any file by its
`identifier, al! EFs and OFs immediately under a given DF
`shall have different fite identifiers.
`
`— Referencing by path — Anyfile may be referenced by
`@ path {concatenation of file iderz‘fiers). The path begins
`with the identifier of the MF or of the current DF and ends
`with the identifier of the file itself. Between those two
`identifiers,
`the path consists of the identifiers of the_
`successive patent DFs if any. The order of the file
`identifiers is always in the direction parent to child. If the
`identifier of the current OF is not known, the value ‘3FFF'
`(reserved value) can be used at the beginning of the path.
`The path allows an unambiguous selection of any file
`from the MF or from the current DF.
`
`— Referencingby short EF identifier — Any EF may be
`referenced by a short EF identifier coded on 5 bits valued
`in the range from 1 to 30. The value O used as @ short EF
`identifier references the currently selected EF. Short EF
`identifiers cannot be used in a path or as a file identifier
`(e.g., in a SELECT FILE command).
`
`Apple Ex. 1029, p. 9
`Apple Ex. 1029, p. 9
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`
`
`© ISONEC
`
`ISO/IEC 7846-4; 1995 (E)
`
`The logical organization of data in a card consists of the
`following structural! hierarchy of dedicated files.
`— The OF at the root is called the master file (MF).
`The MF is mandatory.
`— The other DFs are optional.
`
`,
`
`Figure 1 — Logical file organization (exarnpte)
`
`4 Abbreviations and notstion
`
`,
`
`

`

`
`
`ISO/IEC 7816-4: 1995 (E)
`
`© ISONEC
`
`
`
`~— Referencing by DF name — Any DF may be refer-
`enced by a OF name coded on 1
`to 16 bytes.In order to
`select unambiguously by DF name (e.g., when selecting
`by means of application identifiers as defined in part 5 of
`ISO/IEC 7816}, each DF name shall be unique within a
`given card.
`
`5.1.3 Elementary file structures
`
`The following structures of EFs are defined.
`— Transparent structure — The EF ig seen at the
`intetace as a sequence of data units.
`— Facord structure — The EF is seen at the interface
`as 2 sequence ofindividually identifiable records.
`
`The following attributes are defined for EFs structured in
`records
`—— S2e of the records : eitherfixed or variable.
`— crganization of the records: either as a sequence
`. (linear structure) or as a ring (cyclic structure).
`:
`
`The ca‘2 shall support at least one of the following four
`methocs for structuring EFs.
`-- ~ransparent EF.
`~— . rear EF with records of fixed size.
`— . 7eaF file with records of vanable size.
`w= Zyvclic EF with records of fixed size.
`
`Figure z shows those four EF structures.
`Linear variable
`
`Cycle fixed
`
`6.1.4.1
`
`Record referencing
`
`Within each EF of record structure, each record can be
`referenced by a record identifier and/or by a record
`number. Record identifiers and record numbers are
`unsigned 8-bdit integers with values in the range from ‘01’
`to FE’. The value ‘00° is reserved far special purposes.
`The value ‘FF’ is RFU.
`
`induce the man-
`Referencing by record identifier shall
`agement of a record pointer. A reset of the card, a
`SELECT FLE and any command carrying a valid short EF
`identifier can affect the record pointer. Referencing by
`record number shall not affect the record pointer.
`7
`
`— Referencing by record identifier — Each record iden-
`tifier is provided by an application. If a record is a SimPLEe-
`Tiv data object in the data field of a message (see 5.4.4},
`then the record identifier is the first byte of the data
`object. Within an EF of record structure, records may
`have the same record identifier,
`in which case data
`contained in the records may be used for discriminating
`between them.
`
`Each time a reference is made witr a recors identifier, an
`indication shali specify the togice sositior of the target
`record. the frst or blast occurrences the ner* or previous
`occurrence relaive to the recard pointer.
`
`— Within each EF of linear structure, the logical posi-
`tions shall be sequentially ass gned wen writng or
`appending. 1€.,
`in the order of creation. Therefore the
`first created recard is in the firs: logical position.
`
`-~ Within each EF of cyclic structure, the logical posi-
`tions shall be sequentially assigned in the opposite
`order, i.e.. the most recently created record is in the
`first logical position.
`
`The following additional rules are defined for linear struc-
`tures and for cyclic structures.
`
`Transzarent=Linear fixed
`
`Figure 2 - EF structures
`NOTE — Tne arrow on the figure references the most recently
`written cecord.
`
`5.1.4 Data referencing methods
`
`Data may be referenced as records, as data units of as
`data ot ects. Data is considered to be stored in a single
`continuous sequence of records (within an EF of record
`structuse) or of data units {within an EF of transparent
`structure). Reference to a record or 10 3 data unit outside
`an EF is an error.
`
`Data referencing method, record numbering method and
`data unit size are EF-cependent features. The card can
`provide indications in the ATR, in the ATR file and in any
`_ file control information. When the card provides indica-
`tions in several places, the indication valid for a given EF
`is the closest one to that EF within the path from the MF
`to that EF.
`_
`
`
`
`— The first occurrence shall be the record with the
`specified identifier and in the first logica! position ; the
`last occurrence shall be the resord wr the specified
`identifier and in the tast logica! position.
`
`—~ When there is no current record, the next occur-
`rence shall be equivaient to the first occurrence; the
`previous occurrence shai: be equivalent to the last
`eccurrence.
`
`— Whenthere is a current record, the next occur-
`rence shali be the closest record with the specified
`identifier but in a greater logical position than the cur-
`rent record; the previous occurrence shall be the
`closest record. with the specified identifier but in a
`smaller logica! position than the current record.
`
`— The value ‘00° shall refer to the first, last, next or
`previous record in the numbering sequence, indepen
`dently from the record identifier.
`
`Apple Ex. 1029, p. 10
`Apple Ex. 1029, p. 10
` Apple v. Fintiv
`Applev. Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`- @ ISOJEC
`
`ISO/IEC 7816-4; 1995 (E)
`
`— Referencing by record number — Within each EF of
`record structure, the record numbers are unique and
`sequential.
`
`— Within each EF of linear structure, the record num-
`bers shall be sequentially assigned when writing or
`appending,i.e., in the order of creation. Therefore the
`first record (record number one, # 1)
`is the first
`created record.
`
`— Within each EF of cyclic structure, the record num-
`bers shall be sequentially assigned in the opposite
`order, i.e., the first record (record number one, # 1) is
`the most recently created record.
`
`The following additional rule is defined for linear struc
`tures and for cyclic structures.
`
`— The value ‘00° shall refer to the current record, i.e.,
`that record fixed by the record pointer.
`
`5.1.4.2 Data unit referencing
`
`Vvithin eacr, EF of transparent structure, each data unit
`can be 're*erences by an offset (e.g..
`in READ BINARY
`command. see 6.1!.
`It
`is an unsigned integer, limited to
`either & of 15 bits accarding to an option in the respective
`command. Valued to O for the first data unit of the EF, the
`offset is inzsemented by 1 for every subsequen: data unit.
`
`if the card gives no indication, the size of
`By default, i.e.,
`the: dataunit is one byte.
`NOTES
`
`An EF of record structure may support data unit referencing
`1
`and, in case it does, dats units may contain structural intorma-
`tion along v.th data, e.g., record numbers in a linear structure.
`
`2 Within an EF of record structure, data uni referencing may
`nat provide the intended result because the storage order of
`the records :- the EF 1s mot known, e€.g.. Storage order in a cyclic
`Structure.
`
`5.1.4.3' Data object referencing
`
`Each data object (es defined in 5.4 4) is headed by a tag
`which references it. Tags are specified in this part and
`other parts of ISO/IEC 7816.
`
`
`
`5.1.5
`
`File contro! information
`
`Thefile control information (FC) is the string of data bytes
`available in response to a SELECT FILE command. Thefile
`control information may be present for any file.
`
`Table 1 introduces 3 templates intended for conveying file
`control information when coded es BER-TLY data objects.
`— The FCP template is intended for conveying file .
`contro! parameters (FCP),
`i.e., any BEAR-TIV data |
`objects defined in table 2.
`
`—~ The FMD temniate is intended for conveying file
`management data (FMO},
`i.e., BER-NV data objects
`specified in other clauses of this part or in other pasts
`of ISO/IEC 7816 (e.9.. application label as defined in
`pan and application expiration date as defined in
`part
`6).
`~— The FCi template is intended for conveying file
`control parameters and file management data.
`
`Table 1 — Templates relevant to FC!
`
`F 2 conrol infermaten ‘Flt resp etet
`
`Fue
`control parameters i
`F ¢ ~anagemen: azze ("4D temz.zte}
`
`The 2 temp'ztes may be Tetraves according te selection
`options of tre SELECT FILE commend (See table 59).
`If the
`FCP or FMD option is set.
`tnen the use of the corre-
`sponding template is mandatory.!f the FCI option is set,
`then the use of the FCi template is optional.
`
`Part of the file control information may additionally be
`Present in @ working EF under control of an application
`and referenced under tag ‘87°. The useof the FCP or FCI
`template is mandatory for the coding of
`file control
`information in such an EF.
`
`File contro! information not coded according to this part
`of ISO/IEC 781€ may be introauced as follows.
`— ‘00° or any value higher than '9F’ — The coding of
`the subsequentstring of bytes is proprietary.
`— Tag = ‘53° — The value field of
`the data object
`consists of discretionary cata not coded in TLV.
`— Tag = ‘73"— The value field of
`the data object
`we
`consists of discretionary 8&A-"Lw data objects.
`
`Apple Ex. 1029, p. 11
`Apple Ex. 1029, p. 11
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISO/IEC 7815-4: 1995 (E)
`
`© IsonEC
`
`Table 2 — File contro! parameters
`
`Transperen
`t EFs
`
`
`
`5.2 Security architecture of the card
`
`This clause describes the following features:
`— security status,
`— secunty attributes,
`— security mechanisms.
`
`Security attributes are compared with the security statu:
`to execule Commands and/or to accessfiles.
`:
`
`5.2.1
`
`Security status
`
`
`Number of date bytes
`
`
`in the file, excluding
`
`
`structural information
` Number of data bytes
`
`
`in the file, including”
`
`
`structural information if any
`
`
`File descriptor byte
`Anyfile
`(see table 3!
`
`
`
`Any file
`File descriptor byte tollowed
`
`by date coding byte
`(see table 86)
`
`
`EFs with
`File descriptor byte followed
`
`
`record
`by data coding byte and
`Security status represents the current state possibly
`
`
`maximum record length
`structure
`
`achieved after completion of
`,
`
`
`aay fe
`
`— answer to reset {ATR} and possible protoco! type
`rorreneO
`selection (PTS) and/or
`Proprietary information
`—a single command or a sequence of commands,
`possibly performing authentication procedures.
`Security attributes |
`
`
`(coding outside the scope
`of this pan of tSOAEC 7816)
`loentiber Gf an EF containing
`ar exie7sion.of the FC!
`
`
`
`
`
`Anyfile
`
`Any file
`
`|
`
`peopeee#a
`
`File accessibility
`— Not shareable file
`~— Shareable file
`
`File type
`— Working EF .
`
`proprieary
`types
`of EFs
`— DF
`
`EF structure
`-— No informauon given
`— Transparent
`— Linear fixed, no further info
`= Linear fixed, SIMPLE-TLY
`— Linear variable. no further info
`-— Linear variable, SIMPLE -TLV
`— Cyclic. no further info
`— Cyciic. SIMPLE-TLV
`
`~~OO--a0x
`
`“OOO
`
`wtet
`
`taeuenee
`
`Cree|
`
`The security status may also resu': from the completion
`of a security procedure related to the ident:‘:cation of the
`Involved entities if any, e.g...
`.
`
`— by proving the knowledge of a pessword te.g.,
`using @ VERIFY Command).
`— by proving the knowledge c‘ a key €.g.,
`GET CHALLENGE
`commanc
`follov.ed
`EXTERNAL AUTHENTICATE Command).
`—by secure messaging (e.g.. message authenti-
`cation).
`
`using a
`by
`an
`
`Three security statuses are considered.
`
`~~ Globa! security status -— it may be modified by the
`completion of an MF-retated authenticaton procedure
`{e.g., entity authentication by 6 password or by a key
`attached to the MF).
`
`— File-specific security status — H may be modified
`by the cormoletion of a DF-retaced authenticatic: pro-
`cedure {e.g., entity authentication by @ password or
`by 8 key attached to the specific DF) ; it may be main-
`tained, recovered or fost by file selection (see 6.10.2):
`this modification may be relevant only for the applica-
`tion to which the authentication procedure belongs.
`
`~~ Command-specific security status — It only exists
`during the execution of a command involving authen-
`tication using secure messaging (see 5.6}; such a
`command may leave the other security status
`unchanged.
`
`{f the concept of logical channels is applied, the file specific
`security status may depend on the logical channel {see
`5.5.1).
`
`Apple Ex. 1029, p. 12
`Apple Ex. 1029, p. 12
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`
`
`‘© ISOAEC
`
`ISO/IEC 7816-4: 1995 (E)
`
`6.2.2
`
`Security attributes
`
`8.3 APDU messagestructure
`
`The security attributes, when they exist, define the
`allowed actions and the procedures to be performed to
`complete such actions.
`
`Security attributes may be associated with each file and
`for the security conditions that shall be satisfied to allow
`operations on the file. The security attributes of a file
`dapend on
`
`— its category (DF or EF),
`
`-~ optional parameters in its file control information
`and/or in that of its parent filets).
`
`A step in an application protocol consists of sending a -
`command, processing it
`in the receiving entity and
`sending back the response. Therefore 6 specific response
`corresponds to eB specific command, referred to as a
`command-tresponse pair.
`
`An application protocol data unit (APDY) contains either a
`command message or a fesponse message, sent from
`the interface device to the card or conversely.
`:
`
`In a command-responsepair, the command message and
`the response message may contain data, thus inducing
`four cases which are summiarizec by table 4.
`
`NOTE — Security attributes may aiso be associated to other
`Table 4 — Data within a command-teszponse palr
`objects ie.g.. keysi.
`
`[Gene|Commanddata|Expectedreeponvegate]
`No data
`No data
`Data
`
`5.2.3 Security mechanisms
`
`Trs pet of ISCIEC 7816 defines the following security
`mechernsms.
`
`Data
`
`— Entity authentication with password — The card
`cimsa°es deta received from the outside world with
`seér7et interne: data. This mechanism may be used for
`porecting 1-2 nghts of the user.
`
`— Entity authentication with key — The entity to be
`accrenticated has to prove the knowledge of
`the
`reevant key in an authentication procedure (e.g.,
`uSs:ng & GET CHALLENGE command followed by an
`E)"ERNAL AUTHENTICATE Command).
`
`— Data authentication — Using internal data. either
`secret or public,
`the card checks redundant data
`r