GB2574572A

GB2574572A - Travel management communication system

Info

Publication number: GB2574572A
Application number: GB1803949.5A
Authority: GB
Inventors: Petorv Yordanov Stoyan; Leo Johan Verrept Peter
Original assignee: UNICARD Ltd
Current assignee: UNICARD Ltd
Priority date: 2018-03-12
Filing date: 2018-03-12
Publication date: 2019-12-18
Also published as: GB201803949D0

Abstract

A wireless electronic ticketing system that utilises Bluetooth® Low Energy (BLE) communication. In one embodiment, a device, mobile phone 100, runs a secure ticketing application 910 that causes the mobile phone to emulate an ITSO certified media 150 by transmitting data structured in accordance with the ITSO specification, such as smart ticketing data, to an accepting device 300, such as a ticketing gate, via bi-directional BLE communication 600. Alternatively, the mobile phone uses unidirectional BLE (fig. 2). A cryptogram indicative of the time and/or location of the mobile phone may be stored within an MCRN data element of the ITSO shell data set that is transmitted by the mobile phone. The device has a unique device identifier. The secure application may reference the unique address, MAC address and Bluetooth environment. Augmented security functions may be provided by connection to a remote host 900.

Description

TRAVEL MANAGEMENT COMMUNICATION SYSTEM

The present specification relates to a ticket management communication system, particularly the enablement of communication between commuters and users on the one hand, and the providers of transport services and similar services.

On public rail and underground (subway) networks, access to the station platforms is usually mediated by automatic barriers. Formerly operated by introducing a ticket to the barrier, these are increasingly operation by means of a smartcard that is presented to a reader, the reader interrogating the smartcard using near field communication (NFC). Smart Technology and specifically Smart Ticketing is constantly evolving and coupled with ever-increasing personal connectivity, innovative approaches to ticketing are being offered. From a Global perspective, public transport is benefiting from such developments, where new standards for ticketing, payments, security and communications are being adopted.

The historic development of smartcards is principally founded on the ISO/IEC 14443 set of specifications where power management and communications between the physical smartcard and the accepting terminal is governed by the specification.

Considering current Smart Ticketing developments in the UK, the ITSO organisation, together with a number of suppliers, are developing the principles i

and execution of ITSO Host Card Emulation (HCE). HCE is where the mobile device’s internal environment supports the required ITSO media structure and data elements, as found in a physical Smartcard and presents these to the accepting device using the device’s Near Field Communication (NFC) capability in accordance with ISO/IEC 14443 standard.

However, it is recognised that the NFC capability differs between mobile device design as well as manufactures and thus effective and reliable coupling with the accepting device remains largely unproven. Further, while the NFC interface of Android based devices is readily accessible to HCE developments, iOS devices produced by Apple Inc. restrict such access to only a few players involved in contactless payments and at the time of writing, exclusions include the ITSO organisation and approved developers/suppliers. Similar restrictions may also apply to devices running Microsoft mobile operating systems.

Further, transactions between the physical or virtual smartcards and the terminal can only be done at short range (typically maximum of 10cm) which restricts the usage of the ITSO standard for non-transport applications

Further, ISO/IEC 14443 / NFC implementation is not available on all android mobile phones or locked down in such a way as to make it unusable for ITSO implementations on Apple devices or Windows mobile. Therefore it is not possible to use these devices with the current ITSO solution

The object of the present invention is to allow a more convenient and flexible communication between public transport users and the public transport system.

According to a first aspect of the present invention, there is provided a system according to claim 1, and according to a second aspect of the present invention, there is provided a system according to claim 15.

The system described herein allows the utilisation of Bluetooth Low Energy (BLE) communications across a wide range of connected devices, both static and mobile, this invention defines a range of systems for the delivery of, but not limited too; location & journey planning information, ticketing information, ticket selection & use (both pre-pay & post-pay) as well as advertising & marketing data.

The invention will now be described, by way of example, with reference to the drawings, of which

Figure 1 shows a system overview of a first embodiment of a typical beacon device incorporating an operating system, an application and associated memory storage and Bluetooth interface, facilitating the ITSO Shell Environment Dataset service, with communications between the device and the accepting device(s) is facilitated using Bluetooth Low Energy (BLE).

Figure 2 shows a system overview of the first embodiment of a typical smart phone incorporating a physical trusted execution environment implementation running an ITSO Shell Environment Dataset service. Communications between the smart phone (the device) and the accepting device(s) is facilitated using Bluetooth Low Energy (BLE).

Figure 3 shows a system overview of the first embodiment of a typical smart phone incorporating a virtual trusted execution environment implementation running an ITSO Shell Environment Dataset service. Communications between the smart phone (the device) and the accepting device(s) is facilitated using Bluetooth Low Energy (BLE).

Figure 4 shows a conceptual view of the first embodiment of the Create Cryptogram function using specific data references within a typical beacon device with the resultant Cryptogram being stored within the MCRN data element of the ITSO Shell Environment Dataset.

Figure 5 shows a conceptual view of the first embodiment of the Create Cryptogram function using specific data references within a typical smart phone device with the resultant Cryptogram being stored within the MCRN data element of the ITSO Shell Environment Dataset.

