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