Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 57
Findings of Key Information to be Exchanged Between Agencies 57
· UPDATE RECORD--Modifies existing data within a record-based (non-transparent-based)
file on the smartcard.
· EXTERNAL AUTHENTICATE--Used with GET CHALLENGE to authenticate the terminal
to the smartcard.
· INTERNAL AUTHENTICATE --Used to authenticate the smartcard to the reader device.
· GET CHALLENGE--Used with the EXTERNAL AUTHENTICATE to authenticate the ter-
minal to the smartcard.
Despite the existence of the ISO 7816 standard, some suppliers have implemented smartcard
application commands that use the distinct advantages of their own specific platforms and thus
offer an advantage to their particular product lines and barriers to entry for other suppliers. This
defeats the purpose of interoperability between suppliers. Therefore, it is critical to require and
then examine the card application requirements that will lead to the definition of the application
commands in a manner that complies with the ISO standard.
4.2.2 Data Layer
The key essential data elements of a regionally interoperable system include information
for front-end components (e.g., the smartcard and the smartcard reader) as well as infor-
mation for back-office systems (e.g., the data collection equipment). Starting with a super-
set of all data from the four primary reference interoperability specifications (i.e., RIS, ITSO,
CEN, and RKF) a conceptual model was created. All data elements were tested against the
working definition of interoperability. This information is summarized in the following two
questions:
· Does this data element enable multiple transit agencies to offer a common smartcard appli-
cation for transit-fare payment?
· Would the lack of this data element prevent multiple transit agencies from offering a common
smartcard application for transit-fare payment?
If the answer to both of these questions was yes, the data element was considered essential.
This information is categorized as follows:
· Cardholder information (information unique to the card itself);
· Fare information (information regarding a particular fare product); and
· Transaction information (information about the particular trip).
During the development phase of this project, additional essential data elements may be iden-
tified. Such discoveries are expected in iterative prototype development, and we will update this
paper with these elements should it be necessary.
Table 13 depicts the data fields defined in the four primary standard specifications (RIS,
ITSO, CEN, and RKF) for each of the three categories (card/holder information, fare infor-
mation, and transaction information). Each of these standards has many other types of data
beyond these three categories; however, only the data for the three categories relevant to data
element interoperability have been included. Table 13 does not suggest that ALL of the
included data fields in each specification in the three categories are required. In fact, the oppo-
site is true, and the subset of fields that must be standardized for minimal interoperability are
identified following this table. Table 14 defines the data elements listed in Table 13 based on
the RIS.
Of the data elements listed, most are not required to be exchanged between agencies for
interoperability to work. Many elements are exchanged between the agencies for business
OCR for page 58
58 Smartcard Interoperability Issues for the Transit Industry
Table 13. All data fields available in selected categories.
CARD/HOLDER INFORMATION
RIS v. 1.0 ITSO v. 1.2 CEN v. 1.0 RKF v. 2.0
Card/Transit Information
PICCTestUse NA NA NA
OpsMaintenanceUse NA NA NA
CountryID NA Country ID NA
PICCValidityPeriod ValidUntil (VUT) NA CardValidityEndDate
RegionID NA NA NA
IssuerID ITSOOperatorsIDNumber ApplicationIssuerID CardProvider
TransitExpirationDate ITSOShellExpiryDate Base data type of NA
EndDate
KeySetIdentifier KeyVersionCode MACKeyID MACKeyIdentifier
ManufactureID MID or CSN NA ManufacturerData
TransitPICCID IssuerIdentificationNumber NA CardSerialNumber
IssuingDeviceID ISAMID Base data type of Base type of Device
DeviceID
Base data type of
SerialNumbers
Holder Information
ProfileBirthDate DateOfBirth BirthDate Base data type of
DateTime
ProfileStartDate NA StartDate Base data type of
DateTime
ProfileExpireDate ExpiryDate EndDate Base data type of
DateTime
ProfileLanguage Language LanguageID DialoguePreferences
Language
UserRegistered NA NA
ProfileCode CustomerProfile EntitlementType DiscountCounter
DiscountLevel DiscountLevel
PassengerClass DiscountType
PassengerType
DepositPaid ShellDeposit NA Deposit
PICCHolderGender IDFlags NA PassengerType
PICCHolderDescription NA NA NA
CardHolderDescription PersonID UserData NA
BirthName
Forename
Surname
HolderName
Employee
CompanyName
Birthplace
reasons or to accommodate policies such as allowing the agencies to gather information to bet-
ter run their businesses. The following are the essential elements that need to be exchanged for
interoperability:
· Card/Holder Information is primarily information associated with an individual card and
cardholder. This information is required in transaction data to allow the back-office systems
to validate, process, and deliver the necessary data for clearing and settlement between agen-
cies. It also allows the reader to validate the transaction and perform the service (allow
entrance or exit) to the patron. The essential card/holder data elements are
Card Identification Number--Uniquely identifies the card within the interoperable sys-
tem. One purpose of the card ID is to ensure the integrity of a card's total value in the
system.
Card Issuer Identification Number--Uniquely identifies the issuer of the card within the sys-
tem. The card issuer ID is required in order to perform inter-system funds settlement.
OCR for page 59
Findings of Key Information to be Exchanged Between Agencies 59
Table 13. (Continued).
FARE INFORMATION
RIS v. 1.0 ITSO v. 1.2 CEN v. 1.0 RKF v. 2.0
Stored Value Information
AutoSubscribe ValueATPAFlags NA AutoloadLoad
Status
ValueExpires EndDate NA EndDate
RemValueSign NA NA NA
RemValue Value Balance Value
ExpRecurDate NA Date NA
RecurringAutoloadType NA NA NA
AutoThreshold Threshold NA NA
SVThreshloadLoadAmount TopUpAmount NA AutoloadValue
SVRecurringLoadAmount NA NA AutoloadValue
CurrencyCode ValueCurrencyCode NA CurencyUnit
CIDTransactionNumber TransactionSequenceNumber NA Device Transaction
Number
CIDID SAMID Base data type of Device
DeviceID
Base data type of
SerialNumbers
Pass/Transfer Information
AutoloadSubscribed TYP9Flags NA NA
PaymentType AmountPaidMethodOfPayment NA NA
LocationEncodingType NA NA NA
RemTripRidesTransfers CountUsesAvailable NA NA
ExpDate ExpiryDate Base data type of Base data type of
EndDate DateTime
ExpTime NA EndTime Base data type of
DateTime
RenewedInAdvance NA NA NA
AutoThreshold NA ThresholdAmount NA
ProdID TransactionType AuthorizedProduct ContractSerial
Number
LocationEncoding ValidFrom / ValidTo NA Place
CIDTransactionNumber TransactionSequenceNumber NA DeviceTransaction
Number
CIDID SAMID Base data type of Device
DeviceID
Base data type of
SerialNumbers
(continued on next page)
Patron Profile Code--Represents the discount allowance, if any, for the individual bearing
the card. Without the patron profile code, discounts for special fares such as for those with
disabilities or for students could not be supported.
· Fare Information describes the fare product being used. It is required for the fare equipment
and the back-office systems to validate and process fare payment transactions. Fare informa-
tion, at a minimum, consists of the following:
Fare Product Identification Number--Uniquely identifies the logical fare product used in the
transaction to enable appropriate clearing and settlement. Even in a system where only the
e-purse is used as the form of payment, the e-purse must be uniquely identified.
Product Validity Period--Identifies the time and/or date period that the product is valid.
Transaction Value--Identifies the fare amount if a stored value e-purse is to be used.
· Transaction Information is a concatenation of card, fare, and specific transaction information.
It is normally referred to as the transaction data for a specific patron's journey. This is the pri-
mary information used by back-office systems to validate and process fare payment transac-
tions for establishing end-of-day net-settlement positions. When the day's transactions are
processed and net-settlement positions established, funds will either be sent to or received