Figure 6 shows a system overview of a second embodiment of a typical smart phone incorporating a physical trusted execution environment implementation running an ITSO Host Card Emulation (HCE) service. Communications between the smart phone (the mobile device) and the electronic ticket machine (the accepting device) is facilitated using Bluetooth Low Energy (BLE).

Figure 7 shows a system overview of the second embodiment of a typical smart phone incorporating a virtual trusted execution environment implementation running an ITSO Host Card Emulation (HCE) service. Communications between the smart phone (the mobile device) and the electronic ticket machine (the accepting device) is facilitated using Bluetooth Low Energy (BLE).

Figure 8 shows a service protocol overview of the second embodiment of a typical communication session between a mobile device and an accepting device.

Figure 9 shows a conceptual view of the second embodiment of the Create Cryptogram function using data elements from a typical smart phone incorporating a physical trusted execution environment.

Figure 10 shows a conceptual view of the second embodiment of the Create Cryptogram function using data elements from a typical smart phone incorporating a virtual trusted execution environment.

Figure 11 shows a conceptual view of the second embodiment of the Verify Cryptogram function using data elements from a typical smart phone incorporating a physical trusted execution environment.

Figure 12 shows a conceptual view of the second embodiment of the Verify Cryptogram function using data elements from a typical smart phone incorporating a virtual trusted execution environment.

There are two general aspects to the system; the first general embodiment is for a system wherein the Bluetooth communication is initiated by e.g. a user device which will be interrogating the ticketing system, while the second general embodiment is for a system wherein the Bluetooth communication is initiated by the ticketing system device polling devices which are within range. The two aspects will be described in turn, however each of the general aspects may themselves be implemented with different variations.

Considering the first aspect, the system functions as a data broadcasting device including general Smartcard data in a network of one or multiple devices. The broadcast data can specifically be structured on the ITSO Shell Environment Dataset and includes the optional MCRN data element and where the dataset is sealed in accordance with the ITSO Specification. The MCRN data element can assume a range of data values and services, interpreted by the accepting device(s), where an accepting device may optionally use the broadcast dataset in respect of Smart Ticketing and other applications.

In accordance with the invention, the device will typically be either: a beacon or similar device, a smart phone, tablet or wearable device, where an integral operating system capable of running one or more user applications will facilitate the ITSO Shell Environment Dataset service for the purposes of transmitting (broadcasting) the ITSO Shell Dataset to an accepting device 700 or devices. Accepting devices, including ITSO Certified devices, are typically: Electronic Ticketing Machines, Platform Validators, Hand Held Terminals and transport Gates/Barriers. Such Accepting devices typically include an ISO/IEC 14443 interface 750. Transmission of the ITSO Shell Dataset from the device to the accepting device 700 or devices, is achieved through the use of BluetoothTM Low Energy, BLE wireless technology. Utilising the core functionality of the Bluetooth specification, core versions 4, 5 and subsequent revisions. The system design establishes the device as a ‘transmit only’ device utilising either an Advertising channel or Data channel for data packet transmission.

In accordance with the invention, the system design utilises the ITSO Shell Dataset structure as the PDU payload within the data packet and where the MCRN data element within the ITSO Shell Dataset structure contains a unique data reference or signature as static data or dynamic data under the control of the system. The ITSO Shell Dataset is initialised via the device’s configuration / commissioning port. In accordance with the ITSO Specification, the ITSO Shell Dataset is sealed using an external ISAM via the device’s configuration / commissioning port. The system design allows for the ITSO Shell Dataset to be changed after the initial commissioning.

In an embodiment in accordance with the invention shown in Figure 1, the device 400 incorporates an operating system 401, and secure application 410, along with ITSO environment 450 as well as the device’s ID 420 and Bluetooth environment 430. The secure application 410, incorporates cryptographic functions 411 and 412. The cryptographic functions Create 411 and Verify 412, which optionally reference the device’s ID 420, the MAC Address 431 and the ITSO Shell data elements 451 with the resultant cryptogram being stored within the ITSO Shell MCRN data element.

The initial loading and commissioning of the secure application 410 and ITSO Environment 450 including the ITSO Shell Dataset 451, is achieved using the device’s configuration / commissioning port 440. Following the initial loading and commissioning of the ITSO Shell Dataset 451, the invention allows for the ITSO Shell Dataset 451, and individual data elements to be changed using the device’s configuration / commissioning port 440.

Configuration and commissioning may also be achieved using the device’s wireless communications interface.

Communications between the device’s Bluetooth environment 430 and the accepting device’s Bluetooth environment 740 are in accordance with the Bluetooth specification and where the BLE communication path 500 conforms to principals of the Link Layer utilising a single packet format for both Advertising channel packets and Data channel packets.

In an embodiment in accordance with the invention shown in Eigure 2, the device 1000 incorporates an operating system 1010, a SIM Card 1100, the device’s ID 1200 along with the Bluetooth environment 1300. The trusted execution environment 1400 is integral to the device’s core electronics design, as a physical implementation 1410 and provides the required secure environment supporting the application 9100, the ITSO Environment 1500 and the cryptographic functions 9110 and 9120. The cryptographic functions Create 9110 and Verify 9120, may optionally reference the IMSI 1110, the IMEI 1210, the MAC Address 1310 and the ITSO Shell data elements 1510 with the resultant cryptogram being stored within the ITSO Shell MCRN data element.

