`
`'
`
`I;
`
`In re Application of
`
`Romain PALMADE
`Serial No. 10/471,883
`
`4‘
`
`A
`
`4
`
`/
`
`.
`I
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`I
`
`Dim/(o
`PATENT
`
`5
`
`.
`
`: Atty. Docket: OO-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
`Commissioner for Patents
`
`PO. Box 1450
`
`Alexandria, VA 22313—1450
`
`SIR:
`
`COURTESY COPY of ms with 4 non-US references i
`previously sent along with Petition to Withdraw from‘I
`Issue and RCE faxed to MS 313(c) on May 3, 20
`
`
`M
`
`
`
`Mariah Moorhead
`
`The attached Form PTO-1449 provides a listing of information which may be relevant to the subject
`
`application. This IDS is not intended as a representation that better art is not available, nor that other art than
`
`that identified exists; nor that the information provided is prior art; nor that a search has been made.
`
`This IDS is submitted under:
`
`__)_(_X__ 37 CFR1.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:
`
`I ; Xéjflé
`
`FLEIT, KAIN, GIBBONS. GUTMAN, BONGINI & BIANCO P.L.
`551 NW 77th Street, Suite 111
`BocaRaton, Florida 33487
`Telephone: (561) 989-9811
`Facsimile : (561)989-9812
`
`
`
`Apple Ex. 1029, p. 1
`Apple Ex. 1029, p. 1
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`
`
`US. Dept. of Commerce
`Patent & Trademark Office
`
`Atty. Docket: 00420-379
`Serial No. 10/471383
`
`.
`Applicant: Romain PALMADE
`Group: 2876
`Filing Date: September 12, 2003
`
`
`' f Documents
`
`
`
`'
`
`Sub-
`class
`
`Transl'n Yes/No
`
`
`
`
`
`
`
`
`
`
`
`
`OTHER DOCUMENTS (Including Author, Title. Date, Pertinent Pages. Etc.)
`
`‘
`
`Rankl, W., et aI., "Handbuch der Chipkarten," 3, vollig tiberarb. und erw. Aufl., Mtinchen. Wien, Hanser. 1999,
`httQ://www.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 199502), pp. 1-46
`
`“information 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
`
`Include copy of this form with next communication to applicant.
`
`“Identification cards ~ Contactless integrated circuitis) cards — Proximity cards. Part 4: Transmission protocol,” Draft
`ISO/IEC FCD 14443-4, 2000-03-10, pp 1-33
`
`
`Examiner:
`
`Date Considered:
`
`Initial if reference considered, whether or not citation is in conformance with MPEP 609; Draw line through citation if not in
`EXAMINER:
`conformance and not considered.
`
`I
`
`I
`
`Apple Ex. 1029, p. 2
`Apple Ex. 1029, p. 2
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`}t
`
`BEST AVAILABLE COPY
`
`- @
`
`INTERNATIONAL
`STANDARD ,
`
`Iso/IEC
`7816-4
`
`.
`
`First cation
`199509-01
`
`m
`
`Information technology — Identification
`cards — Integrated circuifls) cards with
`contacts —
`
`Part 4:
`-
`Interindustry commands for interchange
`
`Technologies c‘e l'in/ormazion — Canes d'idenrificarion —— Carts: é
`circa-:13; ime'grea's; a :anrac:s —-
`
`Fame 4: Commandes inrersectorielles pour les e'changes
`
`
`
`
`
`.
`
`‘ -'.--~——.
`‘
`
`Reierence number
`_ ISOflEC 78164:199515)
`.'
`pl.
`('5
`.
`.
`.A.
`.
`-'~'«:.;C~\.'esrr::‘!z;;:mgung it. vorl. :SQ—wenmfi-tgung
`
`Apple Ex. 1029, p. 3
`Apple Ex. 1029, p. 3
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`ISO/IEC 7816-4: 1595 (E)
`
`Contents
`
`Foreword . .. .
`
`. ..
`
`Introduction
`
`1 Scope
`
`2 Normazwe references
`
`............................................................
`
`3 Definitzens
`
`
`
`4 Abbrevmions and notation ......................................................
`
`
`5 Basic organizations ....................................................................................
`5.1
`Data strhaures
`
`Securrty grchltecture ol the ca
`5.2
`
`5.3
`APDU message structure
`
`Coding :envennons for command headers.
`5.4
`care fiel:s ar-o response trailers
`.
`,
`Logical cnannels
`
`Secure messaging
`
`5.5
`5.6
`
`3
`3
`5
`7
`
`9
`12
`12
`
`
`
`
`6 Basic interindusrry commands .................................................................. 16
`
`6.1
`READ BlhARY command ................
`.
`.
`16
`Lynn's BlfiAR‘.’ command ..
`6.2
`17
`
`UPDATE EINARY command
`6.3
`17
`ERA-SE 8:'-'ARY command .....
`6.4
`18
`
`
`HEAD REIDRmSl command .
`6.5
`19
`
`WRITE R=ZOHD command .
`6.6
`20
`APFEND scoao command .
`6.7
`21
`
`
`:Poars "CCRD command .
`6.8
`22
`
`EET DA.- command .....
`6.9
`23
`
`PUT DAT: :ommand ..
`6.10
`24
`
`command .
`6.11
`SELECT =".
`25
`..........
`6.12
`.EmFY ::mI-.and
`26
`6.13
`‘NTERNL- AUTHENTICATE command ..
`27
`6.1"
`EXTERM. AUTHENTICATE command
`27
`GET CHAcLENGE command ..........
`6.15
`23
`
`6.16
`MANAGE CHANNEL command ..
`29
`'1 Tl’ansf'flISSth-Oflenled interindustry commands
`
`7.1
`GET RESPONSE command .....
`
`7.2
`ENVELOPE commend
`
`
`
`
`8 Historical bytes .............
` 9 Aoplicatiomindependen‘l card services
`
`Annexes
`
`Transportation of APDU messages by T20
`Transportation of APDU messages by T=1
`fiecoro pointer management
`Use at the basic encoding rules of ASN.1
`Examples of card profiles
`.
`Use of secure messaging
`
`mmonu>
`
`
`
`
`. .
`
`.
`
`
`
`
`
`O lSO/lEC 1395
`
`All rights reserved. Unless otherwise specified. no Pl“ 0? INS Publication may be
`reproduced or utilized in any lorm or by any means. electronic or mechanical, lndudino
`photocopying and microfilm, without permission in writing lrorn the publisher.
`ISO/IEC Copyright Office 0 Case Post-Io 56 0 04-12! l Geneva 20 0 Switzerland
`Printed in Switzerland
`
`Apple Ex. 1029, p. 4
`Apple Ex. 1029, p. 4
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`
`
`O ISO/IEC
`
`ISO/IEO 7816-4: 1995 (E)
`
`Foreword
`
`ISO (the International Organization Ior Standardization) and IEC (the
`International Electrotechnical Commission) form the specialized system Ior
`worldwide standardization. National bodies that we members of ISO or IEC
`participate in the development or‘ International Starcards tnrough technical
`committees established by the respective organizatio- to Goa; with particular
`fields oI technical activity. ISO and IEC technical committees collaborate in
`Iields of mutual interest. Other international organizatons. governmental and
`non-governmental, in liaison with ISO and lEC. also tare part in the work.
`
`ISO and IEC have established a joint
`In the field of information technology.
`technieal committee. ISOIIEC 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 96 of
`the national bodies casting a vote.
`
`International Standard ISO/IEC 7816-4 was prepared by Joint Technical
`Committee ISO/IEC JTC 1. Information technology.
`
`ISO/lEC 7816 consists of the lollowing. parts. under the general title Informa-
`tion technology — Identification cards —- Integrated circuirlsl cards with
`contacts.
`
`—Pan 1: Physical characteristics.
`-- Part 2: Dimensions and location of the contacts.
`—- Part 3: Electronic Signals and transmission protocols.
`-— Pan 4 .'
`lnterindustry commands for interchange,
`— Part 5 .' Numbering system and registration procedure for application
`identifiers.
`-
`'
`‘-
`— Part 5:
`
`lnterindustry data elements.
`
`Annexes A and 8 form an integral part of this pait oi ISO/IEC 7816. Annexes C,
`D. E and F are for information only.
`
`Apple Ex. 1029, p. 5
`Apple Ex. 1029, p. 5
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`ISO/IE6 7816-4: 1995 (E)
`
`O [SO/IEC
`
`‘
`
`.
`
`
`
`Introduction
`
`,
`
`This pa't of ISO/IEC 7816 is one of a series 01 standards describing the
`pa'ameters for integrated circuitlsl cards with contacts and the use of such
`ca'ds 1:" international intetchange.
`'
`
`These cards are identification cards intended for iniormation exchange nego-
`tiated between the outside and the integrated circuit in the card. As a result of
`an information exchange. the card delivers information (computation results.
`st: :ed zeta). aha/or modifies its content (data storage. event memorization).
`
`
`
`Apple Ex. 1029, p. 6
`Apple Ex. 1029, p. 6
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`
`
`use/rec 7818-4: 1995 (El
`‘ulrr'enmnomtt STANDARD 0 Isonsc
`
`
`identification cards
`Information technology —
`._ Integrated circuitis) cards with contacts —-
`
`Part 4:
`lnterindustry commands for interchange
`
`
`
`1 Scope
`
`_ > This part of ISO/IEC 7816 specifies
`--the content at the messages. commands and res-
`ponses, transmitted by the interface devrce to the
`card and conversely.
`—the structure and content of the historical bytes
`sent by the card during the answer to reset.
`—the structure of files and data. as seen at the
`intertace when processing interindustry commands
`for interchange,
`-- access methods to files and data in the card.
`
`--—a security architecture defining access rights to
`tiles and data in the card.
`—methods for secure messaging.
`—acoess 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.
`
`It allows further standardization of Idd'ttionai interindustry
`commands and security architectures.
`
`2 Normative references
`
`The fol10wing standards contain provisions which,
`through reierehce in this text. constitute provisions of this
`part of lSO/lEC 7816. At the time of publication.
`the
`editions indicated were valid, All standards are subject to
`revision. and parties to agreements based on this part ct
`lSOIlEc 7815 are encouraged to investigate the possibility
`of applying the most recent editions of the standards
`indicated below. Members of
`IEC and lSO maintain
`registers of currently valid lntemational Standards.
`
`lSD 3166:1993. Codes for the representation of names
`of countries.
`
`rsonec 7512.1 : 1993. identification cards — Identification
`of issuers — Part 1 : Numbering system.
`
`ISO/IEC 7816-3: 1989. Identification cords —- Integrated
`cr'rcur‘rls) cards with contacts — Pan 3‘: Electronic signals
`and transmission protocols.
`
`Amendment 1: 1992 to ISO/IEC 7816—3: 1989 Protocol
`type Tel, asynchronous half duplex block transmission
`protocol
`
`Apple Ex. 1029, p. 7
`Apple Ex. 1029, p. 7
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`
`
`. lSOIlEC 7816-4: 1995 (El
`
`to lSOIlEC
`
`-
`
`
`
`Amendment 2 : 1994 to ISOIIEC 7816-3 : 1989. Revision
`of protocol typo selection.
`.
`
`lSO/IEC 7816-5: 1994. Identification cards -— Integrated
`circuit(sl cards with contacts — Part5 : Numbering sys-
`tem and registration procedure for application identrfiers.
`
`lSOfIEC 7816-6:-—~1). Identification cards — Integrated
`circuitlsl cards with contacts -—— Part 6: lnterindustry data
`elements.
`‘
`
`In this part of ISO/IEC 7816. data objects are
`element).
`referred to as BER-11v, COMPACT-TLV and SIMPLEJLV data
`objects.
`
`infor—
`dedicated filo: File containing file control
`3.6
`motion and. optionally. memory available for allocation. It
`may be the parent of EFs and/or DFs.
`
`DF nor-no: String of bytes which uniquely identifies
`3.7
`a dedimted file in the card.
`
`lSO/IEC 8825: 1990 2), Information technology — Open
`Systems Interconnection —- Specification of Basic Encod-
`ing Rules for Abstract Syntax Notation One (ASN.1).
`ISOIIEC 9796: 1991. Information technology -- Security
`techniques —- Digital signature scheme giving message
`recovery.
`
`lSO/IEC 9797: 1994. Information technology —- Seourity
`techniques — Data integrity mechanism using a crypto-
`graphic checlr
`function employing a block cipher
`algorithm.
`
`lSO/lEC 9979:1991. Data cryptographic techniques —
`Procedures for the registration of cryptographic algo-
`rithms.
`
`Information technology - Modes of
`!SO."EC 101161991.
`opera tron lor'an n~'oi.' DIOCk cipher algorithm.
`technology —-
`lSOIlEC 10118-1: 1994,
`Information
`7; General.
`Security techniques —— Hash'functions —— Parr
`
`-
`
`Information technology .—
`lSO/IEC 10118-2: 1994,
`Securiry techniques —— Hash-functions —.— Pan 2: Hash-
`lunctions using an n-oit block cipher algorithm.
`
`3 Definitions
`
`For the purposes of this pan of ISOIIEC 7816, 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 command followed by a response.
`
`data unit: The smallest set of bits which can be
`3.3
`unambiguously referenced.
`
`directory filo: Elementary file defined in part 5 of
`3.8
`lSO/lEC 7816.
`
`elementary filo: Set of data units or records
`3.9
`which share the same file identifier.
`ll cannot be the
`parent of another file.
`
`3.10 lil- control paramotors: Logical. structural and
`security attributes of a tile.
`
`3.11 filo identifier: A 2-bytes binary value used to
`address a file.
`
`3.12 file management date: 'Any information about a
`file except the file control parameters (6 5.. expiration
`date. application labell.
`
`3.13 internal elementary file: Elem‘s'tary file for
`storing data interpreted by the care
`
`3.14 master file: The mandator. unioue dedicated file
`representing the root of the file stru:ture.
`
`3.15 mossonoztString of bytes transmitted by the
`interface device to the card or vice-verse. excluding
`transmission-oriented characters as defined in part 3 of
`ISO/IEC 7815.
`
`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 to be presented to the card by its user.
`
`tie identifiers without
`3.18 oath: Concatenation of
`delimitation.
`ll the path starts With the identifier of the
`master tile_ it is an absolute path.
`
`3.19 provider: Authority who has or who obtained the
`right to create a dedicated file 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 a record identifier.
`
`‘“
`
`dot- clement: Item of information seen at the
`3.4
`interface for which are defined a name. a description of
`logical content. a format and a coding.
`
`3.21 record Identifier: Value associated with a record
`that can be used to referencethat record. Several records
`may have the same identifier within an elementary file.
`
`information seen at the Interface
`dot- obioct:
`3.5
`which consists 0! a tag, a length and a value (i.e.. a data
`
`
`3.22 record number: Sequential number assigned to
`each record which uniquely identities the record within its
`elementary file.
`
`1’ To be published.
`2’ Currently under rewsion.
`
`3.23 working elementary filo : Elementary file for
`storing data not interpreted by the card.
`
`Apple Ex. 1029, p. 8
`Apple Ex. 1029, p. 8
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

` .
`
`‘o’rs‘onsc
`
`ISOIlEC 7816-4: 1995 IE)
`
`
`
`4 warts and notation
`
`pay the purposes of this part of lSO/lEC 7816. the follow-
`ing abbreviations applv.
`APDU
`Application protocol data unit
`ATR
`Answer to reset
`
`.
`
`~ BER
`CLA
`DIR
`DF
`EF-
`FCt
`PCP
`FMD
`INS
`MF
`P1-P2
`PTS
`RFU
`SM
`SWt-SNZ
`TLV
`TFDU
`
`Basic encoding rules of ASN.1 (see annex D]
`Class byte
`Directory
`Dedicated file
`Elementary file
`Fiie control information
`File control parameter
`File management data
`Instruction byte
`Master file
`Parameter bytes
`Protocol type selection
`Reserved (or future use
`Secure messaging
`Status bytes
`Tag, length, value
`Transmission protocol data unit
`
`'
`
`For the purposes of this part of ISO/15C 7816, the follow-
`ing notation applies._
`'0' to '5‘ and 'A' to ‘F' The sixteen hexadecimal digits
`(81,
`Value 07 byte 3]
`8-, ll 8;
`Concatenation of bytes 81 (the most significant
`byte) and 82 (the least significant byte)
`(8, ll 5;) Value of the concatenation of bytes B1 and 82
`fr
`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 lSO/IEC 7816.
`
`. 5.1.1
`
`Filo organization
`
`""13 Dir! of ISO/16C 7816 supports the following two cute-
`gories of files.
`'
`— Dedicated file (DP).
`
`5— Elementary file (EFL
`
`The logical organization of data in a card consists of the
`following structural hierarchy of dedicated files.
`
`-The OP at the root is called the master file (MP).
`The MF is mandatory.
`'
`— The otherDFs are optional.
`
`The following two types of EFs are defined.
`-- Internal EF-Those EFs are intended for storing
`data interpreted by the card. i.e.. data analyzed and
`used by the card for management and control
`purposes.
`.
`»
`
`'— Working EF —Those EFs are intended for storing
`data not interpreted by the mrd. i.e., data to be used
`by the outside world exclusively.
`
`Figure 1 illustrates an example of the logical file organiza-
`tion in a card.
`
`
`
`Figure 'l — Loglcal filo organization (example)
`
`5.1.2
`
`File rotor-racing methods
`
`When a file cannot be implicitly selected, it shall be possi-
`ble to select it by at least one of the following methods.
`
`~Referencing by file identifier— Any file may be ref-
`erenced by a tile identifier coded on 2 bytes. If the MP 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. all EFs and DFs immediately under a given DF—
`shall have different file identifiers.
`
`—- Referencing by path — Any file may be referenced by
`a path (concatenation of file identifiers). The path begins
`with the identifier of the MF or of the current DF and ends
`with the identifier of the tile itsell. Between those two
`identifiers.
`the path consists of the identifiers of the,_
`successive parent DFs if any. The order of the file
`identifiers is always in the direction parent to child. If the
`identifier of the current CF 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.
`
`—- Referencing, by short EF identifiar— Any EF may be
`referenced by a short EF identifier coded on 5 bits valued
`in the range from 1 to 30. The value 0 used as a short EF
`identifier references the Currently selected EF. Short EF
`identifiers cannot be used in a path or as a file identifier
`(e.9., in a SELECT FILE command).
`
`Apple Ex. 1029, p. 9
`Apple Ex. 1029, p. 9
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`
`
`ISO/IEC 78164: 1995 (E)
`
`O iSO/IEC
`
`__ Referencing by DF name — Any DF may be refer-
`enced by a DP name coded on t
`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 filo structures
`
`The following structures of EFs are defined.
`
`— Transparent structure -— The _EF is seen at the
`inte'face as a sequence of data units.
`-- Facord structure—The EF is seen at the interface
`as a secuence of individually identifiable records.
`
`The following attributes are defined for EFs structured in
`records
`- Eze of the records : either fixed or variable.
`
`— Crganization of the records: either as a sequence
`. (linear structure) or as a ring lcvclrc structural.
`'
`
`The car: shall support at least one of the following four
`mathocs for structuring EFs.
`- ‘ransoarent EF.
`- _ near EF with records of fixed size.
`-- - wear file‘with records of variable size.
`— :lCiiC EF with records of fixed size.
`
`Figure 2 shows those four EF structures.
`Transarent
`Linear fixed
`Linear variable
`
`
`
`
`
`Cyclic fixed
`
`
`DE§©
`
`
`Figure 2 ~- EF structures
`NOTE —The arrow on the figure references the most recently
`written 'ecord.
`
`5.11 Data referencing methods
`
`Data r'av be referenced as records. as data units or as
`data ocects. Data is considered to be stored in a single
`continuous sequence of records (within an EF of record
`structu'el or of data units (within an SF of transparent
`structure). Reference to a record or to a data unit outside
`an EF is an error.
`
`Data referencing method. record numbering method and
`data unit size are EF—dependent features. The card can
`provide indications in the ATE. in the ATE 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 dosest one to that EF within the path from-the MP
`to that EF.
`-
`v
`
`
`
`5.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-bit integers with values in the range from 'O‘l'
`to 'FE'. The value '00‘ is reserved for 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 FlLE and any command carrying a valid short EF
`identifier can affect the record pointer. Referencing by
`record number shall not affect the record pointer.
`‘
`
`-Referencing by record identifier— Each record iden-
`tifier is provided by an application. If a record is a SIMPLE-
`TLV 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 record identifier. an
`indication shall soecrfy the logica aosrtior of the target
`record. the “'5'. or last occur'e'ics the her: or previous
`occmrence relative to the record pointer.
`
`~Vlrithin each EF of linear stru:ture, the logical posi-
`tions shall be sequentially ass gned V"'-‘_’f\ writing or
`appending. i.e.. in the order of creation. Therefore the
`first created record is in the firs: logical position.
`
`——\Mthin 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.
`
`—The first occurrence shall be the record with the
`specified identifier and in the first logical position; the
`last occurrence shall be the re:ord W": the specified
`identifier and in the last logical position.
`
`—When there is no current record, the next occur-
`rence shall be equivalent to the first occurrence: the
`prevrous occurrence shat: be equivalent to the last
`occurrence.
`
`-—When there is a current record. the next occur-
`rence shall 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 logical 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
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`' 0 ISO/IEC
`
`ISO/IEC 7816-4: 1995 (El
`
`-- Referencing by record number— Within each SF of
`record structure, the record numbers are uniQue and
`sequential.
`
`— tMlhin each SF 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. i 1)
`is the first
`created record.
`
`—thin each SF of cyclic structure. the record num»
`bers shall be sequentially assigned in the opposite
`order, i.e.. the first record (record number one, e t) is
`the most recently created record.
`
`Thefollowing 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.
`
`S.‘l.l.2 Date unit referencing
`
`Vlfithin east. EF of transparent structure, each data unit
`can be 're-‘erence: by an olfsez leg. in READ BINAET
`command. see 6.1!.
`It
`is an unsigned integer, limited to
`either 8 or 15 bits according to an option in the respective
`command. Valued to O for the first data unit of the EF, the
`offset is in:remented by 1 lat every subsectuen: data unit,
`
`if the card gives no indication. the size of
`By default. i.e..
`the‘datarunrt is one byte.
`
`mores
`
`An EF of record structure may supportdata unit referencing
`1
`and. in case It does. data units may contain structural informa-
`tion along w-tn data. e.g.. record numbers in a linear structure.
`
`2 Within an SF of record structure. data unit referencing may
`not provide the intended result because the storage order of
`the records ._-. the EF 15 not known, cg. storage order in a cyclic
`structure.
`
`5.1.‘3' Date object referencing
`
`Each data object (as defined in 5.4 4) is headed by a tag
`Which references it. Tags are specified in this part and
`other parts of lSO/lEC 7816.
`
`6.1.5
`
`File control Information
`
`The file control information (FCll is the string of data bytes
`available in response to a sneer ms command. The file
`control Information may be present for any file.
`
`Table 1 introduces 3 templates intended for conveying file
`control information when coded as BER-TLV data objects.
`—The FCP template is intended for conveying file -
`control parameters (FCP),
`i.e.. any BER-TLV data;
`objects defined in table 2.
`
`—~The FMD template is intended for conveying file
`management data (FMDl.
`i.e.. sen-1w data objects
`specified in other clauses of this part or in other parts
`of lSO/lEC 7816 «2.9.. application label as defined in
`can: and application expiration date as defined in
`Daft
`).
`
`-—The F0 template is intended for conveying file
`control parameters and file management data.
`
`Table 1 — Templates relevant to PC!
`
`9 control Informat-c" “73' mm: 229'
`
`"E
`'P temperel
`e ~a<egement oat: -‘- CD ternsstel
`
`The 3 temp-ates may be retrieveslaccordmg to seiectron
`options of the SELECT m5 comma-Id (see table 591.
`If the
`PC? or FMD option is set.
`then the use of the corre.
`sponding template is mandatory. if the FCl option is set.
`then the use of the FCI template is optional.
`
`Part of the file control information may additionally be
`present in a working EF under control of an application
`and referenced under tag '87'. The use of the PC? or FCl
`template is mandatory for the coding of
`file control
`information in such an EF.
`
`File control information not coded according to this part
`of ISO/IEC 7816 may be introouced as follows.
`
`— ‘00‘ or any value higher than '9F' —-The coding of
`the subsequent string of bytes is proprietary.
`— Tag = '53' —The value field of
`the data obiect
`consist: of discretionary data not coded in TLV.
`—Tag = '73'—The value field of
`the data object
`1..
`consists ol discretionary EEfi-YLV data objects.
`
`
`
`Apple Ex. 1029, p. 11
`Apple Ex. 1029, p. 11
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`ISO/[EC 7816-}: 1995 (E)
`
`c Ispnec
`
`Transpaten
`t EFs
`
`Table 2 -- Filo control parameters
`
`
`Number of data bytes
`in the file. excluding
`
`
`
`strucnnl inlormation
`
`
`Number oi data bytes
`
`
`in the file, induding'
`
`structural information if any
`
`
`
`
`File descriptor byte
`Any file
`
`lsee table 3|
`
`
`Any file
`File descriptor byte tollowcd
`
`
`
`
`by data coding byte
`lsec table 86l
`
`
`
`
`File descriptor byte followed
`EFs with
`
`
`
`
`by data coding byte and
`record
`
`
`maximum record length
`structure
`Any r...
`
`_m
`Proprietary inlormation
`Security attributes 4
`(coding outside the scope
`of this part of ISO/15C 7816)
`loentiiue' (:5 an EF containing
`an evens-on-ol the ‘Cl
`
`Any file
`
`Any file
`
`.
`
`RFU
`
`
`
`Table 3 -— Filo descriptor byte
`
`
`
`
`
`W\I
`
`to nx(
`
`8
`
`mwwmm
`File accessibility
`— Not shareable file
`—- Shareable file
`
`‘-l“EM-IE!
`
`0000000"!0OO’HJODUI‘IOOOO
`
`
`
`File type
`
`
`— Working EF .
`— internal EF
`
`— Fieserved
`
`
`lor
`proprietary
`types
`
`
`01 EFs
`.o.
`u-I
`—- DF
`
`I
`I
`I
`o
`EF structure
`
`
`— No information given
`
`
`—- Transparent
`— Linear fixed. no further into
`-— Linear fixed, SlMPLE-TLV
`
`
`— Linear variable. no further inlo
`
`
`- Linear variable, SIMPLE -TLv
`
`
`~ Cyclic. no further info
`— Cyclic. SIMPLE ~TLV
`
`
`
`
`
`‘-‘(30011X
`
`IlIlorIl
`
`4‘004-‘00K
`
`IirIiIcl
`
`liIIIIII
`
`d-O—I-IOOOOX
`
`—‘-'OO-‘-‘OOX
`
`'Snaroable' means that the tile supports at least concurrent
`access on diflerent logical channels.
`
`’
`
`
`
`5.2 Security ardtitocture of the card‘
`
`This clause describes the following features:
`-— security status.
`
`— security attributes.
`— security mechanisms.
`
`Security attributes are compared with the security statu
`to execute commands and/or to access files.
`*
`
`5.2.1
`
`Security stltus
`
`Security status represents the current state possibly
`achieved alter completion of
`‘
`—answer to reset lATRl and possible protocol type
`selection (PTS) and/or
`
`-—a single command or a sequence of commands,
`possibly performing authentication procedures.
`
`The scourity status may also result from the completion
`of a security procedure related to the identification of the
`involved entities ii any, 2.9.,
`,
`
`——by provmg the knowledge of a password le.g..
`using a VEREFY command),
`--by provmg the knowledge 5: a key 5.9., using a
`GET CHALL ENGE
`commanc
`followed
`by
`an
`EXTERNAL A'JTHENTICATE command).
`
`—~by secure messaging (e.g., message authenti-
`cation).
`
`Three security statuses are considered.
`
`—-— Global security status —— It may be modified by the
`completion ol an MF—related authenticat-on procedure
`le.g.. entity authentication by a password or by a key
`attached to the MF).
`
`— Filespecific security status — it may be modified
`by the completion of a DF-relazed authenticaticr. pro-
`cedure le.g., entity authenticauon by a password or
`by a key attached to the specific DF) ; it may be main-
`tained, recovered or lost by file selection (see 6.10.2):
`this modification may be relevant only for the applica-
`tion to which the authentication procedum belongs.
`
`w Command-specific security status —- It only exists
`during the execution ol 8 command involving authen~
`ticatlon using secure messaging (see 5.6): such a
`command may leave the other security status
`unchanged.
`
`\.
`
`It the concept oi 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
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`
`
`'0 ISO/IEC
`
`ISOIIEC 7815-4: 1995 (El
`
`5.2.!
`
`Security attributes
`
`5.3 APDU message structure
`
`A step in an application protocol consists of sending a .
`command. processing it
`in the receiving entity and
`sending back the response. Therefore a specific response
`corresponds to a specific command. relerred to as a
`command-response pair.
`
`An application protocol data unit (APDU) contains either a
`command message or a response message. sent trom
`the rnteriace device to the card or converse .
`-
`
`in e command-response pair. the command message and
`the response message may contain data. thus inducing
`four cases which are summarized by table 4.
`
`Table 4 — Date within a commend-response pair
`
`-—-m
`
`5.3.1 Command APDU
`
`the command
`Illustrated b. figure 2 (see as: table 6
`APDU defined In this part of ESO’ EC 7816 :onsists of
`-— a mandatory header at 4 bytes lCLI- INS P1 P2).
`
`—- a concztional body 01 varraae length
`' gi—z‘;¢.
`I .
`v.4.
`.’é:1,,‘n(;‘\-7ridl’.44 1;'rt_-
`<1 I
`.1 _
`1‘
`Jr l4),
`. t .3.
`Header
`,
`Bod
`lL.lieldi
`CLA INs Pl P2
`ILe field]
`[Data field]
`Figure 3 — Commend APDU structure
`
`.
`
`The number of bytes present in the data field of the
`command APDU is denoted by LC.
`
`The maximum number oi bytes expected in the data field
`of the response APDU is denoted by L. (length 01 ex-
`pected data). When the Le field contains only zeroes. the
`maximum number of available data bytes is requested.
`
`Figure 4 shows the 4 structures of command APDUs
`. according tothe 4 cases defined in table 6.
`
`Case 1
`
`
`
`The security attributes, when they exist, define the
`allowed actions and the procedures to be parlormad to
`complete such actions.
`
`Security attributes may be associated with each tile and
`for the security conditions that shall be satisfied to allow
`operations on the tile. The security attributes of a tile
`depend on
`
`—- its category (DF or EFl.
`
`-- optiona