They swipe the card on a reader at the start and end of journeys to validate
their tickets or deduct credit. The Oyster saves time and money processing
ticket office transactions and reduces the number of paper tickets. To
encourage use, fares are substantially cheaper than paper tickets.
Figure 4.19: the London Oyster card
The Oyster card itself is not much of a smart object. It’s just a piece of plastic
containing an RFID chip and a small amount of memory. The RFID chip
passes a unique ID to a reader when a passenger swipes in. The memory holds
information about the tickets or money stored on it, so the reader does not
need to contact the back office service in real time every time the user swipes
the card. This speeds up the rate at which passengers can pass through ticket
barriers, which is vital during rush hour. Readers transmit transactions to the
back office in batches.
The Oyster card is an icon of London life, but it is really just an avatar for the
service. Without the card readers or the ability to top it up it wouldn’t be much
use to you. The Oyster service involves smooth coordination between many
different channels, such as the Transport for London website, the ticket
machines, ticket offices and shops that sell top ups, the readers themselves,
and the back office systems (see ‘Service ecosystems’, below).
Technically, the Oyster card itself is not even an essential part of the service:
Oyster can also be used via NFC enabled phones and bankcards. In future, the
dedicated Oyster card might even disappear, but the service will remain. But
services are intangible, and avatars can provide a concrete, tangible focus that
helps us understand the service.
Right now, IoT systems are still pretty novel and not well understood, at least
by consumers. It’s easy to look to individual devices as a handle to understand
the system, whether or not this is accurate. (We’ve heard smart meter users
refer to the in-home counter-top display as the ‘smart meter’, and the actual
smart meter as the ‘computer under the stairs’: see figure 4.20). You might
need to play up the role of the devices in communicating what your system
does (presenting it as a service-enabled device), just to help consumers
understand it.