Alternately, the MCRN data element may accommodate a range of data values and/or location services 1600 under the control of the system.

The embodiment shown in Figure 2, incorporating the smart phone 1000 and identified elements forms the device.

The initial loading and initialisation of the application 9100 and ITSO environment 1500 is achieved using the device’s 2G/3G/4G/5G or routed Wi

Fi (IEEE 802.11 standard) data connection to the device’s service operator’s network 800 and subsequent routing to the inventor’s remote host 900.

Communications between the device’s Bluetooth environment 1300 and the accepting device’s Bluetooth environment 740 are in accordance with the Bluetooth specification and where the BLE communication path 500 conforms to principals of the Link Layer utilising a single packet format for both Advertising channel packets and Data channel packets.

In an embodiment in accordance with the invention shown in Figure 3, the device 2000 incorporates an operating system 2010, a SIM Card 2100, the device’s ID 2200 along with the Bluetooth environment 2300. The trusted execution environment 2400 is an extension to the device’s operating system 2010, with augmented security functions provisioned by the remote host 900 using the phone’s 2G/3G/4G/5G or routed Wi-Fi (IEEE 802.11 standard) data connection to the operator’s network 800. The virtual implementation 2410 provides the required secure environment supporting the application 9100, the ITSO Environment 2500 and the cryptographic functions 9110 and 9120. The cryptographic functions Create 9110 and Verify 9120, may optionally reference the IMSI 1110, the IMEI 1210, the MAC Address 1310 and the ITSO Shell data elements 1510 with the resultant cryptogram being stored within the ITSO Shell MCRN data element.

Alternately, the MCRN data element will accommodate a range of data values and/or location services 1600 under the control of the system.

The embodiment shown in Figure 3, incorporating the smart phone 2000 and identified elements forms the device.

The initial loading and initialisation of the application 9100 and ITSO environment 2500 is achieved using the device’s 2G/3G/4G/5G or routed WiFi (IEEE 802.11 standard) data connection to the device’s service operator’s network 800 and subsequent routing to the inventor’s remote host 900.

Communications between the device’s Bluetooth environment 2300 and the accepting device’s Bluetooth environment 740 are in accordance with the Bluetooth specification and where the BLE communication path 500 conforms to principals of the Link Layer utilising a single packet format for both Advertising channel packets and Data channel packets.

In an embodiment in accordance with the invention shown in Figure 4, the device 400 shall incorporate a cryptographic function 411 that may be optionally used to generate a unique reference, the cryptogram, which is stored within the ITSO environment 450. The system generates a cryptogram using individual parameters contained within the device’s environment including: the device’s ID 420, the MAC Address of the Bluetooth hardware 431 together with the ITSO data elements: IIN, OID, ISSN & CHD 451 that feed the cryptographic function 411 with the resultant cryptogram being stored within the Multi-application Card Reference Number (MCRN) 451 data element within the HCE ITSO environment 450. During the initial loading and initialisation of the application 410 and creation of the ITSO environment 450, the cryptogram is created and subsequently stored within the MCRN data element before the ITSO Shell data elements 451 are sealed in accordance with the ITSO Specification.

In an embodiment in accordance with the invention shown in Figure 4, the system may optionally feed the cryptographic function 411 with a Time Stamp / Sequence Number 413 and/or location services 414.

In an embodiment in accordance with the invention shown in Figure 4, access to the ‘Create Cryptogram’ function 411 within the secure application 410 shall be protected by mutual authentication.

In an embodiment in accordance with the invention shown in Figure 5, the device 1000 or the device 2000, shall incorporate a cryptographic function 9110 that may be optionally used to generate a unique reference, the cryptogram, which is stored within the ITSO environment 1500 or the ITSO environment 2500. The system generates a cryptogram using individual parameters contained within the device’s environment including: the IMSI 1110 / 2110, the device’s IMEI 1210/2210, the MAC Address of the Bluetooth hardware 1310/2310 together with the ITSO data elements: UN, OID, ISSN & CHD 1510/2510 that feed the cryptographic function 9110 with the resultant cryptogram being stored within the Multi-application Card Reference Number (MCRN) 1510/2510 data element within the ITSO environment 1500/2500. During the initial loading and initialisation of the application 9100 and creation of the ITSO environment 1500/2500, the cryptogram is created and subsequently stored within the MCRN data element before the ITSO Shell data elements 1510/2510 are sealed in accordance with the ITSO Specification.

In an embodiment in accordance with the invention shown in Figure 5, the system may optionally feed the cryptographic function 9100 with a Time Stamp / Sequence Number 9130 and/or location services 1600.

In an embodiment in accordance with the invention shown in Figure 5, access to the ‘Create Cryptogram’ function 9130 within the secure application 9100 shall be protected by mutual authentication.

The second aspect of the system governs a generic smartcard host card emulation data interchange using bluetooth low energy communication protocols. A static or mobile device, where the device is running one or more applications provisioning a Host Card Emulation (HCE) service for the purposes of emulating Smartcard physical media and transacting with accepting device or devices uses bi-directional Bluetooth Low Energy (BLE) communications.

