Slides from Ben Whitaker's talk about new mobile ticketing approaches for public transport including mobile payments via credit card this month at the UK's ITS Passenger Information Interest Group's seminar on Options for Ticketing and Standards in Ticketing on the 27th May 2009 in London. Highlights of new features in the UK's Rail Barcode Ticket standard, and a brief summary of the lower capital expenditure soft-rollout of visual barcode ticketing on paper and mobile versus the large up-front costs of smartcard. Finally a summary of selling tickets from the mobile phone, and the benefits it brings to the operator.

2.  Masabi build mobile applications
 Award winning and certified security
 Ticket sales and delivery from mobile
 Projects:
Consultancy supporting the standards
Rail Settlement Plan work on self-print and mobile barcodes
mobile tickets for
Business Rail ticket sales
ticket sales from
mobile (’07 – ‘08)

3.  Contactless RF
 Smart-Card
ITSO, Oyster, Mi-Fare
 NFC Phones
Dependant on scanning hardware
 Barcodes
 Self-print
 Mobile
Soft rollout option with visual inspection

4.  Avoid up-front cap-ex on
full barcode scanner rollout
 Visually inspect at launch
 Staff report barcode ticket
usage levels each week
 Occasional SMS or scan checks
(Can add
 Staged scanner rollout for an animated
watermark to aid
routes with significant adoption visual inspection)

5.  Oyster for London
 Price incentives drive public uptake
Single Fare: Paper £4; Oyster £1.60
 Massive capital expenditure before launch
Resistance from overland rail to accept same fees
 National Smartcard Questions:
▪ Will tickets be as heavily discounted?
▪ Will it be as widely adopted by public?
▪ How long will it take to recoup Cap-Ex?

6. RSPS3001 Approved in December 2008 as the UK standard
for self print and mobile barcode rail ticketing

7.  Share self-print and mobile barcodes
between TOCs, TIS and 3rd party retailers
 Public and open security
 Based on PKI, standard SSL certificates
 Optional ITSO seal, but not required
 Decentralised system - robust
 Cheap to implement and use

8. ITSO and Oyster PKI is Asymmetric
are Symmetric =Different Keys
=Same Keys
Private key to create
ticket
Private key
to create (safe on TIS server)
ticket
Private key to Public Key to
check ticket check ticket
(some risk from
key theft) (no risk from
key theft)

9.  Traceability, and no security risk from
theft of scanning devices
 If private keys are leaked, only the
vendor that loses the keys is affected
 3rd parties and other EPOS vendors
can take part, even taxis and coffee
shops can scan and validate
cross-sale tickets or entitlements

10.  More free space for single TOC
products and extra entitlements
“Includes free cup of Costa Coffee
and 2 Adults entry to Alton Towers”
 ITSO Seals included, but optional
 Allows non-ITSO and ITSO enabled
TOC’s to inter-operate

11.  Any barcode scanner, online or off-line,
must support: 2D Aztec with CCD imager
Basic Advanced
 Handheld
 Small basic scanners for door staff
Bluetooth
 Advanced PDA based scanners for service staff
 Bluetooth scanner upgrade for Avantix Mobile 2
 Cash Register/EPOS Scanners EPOS Scanner
 Connect via USB or as “keyboard wedge” in
between keyboard and EPOS like a normal scanner
Retro-fit
 Fixed Scanners for gates or check-outs Fixed / gate
scanner
 Retro-fit to existing gates, user places phone on
rubber face to scan
 Or built in at manufacture by gate supplier

12.  Offline validation from software
 Add to existing EPOS or gate systems
 No mobile databases required
 No synchronisation of valid tickets
from one TOC to another
(too much data, too unreliable)
 Walk-up tickets

13.  Isn’t it easy to photocopy a self-print
paper ticket?
 What if a bunch of clever people
figure out how to copy mobile
tickets?
 What if one user copies a ticket, gets
onto an off-line train, and his friend
gets onto a second off-line train?

14.  Scanners only accept first seen barcode
 On-line scanners can check for previous
scans at other locations
 Off-line scanners submit scan records
back to ticket issuer for post-processing
 Post processing identifies dual use, and
blocks future purchases from the same
credit card until fine paid, limiting fraud

16.  Only 12% of rail tickets sold on the
internet – most bought at station
 Over 2/3 of mobile users never
complete their sign-up if it’s on the web
 So: Sign up the users when they need it
 in a queue
 in a hurry
 next to a broken ticket machine

19.  WAP / xHTML
 Browser based, like on
the web
 No javascript or Ajax
on ~90% of mobiles
 Application
 Installed on the phone
 Dedicated, customised

20.  Still useful without a continuous
data connection
 Optimised data entry
 Faster responses
 Catch mistakes quicker
 SMS failover from GPRS
 Avoid settings, reception &
roaming problems
 Cheaper + faster for the user
 Send only the data
 Flat rate data is still not common

21.  Early WAP:
 WTLS – not true security
 New WAP2
 Vodafone breaks HTTPS, breaks PCI
 Merchant’s policy decision on acceptable
level of security
 Most agree that credit card sign-up should not
happen over broken WTLS or HTTPS
 Results in sign-up on WEB only, like Trainline

22.  No sign-up process
 no usernames
 no passwords
 Mostly off-line interface, SMS backup
 Fast repeated regular purchases
 Auto-show tickets, full screen barcodes

23. 95% of trial users said:
“better than the IVR system we used until now”
 Payments straight from phone
 No need for explicit sign-up or passwords
 Just type CVV again for future purchases
 All user data entry and validation performed off-line
by application
 Secure SMS for users without data settings or with
poor reception
 New user can sign-up and pay in just one SMS

24. Chiltern Railways with YourRail
Trial user feedback: “Better than the web!”
 Buy anywhere
 No paper, no queues - barcode tickets
 Tunnels aren’t showstoppers!
 Auto-detects SMS or GPRS
 1-2 SMS per ticket
 Doubles the consumer uptake by removing Data issues
 Quick repeat tickets
 Customer loyalty and lock-in

25.  Two snags against mass-adoption of the
existing SMS/MMS tickets
1. User delay in finding ticket before gate
customers manually searching the phone’s lists of
messages/images to find today’s ticket
Answer: application auto-shows today’s ticket
2. Some phones don’t scan successfully
Guards simply don’t scan certain phones, and
customers know the gates won’t let them through
without manual intervention
Answer: application displays full-screen Aztec for scanner

26.  Instant sign-up from the queue
 Give everyone a personal ticket
machine
 Soft rollout to avoid cap-ex
 Customer behaviour tracking
and targeted SMS offers
 Cross-sales to raise margins

28. Masabi Proxy Retailer Web
(can be hosted by
retailer) Services
SMS “Tickets” to 89080
1
2
Auto-Install SMS
3
Purchase Request
and Payment Details 4
(sent by encrypted SMS or Data
from the mobile application) XML Web
Service Requests
5
Success message
with content, ticket or code

29.  Optimise for the regular use cases
 Make them fast and obvious
 Allow advanced search for users that
choose it
 Dynamic interface can expand options
 Enable goal seeking for
▪ Cheapest Advanced tickets, with maximum
date/time range
▪ Off-peak services
▪ Advanced/non advanced

30.  Full-Screen Barcode Display on Mobile
 Size = speed and reliability of scanning
 More reliable than SMS, MMS or WAP delivered
barcodes
 Off-line Scanning
 Allows for total loss of site WiFi / Internet
connectivity or loss of the central ticket server
 Secure Barcodes
 PKI barcode signatures prevent modification
of tickets by criminals
 Public Key Validation allows any 3rd party vendor
or EPOS till integrator to scan and check tickets