It provides an ITSO Smartcard Host Card Emulation Data Interchange using Bluetooth Low Energy Communication Protocols, and generally comprises a mobile device, typically a smart phone, tablet or wearable device, where the device is running one or more applications provisioning a Host Card Emulation (HCE) service for the purposes of emulating ITSO certified media and transacting with ITSO certified accepting device or devices using bidirectional Bluetooth Low Energy (BLE) communications.

Given the increasing presence of Bluetooth/BLE across a wide range of devices, thus providing a unified and accessible communications interface, the system adopts the BLE specification for all communications between devices mobile device to accepting device.

The system facilitates a data transfer mechanism, including the transfer of general Smartcard data in a network of one or multiple devices. Data transfer can specifically be structured on the ITSO Specification and includes the use of the optional MCRN data element and where the dataset is sealed in accordance with the ITSO Specification. The MCRN data element can assume a range of data values and services, interpreted by the accepting device(s), where an accepting device may optionally use the dataset in respect of Smart Ticketing and other applications.

The system introduces additional security elements, further reinforcing the ITSO security regime without any impact on the ITSO Specification. By incorporating specific unique data references within the mobile device’s environment, the system generates a cryptographic signature, the Cryptogram, which is stored at the time of the ITSO HCE creation.

The system introduces benefits including faster transaction times, distance based transactions (equivalent to Far Field Communications - FFC) and multiple concurrent transactions.

Detailed Description:

In accordance with the invention, the mobile device will typically be either be a smart phone, tablet or wearable device with an integral operating system capable of running one or more user applications, where one such application will be a Host Card Emulation (HCE) service for the purposes of emulating ITSO certified media and transacting with ITSO certified accepting devices. Accepting devices typically include: Electronic Ticketing Machines, Platform Validators, Hand Held Terminals and transport Gates/Barriers. Interoperability between the mobile device and the accepting device is achieved through the use of BluetoothTM Low Energy, BLE wireless technology.

It is possible to configure the system so that so that the mobile device and the accepting device communicate in a one to one relationship, or alternatively the system to could configured so that either one or many mobile devices can communicate with the accepting device in a one to one or one to many relationship.

To implement a one to one relationship, a first approach utilises the core functionality of the Bluetooth specification, core versions 4, 5 and subsequent revisions, the system design establishes the mobile device as the GATT Server and that the accepting device will be configured as a GATT Client, The mobile device, as a GATT Server will broadcast ITSO advertising packets looking for a response from an accepting device. Once detected, the mobile device will initiate a ‘Discovery’ session with the identified accepting device in order to confirm that ITSO Service(s) are supported. Having established that ITSO Service(s) are supported, the mobile device will then initiate a mutual authentication session, with the accepting device. The proposed methodology requires that the accepting device (Client) supports the required ITSO Service(s) in accordance with GATT service definitions. The GATT ITSO Service (one or multiple services) will be required to support full HCE Read/Write functionality and where; Create, Modify and Delete capability is required. This approach supports a one to one relationship between the mobile device and the accepting device.

To implement a one to one and a one to many relationship, a second approach utilises the core functionality of the Bluetooth specification, core versions 4, 5 and subsequent revisions, the system design establishes the mobile device as the GATT Client and that the accepting device will be configured as a GATT Server, The mobile device, as a GATT Client, listens for ITSO advertising packets from an accepting device. Once detected, the mobile device will first acknowledge and then will initiate a ‘Discovery’ session with the accepting device in order to confirm that ITSO Service(s) are supported. Having established that ITSO Service(s) are supported, the mobile device will then initiate a mutual authentication session, with the accepting device. The proposed methodology requires that the accepting device (Client) supports the required ITSO Service(s) in accordance with GATT service definitions. The GATT ITSO Service (one or multiple services) will be required to support full HCE Read/Write functionality and where; Create, Modify and Delete capability is required. This approach supports a one to one and one to many relationship between the accepting device and the mobile device or multiple mobile devices.

In accordance with this aspect of the invention, the system will create and initialise an HCE instance within the mobile device’s operational environment using the cloud based Remote Host services. As part of the HCE create and initialise process, the system will generate a cryptogram using individual parameters contained within the mobile device’s environment including: the SIM card IMS I, the device’s IMEI and the MAC Address of the Bluetooth hardware. These parameters, together with the HCE ITSO data elements: IIN, OID, ISSN & CHD (the ITSO ISRN), are combined to form the cryptogram with the resultant output being stored within the MCRN data element of the ITSO Shell.

In an embodiment in accordance with the invention shown in Figure 6, the smart phone 100 incorporates an operating system 101, a SIM Card 110, the device’s ID 120 along with the Bluetooth environment 130. The trusted execution environment 140 is integral to the smart phone’s core electronics design, as a physical implementation 141 and provides the required secure environment supporting the ticketing application 910, the HCE ITSO environment 150 and the cryptographic functions 911 and 912. The cryptographic functions Create 911 and Verify 912, reference the IMSI 111, the IMEI 121, the MAC Address 131 and the ITSO Shell data elements 151 with the resultant cryptogram being stored within the ITSO Shell MCRN data element. The smart phone 100 and identified elements forms the mobile device.

The initial loading and initialisation of the ticketing application 910 and HCE ITSO environment 150 is achieved using the device’s 2G/3G/4G/5G or routed Wi-Fi (IEEE 802.11 standard) data connection to the mobile device’s service operator’s network 800 and subsequent routing to the inventor’s remote host 900.

To implement a one to one relationship, in a first approach, communications between the mobile device’s Bluetooth environment 130 and the accepting device’s Bluetooth environment 310 are in accordance with the Bluetooth specification and where the BLE communication path 600 conforms to principals of Advertiser 100 and Scanner 300. The Bluetooth interface 130 under the control of the system, broadcasts ITSO advertising packets looking for a response from an accepting device. The advertising packet, once detected and authenticated by the Scanner 300, responds accordingly and following acceptance by the Advertiser 100, a connection is established (link establishment) by the Advertiser 100, Once connected, the Scanner 100 assumes Initiator status and becomes the Server device and the advertising device 300 becomes the Client device. This approach supports a one to one relationship between the mobile device and the accepting device.

To implement a one to one and a one to many relationship, in a second approach communications between the mobile device’s Bluetooth environment

130 and the accepting device’s Bluetooth environment 310 are in accordance with the Bluetooth specification and where the BLE communication path 600 conforms to principals of Advertiser 300 and Scanner 100, The Bluetooth interface 130 under the control of the system, listens for connectable ITSO advertising packets from the accepting device 300 and following detection and authentication, requests connection. Once a connection is established (link establishment), the Scanner 100 assumes Initiator status and becomes the Server device and the advertising device 300 becomes the Client device. This approach supports a one to one and one to many relationship between the accepting device and the mobile device or multiple mobile devices.

In an embodiment in accordance with the invention shown in Figure 7, the smart phone 200 incorporates an operating system, a SIM Card 210, the device’s ID 220 and the Bluetooth environment 230. The trusted execution environment 240 is an extension to the smart phone’s operating system 201, with augmented security functions provisioned by the remote host 900 using the phone’s 2G/3G/4G/5G or routed Wi-Fi (IEEE 802.11 standard) data connection to the operator’s network 800. The virtual implementation 241, provides the required secure environment supporting the ticketing application 910, the HCE ITSO environment 250 and the cryptographic functions 911 and 912. The cryptographic functions Create 911 and Verify 912, reference the IMSI 211, the IMEI 221, the MAC Address 231 and the ITSO Shell data elements 251 with the resultant cryptogram being stored within the ITSO Shell MCRN data element. The smart phone 200 and identified elements forms the mobile device.

The initial loading and initialisation of the ticketing application 910 and HCE ITSO environment 250 is achieved using the phone’s 2G/3G/4G/5G or routed Wi-Fi (IEEE 802.11 standard) data connection to the mobile device’s service operator’s network 800 and subsequent routing to the inventor’s remote host 900.

To implement a one to one relationship, in a first approach, communications between the mobile device’s Bluetooth environment 230 and the accepting device’s Bluetooth environment 310 are in accordance with the Bluetooth specification and where the BLE communication path 600 conforms to principals of Advertiser 200 and Scanner 300. The Bluetooth interface 230 under the control of the system, broadcasts ITSO advertising packets looking for a response from an accepting device. The advertising packet, once detected and authenticated by the Scanner 300, responds accordingly and following acceptance by the Advertiser 200, a connection is established (link establishment) by the Advertiser 200, Once connected, the Scanner 200 assumes Initiator status and becomes the Server device and the advertising device 300 becomes the Client device. This approach supports a one to one relationship between the mobile device and the accepting device.

To implement a one to one and a one to many relationship, in a second approach communications between the mobile device’s Bluetooth environment 230 and the accepting device’s Bluetooth environment 310 are in accordance with the Bluetooth specification and where the BLE communication path 600 conforms to principals of Advertiser 300 and Scanner 200, The Bluetooth interface 230 under the control of the system, listens for connectable ITSO advertising packets from the accepting device 300 and following detection and authentication, requests connection. Once a connection is established (link establishment), the Scanner 200 assumes Initiator status and becomes the Server device and the advertising device 300 becomes the Client device. This approach supports a one to one and one to many relationship between the accepting device and the mobile device or multiple mobile devices.

In an embodiment in accordance with the invention shown in Figure 8, the mobile device 100 and the mobile device 200 will, following link establishment, initiate the GATT service discovery phase 610, where the accepting device will acknowledge and publish its entire GATT service capability 620 and when configured as an ITSO certified terminal 300, publication will include GATT ITSO Service(s) 621. Following acknowledgement of the published ITSO Service 621, the mobile device will initiate a mutual authentication challenge 611 to the accepting device and following confirmation of the mutual authentication response 622, the mobile device will issue the Start ITSO Service command 612. Thereafter, the accepting device will interrogate the HCE ITSO environment 150, or the HCE ITSO environment 250, using a set of ITSO media related commands for Read/Write functionality and where ITSO accredited functions: Create, Modify and Delete capability are required. Typical ITSO commands issued by the accepting device 300 using the BLE communication link 600 shall include: Initiate ISAM Security Checks - 623, Request ITSO Shell Data - 624, Request ITSO Directory - 625, Request IPE Data - 626, Request Value Group Data 627.

The inventor, as a Bluetooth SIG Associate Member, shall incorporate its Universally Unique Identifier (UUID) into the GATT Service structures supported by the mobile device 100 and mobile device 200 and accepting device(s) 300 in accordance with the Bluetooth BLE specification. In the case of the accepting device 300, the inventor shall make available to all third parties, a Software Development Kit (SDK) encapsulating the GATT Client 620 full range of services (refer to Figures 6 and 7). Utilisation of the GATT Client services 620 will be governed by the inventor under licence where access is controlled by the use of a software dongle 999, typically a preprogrammed USB plug-in device.

In an embodiment in accordance with the invention shown in Figure 9, the mobile device 100 shall incorporate a cryptographic function 911 that generates a unique reference, the cryptogram, which is subsequently stored within the HCE ITSO environment 150. The system generates a cryptogram using individual parameters contained within the mobile device’s environment including: the IMSI 111, the device’s IMEI 121, the MAC Address of the Bluetooth hardware 131 together with the HCE ITSO data elements: IIN, OID, ISSN & CHD 151 that feed the cryptographic function 911 with the resultant cryptogram being stored within the Multi-application Card Reference Number (MCRN) 151 data element within the HCE ITSO environment 150. During the initial loading and initialisation of the ticketing application 910 and creation of the HCE ITSO environment 150, the cryptogram is created and subsequently stored within the MCRN data element before the ITSO Shell data elements 151 are sealed in accordance with the ITSO Specification.

In an embodiment in accordance with the invention shown in Figure 9, the system may optionally feed the cryptographic function 911 with a Time Stamp / Sequence Number 913.

In an embodiment in accordance with the invention shown in Figure 9, access to the ‘Create Cryptogram’ function 911 within the trusted execution environment 140 physical implementation 141 shall be protected by mutual authentication between the secure application 910 and the trusted execution environment 140.

In an embodiment in accordance with the invention shown in Figure 10, the mobile device 200 shall incorporate a cryptographic function 911 that generates a unique reference, the cryptogram, which is subsequently stored within the HCE ITSO environment 250. The system generates a cryptogram using individual parameters contained within the mobile device’s environment including: the IMSI 211, the device’s IMEI 221, the MAC Address of the Bluetooth hardware 231 together with the HCE ITSO data elements: IIN, OID, ISSN & CHD 251 that feed the cryptographic function 911 with the resultant cryptogram being stored within the Multi-application Card Reference Number (MCRN) 251 data element within the HCE ITSO environment 250. During the initial loading and initialisation of the ticketing application 910 and creation of the HCE ITSO environment 250, the cryptogram is created and subsequently stored within the MCRN data element before the ITSO Shell data elements 251 are sealed in accordance with the ITSO Specification.

In an embodiment in accordance with the invention shown in Figure 10, the system may optionally feed the cryptographic function 911 with a Time Stamp / Sequence Number 913.

In an embodiment in accordance with the invention shown in Figure 10, access to the ‘Create Cryptogram’ function 911 within the trusted execution environment 240 virtual implementation 241 shall be protected by mutual authentication between the secure application 910 and the trusted execution environment 240.

In an embodiment in accordance with the invention, verification of the cryptogram stored within the MCRN 151 data element (physical implementation - Figure 11) or MCRN 251 data element (virtual implementation - Figure 12), shall be performed by the accepting device 300 using the Software Development Kit (SDK) GATT Client services 620 in conjunction with the software dongle 999. Access to the ‘Verify Cryptogram’ function 911 within the software dongle 999 shall be protected by mutual authentication between the accepting device’s 300 software, firmware and hardware execution environment and the software dongle 999.

In an embodiment in accordance with the invention shown in Figure 6, the mobile device 100 (physical implementation), shall, as part of the mutual authentication challenge 611, convey to the accepting device 300, as encrypted values, the cryptographic feed parameters: IMSI 111, IMEI 121, MAC Address 131 together with the HCE ITSO data elements: IIN, OID, ISSN & CHD and MCRN 151 - physical trusted execution environment. The optional cryptographic feed parameter: Time Stamp / Sequence Number 913, may also be conveyed.

In an embodiment in accordance with the invention shown in Figure 7, the mobile device 200 (virtual implementation), shall, as part of the mutual authentication challenge 611, convey to the accepting device 300, as encrypted values, the cryptographic feed parameters: IMSI 211, IMEI 221, MAC Address 231 together with the HCE ITSO data elements: IIN, OID, ISSN & CHD and MCRN 251 - virtual trusted execution environment. The optional cryptographic feed parameter: Time Stamp / Sequence Number 913, may also be conveyed.

In an embodiment in accordance with the invention shown in Figure 6, the result of verification of the conveyed cryptogram stored within the MCRN 151 - physical trusted execution environment by the accepting device 300, will be returned to the mobile device 100 during the mutual authentication response 622 (refer to Figure 8).

In an embodiment in accordance with the invention shown in Figure 7, the result of verification of the conveyed cryptogram stored within the MCRN

251 - virtual trusted execution environment by the accepting device 300, will be returned to the mobile device 200 during the mutual authentication response 622 (refer to Figure 8).

In an embodiment in accordance with the invention, the accepting device 300, Figure 6 and Figure 7, will typically incorporate an ISO/IEC 14443 interface 350.

Claims

1. A static or mobile device comprising of:

an operating system;

a secure application and memory storage;

a uni-directional BluetoothTM interface;

a unique device identifier;

a local configuration / commissioning / input / output port; and or a wireless communications configuration / commissioning port.

2. The device of Claim 1 including a user display.

3. The device of Claim 1, wherein the Bluetooth environment and associated Media Access Control Address, the MAC Address, is referenced by the secure application.

4. The device of Claim 1, wherein the device’s unique identity, is referenced by the secure application.

5. The device of Claim 1, wherein the Bluetooth interface is configured for BLE uni-directional transmit only for data broadcast operation.

6. A system comprising of: the device according to Claim 1, the secure application and memory storage, the operating system, the configuration / commissioning port, the BLE interface of Claim 5, the MAC Address of Claim 3, and the device’s ID of Claim 4.

7. The system of Claim 6, wherein the secure application and memory storage is commissioned and configured through the device’s local configuration / commissioning port; and or

8. The system of Claim 6, wherein the secure application and memory storage is commissioned and configured through the device’s wireless communications interface.

9. The system of Claim 6, wherein general data including Smartcard data is provisioned as a Dataset service for the purposes of broadcasting the said Dataset using the Bluetooth interface and where service provision includes the creation, updating and deletion of data via the local configuration / commissioning port.

10. The system of Claim 6, wherein an ITSO Shell Environment Dataset service is provisioned for the purposes of broadcasting the said Dataset using the Bluetooth interface and where service provision includes the creation, updating and deletion of an ITSO Shell and its sub-components via the local configuration / commissioning port.

11. A method of using the system of Claim 6 to generate a Cryptogram utilising the ITSO Shell data elements: IIN, OID, ISSN and CHD along with other unique references including the device ID, the BLE interface, together with other parameters under the control of the system. The resultant Cryptogram being stored within the ITSO Shell data element: MCRN.

12. A method of using the system of Claim 6 for the storage of data using to the ITSO Shell data element: MCRN. The conveyance such data may be used directly or indirectly by an accepting device.

13. The method of Claim 11, whereby the Cryptogram being stored within the ITSO Shell data element: MCRN, shall be verified by the accepting device where the verification service is provisioned by the inclusion of a Security Dongle.

14. The method of Claim 11, shall support the optional inclusion of further data references that include time based parameters and/or sequence based parameters as well as service identification and/or location information.

15. A mobile device comprising:

an operating system;

a secure application and memory storage;

a trusted execution environment;

a wireless communications interface;

a subscriber identification module; and a BluetoothTM interface.

16. The device of Claim 15 including a user display.

17. A computer program product comprising computer readable instructions that when executed on a device comprising a Bluetooth interface will cause the device to store an ITSO shell dataset, and will cause the device to be operable as a

15 transmit only device where the device transmits the ITSO shell dataset using unidirectional Bluetooth Low Energy, wherein a cryptogram indicative of time and/or location is stored within an MORN data element of the ITSO shell dataset transmitted by the device.

17. The device of Claim 15 wherein the device is a smart phone, tablet or wearable device with an integral operating system capable of running one or more user applications.

18. The mobile device of Claim 15, wherein the operating system is Apple - iOS, Google - Android and Microsoft - Windows 10 Mobile.

19. The mobile device of Claim 15, wherein the Subscriber Identification Module (SIM), the SIM Card, containing a unique International Mobile Subscriber Identity (IMSI), which is referenced by the secure application.

20. The mobile device of Claim 15, wherein the Bluetooth environment and associated Media Access Control Address, the MAC Address, is referenced by the secure application.

21. The mobile device of Claim 15, wherein the International Mobile Equipment Identity, the IMEI, is referenced by the secure application.

22. The mobile device of Claim 15, wherein the secure application is coupled to the trusted execution environment and operating system.

23. The mobile device of Claim 15, wherein the Bluetooth interface is configured for Bluetooth Low Energy (BLE) bi-directional operation.

24. A system comprising of: the mobile device according to Claim 15, the secure application, the trusted execution environment, the operating system, the wireless communications interface, the BLE interface of Claim 23, the SIM Card of Claim 19, the MAC Address of Claim 20 and the IMEI of Claim 21.

25. The system of Claim 24, wherein the trusted execution environment is integral to the mobile device’s microcontroller / microprocessor, offering a separate and secure operating system and execution environment - the physical implementation.

26. The system of Claim 24, wherein the trusted execution environment, as an extension to the operating system, is augmented as a cloud service facilitated by the remote host offering a secure operating system and execution environment - the virtual implementation.

27. The system of Claim 24, wherein the trusted execution environment, the virtual implementation, is augmented through the mobile device’s cellular 2G/3G/4G/5G connection to the mobile operator’s network. 2G/3G/4G/5G and future standards are wireless mobile telecommunications technology standards governed by the International Mobile Telecommunications industry.

28. The system of Claim 24, wherein the trusted execution environment, the virtual implementation, is augmented through the mobile device’s Wi-Fi (IEEE 802.11 standard) where connection to the mobile operator’s network is typically routed via the internet.

29. The system of Claim 24, wherein a Host Card Emulation (HCE) service is provisioned for the purposes of transacting via BLE communications, generic Smartcard data and where service provision includes the creation, updating and deletion of Smartcard HCE data.

30. The system of Claim 24, wherein a Host Card Emulation (HCE) service is provisioned for the purposes of transacting via BLE communications, ITSO certified media and where service provision includes the creation, updating and deletion of ITSO HCE data.

31. The system of Claim 24, wherein the BLE bi-directional interface is configured to communicate with an accepting device for the purposes of: link establishment, security checks including mutual authentication, enabling access to the HCE service for data exchange (read, write, append, delete, create), device status and control and link disconnection.

32. A method of using the system of Claim 24 to generate a Cryptogram utilising the HCE ITSO Shell data elements: IIN, OID, ISSN and CHD along with other unique references offered by the SIM Card, the device ID and the BLE interface. The resultant Cryptogram being stored within the HCE ITSO Shell data element: MCRN.

33. A method of using the system of Claim 24 to initiate a communication session with an accepting device in order to identify the device’s BLE service repertoire that shall include the ITSO service.

34. A method of using the system of Claim 24 to initiate mutual authentication with the ITSO accredited terminal, the accepting device, of the ITSO service provisioned by the accepting device, where mutual authentication requires positive confirmation.

35. A method of using the system of Claim 24 to instruct the accepting device to commence data exchange with the HCE ITSO media structure and data elements.

36. The method of Claim 35, where the accepting device will determine the sequence of data exchanges in accordance with the ITSO Specification and accepting device’s configured business rules.

37. The method of Claim 35, where the accepting device will signal the end

5 of the data exchange procedure and where the method of Claim 35 will initiate link disconnection.

38. A method of using the system of Claim 24 to adjust the power level of the accepting device’s BLE transmission signal.

39. The method of Claim 32, whereby the Cryptogram being stored within

10 the HCE ITSO Shell data element: MCRN, shall be verified by the accepting device where the verification service is provisioned by the inclusion of a Security Dongle software/hardware service.

40. The method of Claim 32, shall support the optional inclusion of further data references that include time based parameters and/or sequence based

15 parameters.

Amendments to the claims have been filed as follows

3 05 19

CLAIMS:

1. A device comprising;

a Bluetooth interface;

5 wherein the device is configured to support the ITSO media structure and data elements; and wherein the device is configured to emulate an ITSO certified media via bidirectional Bluetooth Low Energy communication, the emulation comprising performing data transfer structured in accordance with the ITSO Specification with 10 an accepting device via bi-directional Bluetooth Low Energy communication.

2. A device as claimed in claim 1, wherein a cryptogram indicative of a time and/or a location of the device is stored within an MCRN data element of an ITSO shell dataset transmitted during the data transfer.

3. A device as claimed in claim 2, wherein the cryptogram includes a unique identifier.

4. A device as claimed in claim 1, 2 or 3, wherein the device is a mobile phone, 20 tablet or wearable device.

5. A device as claimed in claim 4, wherein the ITSO certified accepting device is an electronic ticketing machine, platform validator, hand-held terminal or transport barrier.

6. A device as claimed in any preceding claim, wherein the data transfer comprises transfer of smart ticketing data.

7. A computer program product comprising computer readable instructions that

30 when executed on a device comprising a Bluetooth interface will cause the device to support the ITSO media structure and data elements, and will cause the device to emulate an ITSO certified media via bi-directional Bluetooth Low Energy, the emulation comprising performing data transfer structured in accordance with the ITSO Specification with an accepting device via bi-directional Bluetooth Low Energy 35 communication.

8. A computer program product comprising computer readable instructions that when executed on an accepting device comprising a Bluetooth interface will cause the accepting device to support ITSO services and transact with a device emulating an ITSO media, and will cause the accepting device to receive data transfer structured in accordance with the ITSO specification from the device via bidirectional Bluetooth Low Energy.

9. A method of performing a smart ticketing operation, comprising: providing a device including a Bluetooth interface, the device supporting the

ITSO media structure and data elements; and performing data transfer between the device and an accepting device via bidirectional Bluetooth Low Energy communication, wherein the data transfer is structured in accordance with the ITSO specification, and wherein the device emulates an ITSO certified media.

10. A device comprising;

a Bluetooth interface;

wherein the device is configured to store an ITSO shell dataset;

wherein the device is configured to be operable as a transmit-only device where the device transmits the ITSO Shell dataset using uni-directional Bluetooth Low Energy communication; and wherein a cryptogram indicative of a time and/or a location of the device is stored within an MCRN data element of the ITSO Shell dataset transmitted by the device.

11. A device as claimed in claim 10, wherein the cryptogram includes a unique identifier.

12. A device as claimed in claim 10 or 11, wherein the device is a mobile phone, tablet or wearable device.

13. A device as claimed in claim 10 or 11 wherein the device is a fixed device, electronic ticketing machine, platform validator, hand-held terminal or transport barrier.

3 05 19

14. A device as claimed in any of claims 10 to 14, wherein the ITSO shell dataset is transmitted via Bluetooth Low Energy as an advertising packet.

5 15. A device as claimed in any of claims 10 to 14, wherein the ITSO shell dataset stored on the device is sealed using ISAM.

16. A device as claimed in any of claims 10 to 15, wherein the device is configured to permit modification of the ITSO shell dataset after initial loading onto

10 the device