Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
TRANSACTION SYSTEM
Document Type and Number:
WIPO Patent Application WO/2018/029484
Kind Code:
A1
Abstract:
A method of and apparatus for transmitting data between devices during a voice call, the method comprising: sending an initialisation signal from a first device to a second device; selecting at the second device a communications protocol in dependence on the received initialisation signal; and transmitting data from the second device to the first device using the selected communications protocol; wherein the initialisation signal is encoded as audio in the voice call.

Inventors:
CRITCHLEY TIMOTHY (GB)
JACKSON DAVID (GB)
BALDWIN THOMAS (GB)
TAO YUFEI (GB)
Application Number:
PCT/GB2017/052370
Publication Date:
February 15, 2018
Filing Date:
August 10, 2017
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
SEMAFONE LTD (GB)
International Classes:
H04L29/06; H04M7/00
Domestic Patent References:
WO2000019699A12000-04-06
Foreign References:
US6230024B12001-05-08
GB2014051311W2014-04-25
Attorney, Agent or Firm:
JASZEK, Richard (GB)
Download PDF:
Claims:
Claims

1 . A method of transmitting data between devices during a voice call, comprising:

sending an initialisation signal from a first device to a second device;

selecting at the second device a communications protocol in dependence on the received initialisation signal; and

transmitting data from the second device to the first device using the selected communications protocol;

wherein the initialisation signal is encoded as audio in the voice call.

2. A method according to claim 1 , wherein the communications protocol identifies a communications channel and/or an encoding scheme.

3. A method according to claim 1 or 2, wherein the communications protocol selected by the second device is used for subsequent data transmission between the devices.

4. A method according to any preceding claim, further comprising querying by the first device a property of the second device via the initialisation signal.

5. A method according to claim 4, wherein the property is a communications ability.

6. A method according to any of claims 4 or 5, wherein the first device determines the property of the second device in dependence on the response to the initialisation signal.

7. A method according to any preceding claim, wherein the initialisation signal comprises information identifying at least one proposed communications protocol.

8. A method according to claim 7, further comprising selecting the proposed communications protocol as the selected communications protocol.

9. A method according to any of claims 4 to 8, further comprising determining the proposed communications protocol in dependence on the determined property of the second device.

10. A method according to any preceding claim, wherein if transmission of the data is unsuccessful using the selected communications protocol, selecting a further protocol as the selected protocol and transmitting the data via the further protocol.

1 1 . A method according to any preceding claim, further comprising determining whether an alternative, preferably more efficient, communications protocol is available and conducting subsequent data transmission via the alternative communications protocol.

12. A method according to claim 1 1 , further comprising the first and/or second device polling the other to determine whether an alternative communications protocol is available.

13. A method according to claim 1 1 or 12, wherein if transmission of the data is unsuccessful using the alternative communications protocol, reverting to data transmission via the previously selected communications protocol.

14. A method according to any preceding claim, wherein the selected communications protocol is an audio protocol.

15. A method according to claim 14, wherein the selected communications protocol is the same as that used for the voice call. 16. A method according to claim 14 or 15, wherein a voice-optimised codec is used for non- voice data transmission.

17. A method according to any of claims 14 to 16, wherein the selected protocol is compatible with the adaptive multi-rate AMR codec.

18. A method according to any of claims 14 to 17, further comprising the use of single, multi- tones, speech symbols or a combination of tones and speech symbols, optionally using a tone to expand the speech symbol of the codec.

19. A method according to any of claims 14 to 18, further comprising selecting speech encoding parameters from a master symbol set in such a way as to minimise transmission errors. 20. A method according to any of claims 14 to 19, further comprising varying or adapting the symbol set used for encoding the data being transmitted dynamically in dependence on changes to the AMR codebook, preferably per sub-frame, more preferably so as to avoid codes determined to be unsuitable.

21 . A method according to any of claims 14 to 20, further comprising estimating encoder characteristics from spectral analysis of the received audio and determining bandwidth and/or characteristic frequencies, preferably averaged over a time window.

22. A method according to according to any of claims 1 to 13 wherein the selected protocol is a non-audio data protocol.

23. A method according to according to claim 22, wherein the initialisation signal comprises information for locating the other device using the non-audio protocol, for example via directory services.

24. A method according to any preceding claim, wherein the first or second device comprises a user handset such as a smartphone.

25. A method according to any preceding claim, wherein the first or second device comprises a call processor, preferably associated with a call centre. 26. A method according to any preceding claim, further comprising facilitating the provision of sensitive data during a telephone call between a user or caller to and an agent of a contact or call centre or to a merchant, wherein sensitive data is provided by the caller during the call for forwarding to a third party.

27. A method according to claim 26, wherein the sensitive data provided by the caller is prevented from reaching the agent.

28. A method according to claim 27, wherein sensitive data provided via audio is suppressed or masked by an audio tone.

29. A method according to any preceding claim, method further comprising at least one of: i) obtaining consent for the data transmission from a user of the first and/or second device;

ii) authenticating the user;

iii) determining the authorisation of the user; and

transmitting the data only if the corresponding of at least one of consent, authentication and authorisation determined to be valid. 30. A method according to claim 29, wherein the authorisation is local to the device.

31 . A method according to claim 29 or 30, wherein the authorisation is remote from the device.

32. A method according to any of claims 29 to 31 , wherein obtaining an authorisation comprises at least one of:

i) receiving an input from the user;

ii) detecting an object or token in possession of the user; and

iii) determining a property of the user.

33. A method according to claim 32, wherein the object is a contactless or NFC card.

34. A method according to claim 32 or 33, wherein the property is a biometric property. 35. A method according to any preceding claim, when used for at least one of:

i) contactless payments during a telephone call, including card-not-present; ii) authentication during a telephone call, including two-factor or dual authentication; and

iii) remote troubleshooting and monitoring. 36. A method performed in a first device participating in the transmission of data during a voice call, comprising:

transmitting an initialisation signal to a second device;

receiving data from the second device in a communications protocol selected oin dependence on the initialisation signal; and

transmitting data to the second device using the selected communications protocol; wherein the initialisation signal is encoded in the audio stream of the voice call.

37. A method performed in a second device participating in the transmission of data during a voice call, comprising:

receiving an initialisation signal from a first device;

selecting a communications protocol in dependence on the received initialisation signal; and

transmitting data to the first device using the selected communications protocol; wherein the initialisation signal is encoded in the audio stream of the voice call.

38. Apparatus for transmitting data between devices during a voice call, comprising:

a first device adapted to send an initialisation signal to a second device; and a second device adapted to select a communications protocol in dependence on the received initialisation signal and to transmit data to the first device using the selected communications protocol;

wherein the initialisation signal is encoded as audio in the voice call.

39. Apparatus according to claim 38, wherein the communications protocol identifies a communications channel and/or an encoding scheme. 40. Apparatus according to claim 38 or 39, wherein the first and/or second device is adapted to use the selected communications protocol for subsequent data transmission between the devices.

41 . Apparatus according to any of claims 38 to 40, wherein the first and/or second device is adapted to query a property of the other device by means of the initialisation signal. 42. Apparatus according to claim 41 , wherein the property is a communications ability.

43. Apparatus according to any of claims 41 or 42, wherein the first and/or second device is adapted to determine the property of the other device in dependence on the response to the initialisation signal.

44. Apparatus according to any of claims 38 to 41 , wherein the initialisation signal comprises information identifying at least one proposed communications protocol.

45. Apparatus according to claim 44, wherein the first and/or second device is further adapted to select the proposed communications protocol as the selected communications protocol.

46. Apparatus according to any of claims 41 to 45, wherein the first and/or second device is further adapted to determine the proposed communications protocol in dependence on the determined property of the device.

47. Apparatus according to any of claims 38 to 46, wherein the first and/or second device is adapted to select a further protocol as the selected protocol and transmit the data via the further communications protocol if transmission of the data is unsuccessful using the selected protocol.

48. Apparatus according to any of claims 38 to 47, wherein the first and/or second device is further adapted to determine whether an alternative, preferably more efficient, communications protocol is available and to conduct subsequent data transmission via the alternative communications protocol. 49. Apparatus according to claim 48, wherein the first and/or second device is further adapted to poll the first and/or second device to determine whether an alternative communications protocol is available.

50. Apparatus according to claim 48 or 49, wherein the first and/or second device is further adapted such that, if transmission of the data is unsuccessful using the alternative communications protocol, to revert to data transmission via the previously selected communications protocol.

51 . Apparatus according to any of claims 38 to 50, wherein the selected communications protocol is an audio protocol.

52. Apparatus according to claim 51 , wherein the selected communications protocol is the same as that used for the voice call.

53. Apparatus according to claim 51 or 52, wherein the first and/or second device is adapted to use a voice-optimised codec for non-voice data transmission.

54. Apparatus according to any of claims 51 to 53, wherein the selected protocol is compatible with the adaptive multi-rate AMR codec. 55. Apparatus according to any of claims 51 to 54, wherein the first and/or second device is further adapted to use single, multi-tones, speech symbols or a combination of tones and speech symbols, optionally a tone to expand the speech symbol of the codec.

56. Apparatus according to any of claims 51 to 55, wherein the first and/or second device is further adapted to select speech encoding parameters from a master symbol set in such a way as to minimise transmission errors.

57. Apparatus according to any of claims 51 to 56, wherein the first and/or second device is further adapted to vary or adapt the symbol set used for encoding the data being transmitted dynamically in dependence on changes to the AMR codebook, preferably per sub-frame, more preferably so as to avoid codes determined to be unsuitable. 58. Apparatus according to any of claims 51 to 57, wherein the first and/or second device is further adapted to estimate encoder characteristics from spectral analysis of the received audio and determine bandwidth and/or characteristic frequencies, preferably averaged over a time window.

59. Apparatus according to according to any of claims 38 to 50 wherein the selected protocol is a non-audio data protocol.

60. Apparatus according to according to claim 59, wherein the initialisation signal comprises information for locating the other device using the non-audio protocol, for example via directory services.

61 . Apparatus according to any of claims 38 to 60, wherein the first and/or second device comprises a user handset such as a smartphone.

62. Apparatus according to any of claims 38 to 61 , wherein the first or second device comprises a call processor, preferably associated with a call centre.

63. Apparatus according to any of claims 38 to 62, further adapted to facilitate the provision of sensitive data during a telephone call between a user or caller to and an agent of a contact or call centre or to a merchant, wherein sensitive data is provided by the caller during the call for forwarding to a third party.

64. Apparatus according to claim 63, further adapted to prevent the sensitive data provided by the caller from reaching the agent.

65. Apparatus according to claim 64, further adapted to suppress or mask by an audio tone sensitive data provided via audio. 66. Apparatus according to any of claims 38 to 65, further adapted to at least one of:

i) obtain consent for the data transmission from a user of the first and/or second device;

ii) authenticate the user;

iii) determine the authorisation of the user; and

to transmit the data only if the corresponding of at least one of consent, authentication and authorisation determined to be valid.

67. Apparatus according to claim 66, wherein the authorisation is local to the device.

68. Apparatus according to claim 66 or 67, wherein the authorisation is remote from the device. 69. Apparatus according to any of claims 66 to 68, wherein the first and/or second device is further adapted to obtain an authorisation comprises by at least one of:

i) receiving an input from the user;

ii) detecting an object or token in possession of the user; and

iii) determining a property of the user. 70. Apparatus according to claim 69, wherein the object is a contactless or NFC card.

71 . Apparatus according to claim 69 or 70, wherein the property is a biometric property.

72. Apparatus according to any preceding claim, wherein the first and/or second device is adapted for use for at least one of:

iv) contactless payments during a telephone call, including card-not-present;

v) authentication during a telephone call, including two-factor or dual authentication; and

vi) remote troubleshooting and monitoring.

73. A device for participating in the transmission of data during a voice call, the device adapted to:

transmit an initialisation signal; receive data in a communications protocol selected on dependence on the initialisation signal; and

transmit data using the selected communications protocol;

wherein the initialisation signal is encoded in the audio stream of the voice call.

74. A device for participating in the transmission of data during a voice call, the device adapted to:

receive an initialisation signal;

select a communications protocol in dependence on the received initialisation signal; and

transmit data using the selected communications protocol;

wherein the initialisation signal is encoded in the audio stream of the voice call.

75. Apparatus for performing any of the methods of claims 1 to 37.

76. A computer program and a computer program product for carrying out any of the methods of claims 1 to 37.

77. A computer readable medium having stored thereon a program for carrying out any of the methods of claims 1 to 37.

78. A signal embodying a computer program for carrying out any of the methods of claims 1 to 37.

Description:
Transaction system

This invention relates to a transaction system including a method of and apparatus for data exchange between devices during a voice call. Also disclosed are inter alia a transaction protocol for transferring data during a voice call, apparatus for and a method of facilitating contactless transactions during a voice call and a multi-protocol call processor.

International patent application PCT/GB2014/05131 1 in the name of the same applicant (and incorporated herein by reference) describes a method of facilitating a transaction during a telephone or phone call, with particular application to an implementation involving an electronic wallet on a smartphone. The applicant has since developed further innovations as described in the following.

According to an aspect of the invention there is provided a method of transmitting data between devices during a voice call, comprising: sending an initialisation signal from a first device to a second device; selecting at the second device a communications protocol in dependence on the received initialisation signal; and transmitting data from the second device to the first device using the selected communications protocol; wherein the initialisation signal is encoded as audio in the voice call.

Preferably, the communications protocol identifies a communications channel and/or an encoding scheme.

Preferably, the communications protocol selected by the second device is used for subsequent data transmission between the devices.

Preferably, the method further comprises querying by the first device a property of the second device via the initialisation signal. The property may be a communications ability.

Preferably, the first device determines the property of the second device in dependence on the response to the initialisation signal. The initialisation signal may comprise information identifying at least one proposed communications protocol.

Preferably, the method further comprises selecting the proposed communications protocol as the selected communications protocol.

Preferably, the method further comprises determining the proposed communications protocol in dependence on the determined property of the second device. Preferably, the method further comprises, if transmission of the data is unsuccessful using the selected communications protocol, selecting a further protocol as the selected protocol and transmitting the data via the further protocol.

Preferably, the method further comprises determining whether an alternative, preferably more efficient, communications protocol is available and conducting subsequent data transmission via the alternative communications protocol.

The first and/or second device may poll the other to determine whether an alternative communications protocol is available.

Preferably, the method further comprises, if transmission of the data is unsuccessful using the alternative communications protocol, reverting to data transmission via the previously selected communications protocol.

The selected communications protocol may be an audio protocol. The selected communications protocol may be the same as that used for the voice call.

Preferably, a voice-optimised codec is used for non-voice data transmission. The selected protocol may be compatible with the adaptive multi-rate AMR codec.

Preferably, the method further comprises the use of single, multi-tones, speech symbols or a combination of tones and speech symbols, optionally using a tone to expand the speech symbol of the codec.

Preferably, the method further comprises selecting speech encoding parameters from a master symbol set in such a way as to minimise transmission errors.

Preferably, the method further comprises varying or adapting the symbol set used for encoding the data being transmitted dynamically in dependence on changes to the AMR codebook, preferably per sub-frame, more preferably so as to avoid codes determined to be unsuitable. Preferably, the method further comprises estimating encoder characteristics from spectral analysis of the received audio and determining bandwidth and/or characteristic frequencies, preferably averaged over a time window.

Preferably, the selected protocol is a non-audio data protocol.

Preferably, the initialisation signal comprises information for locating the other device using the non-audio protocol, for example via directory services. Preferably, the first or second device comprises a user handset such as a smartphone.

Preferably, the first or second device comprises a call processor, preferably associated with a call centre.

Preferably, the method further comprises facilitating the provision of sensitive data during a telephone call between a user or caller to and an agent of a contact or call centre or to a merchant, wherein sensitive data is provided by the caller during the call for forwarding to a third party.

Preferably, the sensitive data provided by the caller is prevented from reaching the agent.

Sensitive data provided via audio may be suppressed or masked by an audio tone. Preferably, the method further comprises at least one of: i) obtaining consent for the data transmission from a user of the first and/or second device; ii) authenticating the user; iii) determining the authorisation of the user; and transmitting the data only if the corresponding of at least one of consent, authentication and authorisation determined to be valid.

The authorisation may be local to the device or remote from the device. Preferably, obtaining an authorisation comprises at least one of: i) receiving an input from the user; ii) detecting an object or token in possession of the user; and iii) determining a property of the user.

The object may be a contactless or NFC card.

The property may be a biometric property. The method may be used for example for at least one of: i) contactless payments during a telephone call, including card-not-present; ^authentication during a telephone call, including two-factor or dual authentication; and iii) remote troubleshooting and monitoring.

According to another aspect of the invention there is provided a method performed in a first device participating in the transmission of data during a voice call, comprising: transmitting an initialisation signal to a second device; receiving data from the second device in a communications protocol selected oin dependence on the initialisation signal; and transmitting data to the second device using the selected communications protocol; wherein the initialisation signal is encoded in the audio stream of the voice call. According to another aspect of the invention there is provided a method performed in a second device participating in the transmission of data during a voice call, comprising: receiving an initialisation signal from a first device; selecting a communications protocol in dependence on the received initialisation signal; and transmitting data to the first device using the selected communications protocol; wherein the initialisation signal is encoded in the audio stream of the voice call.

According to a further aspect of the invention there is provided apparatus for transmitting data between devices during a voice call, comprising: a first device adapted to send an initialisation signal to a second device; and a second device adapted to select a communications protocol in dependence on the received initialisation signal and to transmit data to the first device using the selected communications protocol; wherein the initialisation signal is encoded as audio in the voice call.

The communications protocol may identify a communications channel and/or an encoding scheme Preferably, the first and/or second device is adapted to use the selected communications protocol for subsequent data transmission between the devices.

Preferably, the first and/or second device is adapted to query a property of the other device by means of the initialisation signal. The property may be a communications ability.

Preferably, the first and/or second device is adapted to determine the property of the other device in dependence on the response to the initialisation signal.

Preferably, the initialisation signal comprises information identifying at least one proposed communications protocol.

Preferably, the first and/or second device is further adapted to select the proposed communications protocol as the selected communications protocol. Preferably, the first and/or second device is further adapted to determine the proposed communications protocol in dependence on the determined property of the device.

Preferably, the first and/or second device is adapted to select a further protocol as the selected protocol and transmit the data via the further communications protocol if transmission of the data is unsuccessful using the selected protocol. Preferably, the first and/or second device is further adapted to determine whether an alternative, preferably more efficient, communications protocol is available and to conduct subsequent data transmission via the alternative communications protocol.

Preferably, the first and/or second device is further adapted to poll the first and/or second device to determine whether an alternative communications protocol is available.

Preferably, the first and/or second device is further adapted such that, if transmission of the data is unsuccessful using the alternative communications protocol, to revert to data transmission via the previously selected communications protocol.

Preferably, the selected communications protocol is an audio protocol. Preferably, the selected communications protocol is the same as that used for the voice call.

Preferably, the first and/or second device is adapted to use a voice-optimised codec for non- voice data transmission.

Preferably, the selected protocol is compatible with the adaptive multi-rate AMR codec.

Preferably, the first and/or second device is further adapted to use single, multi-tones, speech symbols or a combination of tones and speech symbols, optionally a tone to expand the speech symbol of the codec.

Preferably, the first and/or second device is further adapted to select speech encoding parameters from a master symbol set in such a way as to minimise transmission errors.

Preferably, the first and/or second device is further adapted to vary or adapt the symbol set used for encoding the data being transmitted dynamically in dependence on changes to the AMR codebook, preferably per sub-frame, more preferably so as to avoid codes determined to be unsuitable.

Preferably, the first and/or second device is further adapted to estimate encoder characteristics from spectral analysis of the received audio and determine bandwidth and/or characteristic frequencies, preferably averaged over a time window.

Preferably, the selected protocol is a non-audio data protocol.

Preferably, the initialisation signal comprises information for locating the other device using the non-audio protocol, for example via directory services.

Preferably, the first and/or second device comprises a user handset such as a smartph Preferably, the first or second device comprises a call processor, preferably associated with a call centre.

Preferably, the apparatus or first and/or second device is further adapted to facilitate the provision of sensitive data during a telephone call between a user or caller to and an agent of a contact or call centre or to a merchant, wherein sensitive data is provided by the caller during the call for forwarding to a third party.

Preferably, the apparatus or first and/or second device is further adapted to prevent the sensitive data provided by the caller from reaching the agent.

Preferably, the apparatus or first and/or second device is further adapted to suppress or mask by an audio tone sensitive data provided via audio.

Preferably, the apparatus or first and/or second device is further adapted to at least one of: i) obtain consent for the data transmission from a user of the first and/or second device; ii) authenticate the user; iii) determine the authorisation of the user; and to transmit the data only if the corresponding of at least one of consent, authentication and authorisation determined to be valid.

The authorisation may be local to or remote from the device.

Preferably, the first and/or second device is further adapted to obtain an authorisation comprises by at least one of: i) receiving an input from the user; ii) detecting an object or token in possession of the user; and iii) determining a property of the user. The object may be a contactless or NFC card.

The property may be a biometric property.

Preferably, the first and/or second device is adapted for use for at least one of: i) contactless payments during a telephone call, including card-not-present; ii) authentication during a telephone call, including two-factor or dual authentication; and ii) remote troubleshooting and monitoring.

According to another aspect of the invention there is provided a device for participating in the transmission of data during a voice call, the device adapted to: transmit an initialisation signal; receive data in a communications protocol selected on dependence on the initialisation signal; and transmit data using the selected communications protocol; wherein the initialisation signal is encoded in the audio stream of the voice call. According to another aspect of the invention there is provided a device for participating in the transmission of data during a voice call, the device adapted to: receive an initialisation signal; select a communications protocol in dependence on the received initialisation signal; and transmit data using the selected communications protocol; wherein the initialisation signal is encoded in the audio stream of the voice call.

Also disclosed is i) apparatus, ii) a computer program and a computer program product, iii) a computer readable medium having stored thereon a program and iv) a signal embodying a computer program for carrying out any of the methods herein described.

Also provided is a method performed by a first device in order to transmit data to a second device during a voice call, comprising: receiving an initialisation signal from the second device; selecting a communications protocol in dependence on the initialisation signal; and transmitting data to the second device using the selected communications protocol; wherein the initialisation signal is encoded in audio.

Encoded in audio may be understood as encoded in the audio component, stream or channel of the voice call

The selected protocol may be a non-audio data protocol.

Preferably, the method further comprises if transmission of the data is unsuccessful using the selected protocol, selecting a further protocol and transmitting the data via the further protocol. The selected or further protocol may be an audio protocol. The proposed communications protocol may be the same as that used for the voice call.

The initialisation signal may comprise information identifying a proposed communications protocol for potential selection by the device.

Preferably, the method further comprises selecting the proposed communications protocol as the selected communications protocol.

Preferably, the method further comprises at least one of: obtaining consent for the data transmission from a user of the first device; authenticating the user; determining the authorisation of the user; and transmitting the data to the second party only if the at least one of consent, authorisation and authorisation is valid. The authorisation may be local or remote. Preferably, obtaining an authorisation comprises at least one of: receiving an input from the user; detecting an object or token in possession of the user; and determining a property of the user.

The object may be a contactless or NFC card. The property may be a biometric property. Preferably, the method further comprises receiving data from the second party encoded in the selected or further protocol.

Generally, the system may allow for channel-agnostic real-time sensitive data interchange, offering reliable communication regardless of intervening infrastructure.

Preferably, the method comprises the use of voice-optimised codecs for non-voice data transmission.

Also provided is a device for transmitting data to a second device during a voice call, the device comprising: a receiver adapted to receive an initialisation signal from the second device; means for selecting a communications protocol in dependence on the initialisation signal; and a transmitter adapted to transmit data to the second device using the selected communications protocol; wherein the initialisation signal is encoded in audio.

Typically, although not exclusively, the system may be implemented to facilitate the provision of sensitive data during a telephone call between a Caller to and an Agent of a contact or call centre or to a merchant - although the system and associated protocol may be applied more generally situations which require the passing of data between two parties, especially at least partly over a voice call. The sensitive data may be provided by the Caller during the call for forwarding to a third party without the Agent being party to the data. Elements of the data exchange may utilise audio tones or signals, particularly when initiating the exchange, negotiating a data exchange protocol (which may or may not be audio) and/or as a fall-back or 'lowest common denominator' if other protocols are determined to be unavailable, unsuitable or happen to fail.

Also provided is a method of transmitting data across a telephony network, the method comprising: receiving encoded data at a decoder; decoding the encoded data into audio data using the decoder; transmitting the audio data across a telephony network to an encoder; and reconstructing the encoded data using the encoder. Also provided is apparatus for transmitting data across a telephony network, the apparatus comprising: a decoder, adapted to receive encoded data, to decode the encoded data into audio data, and to transmit the audio data across a telephony network to an encoder; and an encoder, adapted to receive the audio data, and to reconstruct the encoded data from the audio data.

The encoder and decoder may be provided separately. Either may be provided as part of a user device such as a smartphone. Further aspects of the invention may include one or more of the following: using an initialisation signal, preferably comprising an audio tone or tones to negotiate the protocol and/or path for subsequent data transmission or exchange; using an audio channel and/or protocol as a fall-back in the event of other channels and/or protocols being unavailable, unsuitable or failed; upgrading the data transmission to a channel and/or protocol with enhanced capabilities should one become available, preferably during transmission; using a masking tone or tones to suppress or prevent propagation of data, in particular data encoded as audio tones, to an entity; using a voice-optimised codec for non-voice data transmission; use of an audio transaction protocol compatible with the adaptive multi-rate (AMR) codec; use of single, muiti-tones, speech symbols or a combination of tones and speech symbols, optionally using a tone ίο expand the speech symbol; transmitting data across a telephony network, the method comprising: receiving encoded data at a decoder; decoding the encoded data into audio data using the decoder; transmitting the audio data across a telephony network to an encoder; and reconstructing the encoded data using the encoder; encoding data with a speech-coding algorithm; converting the encoded data into audio data; transmitting the audio data across a telephony network; converting the audio data into encoded data; and decoding the encoded data with the speech- coding algorithm; selecting speech encoding parameters from a master symbol set in such a way as to minimise transmission errors; • varying or adapting the symbol set used for encoding the data being transmitted dynamically in dependence on changes to the AMR codebook, preferably per sub- frame, and preferably avoiding codes determined to be unsuitable;

• performing an error check, such as a checksum, on the encoded and/or audio data; · re-encoding and/or re-decoding data in the event of an error being detected; and

• estimating encoder characteristics from spectral analysis of received audio and determination of bandwidth and characteristic frequencies, preferably averaged over a time window.

Other aspects may include methods and apparatus using an audio protocol for the provision of:

• contactless payments during a telephone call, including card-not-present;

• authentication during a telephone call, including two-factor or dual authentication; and

• remote troubleshooting and monitoring. According to another aspect of the invention there is provided apparatus for performing any of the methods herein described.

The system described may, for example, be implemented as:

• A smartphone or other user handset or device, for example an Apple iPhone running the iOS operating system or a smartphone such as provided by Samsung running the Android operating system, preferably with a trusted execution environment (which may be an area in memory, a specific subsection or enclave of the device or virtual) for storing sensitive data, adapted to run the transaction protocol and to interact with a user of the smartphone (otherwise known herein as the Caller) via a software application or app (which may also reside in the trusted execution environment); and · A media processor running software for implementing the transaction protocol and making data available for example to an Agent (interacting with the Caller) or CRM via APIs

Potential benefits may include: • More options for contact centres to securely process sensitive data (personal, payments) over the phone while preserving confidentiality and accuracy, more security for callers.

• Payments may be made faster, with better interchange rates and more securely; various existing payment methods, schemes and infrastructures may be integrated eg. contactless, Apple Pay, Google Wallet.

• ID &V (identity & verification) may be supported, eg. proving caller / called destination identity, in a mutual, non-verbal manner which is faster, more confidential - resulting in increased trust.

• Personal Data, sent from an electronic wallet or 'eWallet' or other trusted location, may be shared more effectively, faster and more accurately, with better fraud prevention.

Potential features may include:

• The ability to exchange data anywhere one can make a voice call, to send data, in real-time, in the middle of a voice call, even when there is no data channel available - and without making any changes to the world's mobile networks.

• Bi-directionality, meaning either party may initiate the process, with support for a wide variety of cryptographic techniques.

• Being integral, as in built into a telephony component of a smartphone.

• Not requiring 3G/ 4G/ Wi-Fi but instead encoding data into audio tones, acknowledging 2G will remain the dominant fall-back position for a long time, for example in some developing countries.

Potential security features and advantages may include:

• Increased agnosticism of underlying data transport, no longer relying on wi-fi or 3G.

• Application may be stored or run in the trusted area or trusted execution environment (TEE) of the smartphone.

• Storage of security certificates may be moved from app to smartphone, ie. loaded into the smartphone trust centre. The apps makes use of the trust centre to handle the authentication. Preferably, the trust centre resides in the TEE, making for a more secure solution. • Enhanced ease of obtaining security certificates, allowing them to be pushed by a third party, such as a merchant, to the user's smartphone, with acceptance by the user if the user is satisfied that they are genuine eg. connected with their bank

Potential applications and use cases may include:

Insurance Industry eg. direct services, driving licence, driving history, insurance history - increasing quality while still reducing average handling.

Reverse Authentication, for example in bank certificates, certificate stores, online provisioning - potentially using zero-app (without requiring the installation of additional software) and 2-factor implementations.

Permissioning, including the use of biometrics to authorise

Third World applications, including ID & V and authentication.

Peer-to-peer data exchange, micro-payments

Peer-to-(small) merchant

As an example of the latter, the payment for delivery of a pizza via a smartphone may not require a server side component, only a terminal at the merchant premises which has a compatible modem and an Internet connection to the PSP. Use of appropriate end-to-end (E2E) encryption may take the terminal out of PCI scope - although in practice some terminals may need to accept manually entered payment details to accommodate users or customers without compatible smartphones.

General aspects may include the following:

• Data may be sent in either direction.

• Data may be encrypted either by the internal or external components. The use of bidirectional communications means that a wide variety of cryptographic procedures are compatible, such as certificate exchange, EMV payments and others.

• The process may work with a wide variety of forms of voice communication, automatically adapting to the best available mechanism.

• There may be no dependency on a specific intervening network infrastructure for voice calls.

Further features of the invention are characterised by the dependent claims. The invention also provides a computer program and a computer program product for carrying out any of the methods described herein, and/or for embodying any of the apparatus features described herein, and a computer readable medium having stored thereon a program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

The invention also provides a signal embodying a computer program for carrying out any of the methods described herein, and/or for embodying any of the apparatus features described herein, a method of transmitting such a signal, and a computer product having an operating system which supports a computer program for carrying out the methods described herein and/or for embodying any of the apparatus features described herein.

The invention extends to methods and/or apparatus substantially as herein described with reference to the accompanying drawings.

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied apparatus aspects, and vice versa.

Equally, the invention may comprise any feature as described, whether singly or in any appropriate combination.

Furthermore, features implemented in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

The terms "initialisation signal" (or tone) and "initialisation handshake" may be used interchangeably, or either term may be used to refer to both, ie. "initialisation signal" may refer to a signal which includes an initialisation handshake or "initialisation handshake" may refer to a signal which includes an initialisation or identification signal. The invention will now be described, purely by way of example, with reference to the accompanying drawings, in which:

Figure 1 shows a transaction system;

Figure 2 shows examples of possible data paths;

Figures 3 (a) to (c) show the transaction system working with Next Generation Communication Apps [NGCA]; Figure 4 shows a further example of different data paths involved with Next Generation Communication Apps;

Figure 5 shows an example of the use of speech-coding algorithm parameters to encode data for transmission in the voice path through a telephony network; Figure 6 shows an example of a vector quantisation; and

Figures 7 (a) to (i) show an example use case: a contactless payment made during a voice call.

Overview

Figure 1 shows a transaction system 10 in which a Caller 20 uses a smartphone 30 to communicate via voice across a telephony or computer network with an Agent 40 located in a contact centre. A multi-protocol call processor (MPCP) 50 is located at the Agent end of the call (potentially, although not necessarily, within the contact centre) and provides a termination point at the contact centre for various inbound and outbound call types, relaying data to the Agent 40 via headset 42 and computer 44 as appropriate. In some embodiments, MPCP 50 is adapted to forward at least some of the data received from the Caller 20 to a third party 60, potentially without allowing this data to pass to the Agent 40.The third party may be a CRM system, which may or may not be associated with the Agent 40, or a PSP or other party independent of the Agent 40.

The MPCP 50 is adapted to handle the call in a plurality of protocols / channels - and to switch between protocols / channels as appropriate. For example, voice may be carried by various protocols including 2G, ISDN, SIP (eg. via VoLTE), 3G / 4G, or via a proprietary protocol used by a so-called new generation communication apps (NGCA) such as WeChat, Skype or WhatsApp or any similar service. At least some of these protocols / channels may also be used to transmit data from and to the smartphone 30, either as part of or in parallel to the voice call.

A particular aspect of the system 10 involves the use of an audio, preferably 2G compatible, data transaction protocol.

Initialisation signal

When data is to be exchanged during the call an easy-to-detect initialisation or identification signal (eg. an audio tone or series of tones) is transmitted from the MPCP 50 to the smartphone 30 (or vice versa, whichever is initiating the exchange). The initialisation signal serves two purposes: i) it identifies the transition into data transmission mode, ie. it flags to the receiving device to process the following audio as data (rather than to pass through as normal speech) ii) it serves as a brand identifier to users or consumers (an identifying mark may be also placed on equipment to indicate compatibility with the transaction method and the transaction protocol).

In some embodiments, an accompanying tone is transmitted whenever data is being transmitted. This tone may be used to mask or otherwise disguise data being sent via the transaction protocol. In other embodiments, the data being sent via the transaction protocol may be suppressed or otherwise prevented from reaching the Agent 30. Combinations of such masking / suppression techniques may also be used.

Initialisation handshake After transmission of the initialisation signal or tone, the MPCP 50 attempts a handshake using the transaction protocol - in audio - in order to determine the capabilities of the smartphone 30 and to determine or negotiate a data path or channel and protocol for the subsequent data transmission or exchange.

Once the determination is made, data exchange proceeds using the best available data connection channel/protocol combination. For example, 3G / 4G or Wi-Fi may be available; hence the handshake may involve exchange of IP addresses to allow the communication to proceed.

If available and of suitable quality, non-audio data transfer protocols are preferred as they cause less disturbance to the call and likely provide faster data transfer, but the audio protocol remains available as a fall-back.

Transactions are typically initiated from the Agent 40 side, but the principles apply equally to transactions initiated by the Caller 20 (with relevant aspects simply reversed and/or modified accordingly).

Data paths Various data paths may be available between smartphone 30 and MPCP 50. Even if a particular data path is identified, a further determination is usually made to assess its viability for data transfer in terms of integrity and reliability. Figure 2 shows examples of possible data paths [A] - [D] in the public switched telephone network (PSTN):

• [A] - The call enters the contact centre via ISDN, only in-band tones are used and no fall-back processing (ie. resorting to 2G) is required

• [B] - The call enters the contact centre via SIP, so it is possible that a direct end-to- end SIP path exists between smartphone 30 and MPCP 50. However, the capabilities of that path are not assured.

• [C] - It is possible that the path includes non-SIP elements.

• [D] - Or that capabilities in the path are not maintained.

To account for these various possibilities, the initialisation signal is initially sent - in audio - using the transaction protocol. If the receiving device has other data paths available (e.g. SIP MESSAGE) it will attempt to respond in the first instance using these. If this succeeds, all subsequent communication uses the enhanced path. If this fails, all subsequent communication uses the transaction protocol.

For communication initiated from the smartphone 30, the same principles apply. Even though the call may be initiated via an enhanced capabilities channel (eg. VoLTE) there is no guarantee that the route taken through the network will maintain these capabilities, as shown for example in path [D], and so the initial communication preferably uses the transaction protocol until the end-to-end functioning of the route taken can be confirmed.

Figures 3 show the transaction system working with Next Generation Communication Apps [NGCA] eg. Skype, WeChat, WhatsApp etc, which typically involve at least some data transmitted via the internet (INET).

NGCA may use gateways to improve interworking performance. Although voice-only calls will work with the transaction protocol, better performance can be obtained by including a gateway in the NGCA architecture.

Figure 3 (a) shows an example, with a smartphone 30 being used to communicate via NGCA with an Agent 30 at a contact centre (an Automatic Call Distributor or ACD 200 is shown, which relays the call to a particular agent 40): · Calls are placed from NGCA routes to an NGCA server 100 or servers. These may be core servers in the case of a centralised architecture, or edge gateways in the case of a decentralised P2P approach. • Sensitive data from smartphone 30 is encrypted by a transaction protocol component on the smartphone and sent to the NGCA app for transmission across the data path already in use for the voice portion (only as data, not voice).

• The NGCA server 100 includes a transaction protocol interworking element 1 10 which receives the data from the app, and converts it either to the transaction protocol or to an enhanced message format (e.g. SIP MESSAGE or other message, RTP event etc)

• The same principles as described above for PSTN calls apply, in that the initiating party may not assume the availability of end-to-end enhanced messaging, and so initiates using the transaction protocol, and upgrades to the enhanced capability if it proves to be available

Figure 3 (b) shows another example, where the NGCA 100 only has TDM (rather than any form of enhanced message format) interworking to the PSTN:

• In this case, the transaction protocol interworking element or modem element 1 15 (this may be implemented as part of the transaction protocol interworking element

1 10) need only support 'classic' transaction protocol tones (since enhanced messaging is, by definition, not available).

• Although an initiating entity may solicit enhanced communications using the initial transaction protocol tones, the interworking element 1 15 will simply reply immediately with a response using the transaction protocol tones (since it can never support enhanced communications)

Figure 3 (c) shows a further example, where the NGCA 100 employs a separate data connection:

• An alternative approach may be taken for NGCA servers 100 which have only TDM interworking to the PSTN. These NGCA servers may opt to employ a separate data connection to the MPCP 50.

• This means the MPCP 50 and NGCA servers need to know how to find each other, in addition to the phone call part. This may be resolved, for example, by using a directory service. · In this scenario, transaction protocol tones are sent via the audio channel simply to establish the initial communication and exchange a correlation reference. • The correlation reference is then passed across the separate data link (for example, via HTTPS across the Internet) and an end-to-end data channel is established between the handset and the contact centre, via the NGCA servers or gateways.

In all of the above scenarios, end-to-end encryption can be used to prevent the intermediate equipment being brought into regulatory scopes associated with the transmitted data (ie. the Caller does not need to trust the NGCA not to eavesdrop).

Figure 4 shows a further example of different data paths involved with Next Generation Communication Apps.

The transaction protocol Generally, the audio transaction protocol is designed to be compatible with the adaptive multi-rate (AMR) codec widely used in GSM telephone networks, in effect, use is being made of voice-optimised codecs for non-voice data transmission.

Various options may be employed for the constituent tones of the transaction protocol, including: a) single tones - These generally transit AMR well as the frequency tone shift by AMR is expected to be quite low even for low bandwidth modes. They may also be easier to detect than multi-tones as the filtering effect of the AMR deforms the spectrum significantly, which may make multi-tones difficult to detect in some circumstances. Frequencies used by DTMF are preferably avoided in order to minimise the chances of data being interpreted as DTMF by intermediate devices/gateways. b) speech symbols - A set of symbols or symbol base is generated (for example, by using specific coefficients in the AMR filter models) that is distinctive in the frequency domain to allow for reliable recovery. The size of the symbol base (number of symbols used) may be adjusted, potentially according to the AMR mode, where a larger symbol base will allow for more efficient data transmission c) combination of a) & b) - Optionally, a tone is used 'shift key' to expand the speech symbol.

Embodiments of the transaction protocol may comprise one or more of the following features: • Characterising the voice path in use to determine the encoding strategy, eg. whether it comprises a single or multiple (chained) codecs, and determining a modem symbol set

• Varying the transmission rate with channel conditions (better conditions, more data sent)

• Matching the modem symbols to the available dictionary (as defined by channel- specific conditions).

• Varying the symbol set dynamically.

• Using FEC (forward error correction) to detect errors while minimising retransmission and/or interleaved error correction codes to achieve burst error correction

• Using error detection to statistically analyse the errors to infer whether they arise out of intermittent channel disruption (eg. dropout/ squelch/ noise/ interference) or out of a change in channel characteristic (eg. change in mobile codec due to change in extent of mobile network congestion). Some symbols will be more prone to disruption than others when a channel characteristic change occurs.

• Sending optimal audio into an AMR coder

• Sending raw AMR data, chosen to produce audio at the other end and which can be carried across the remaining codec chain without too much loss.

• In some embodiments, use is made of SMS and/or USSD for the data transmission mechanisms.

A note on terminology used in this context:

• "symbol set" means a set of symbols, being synonymous in this context with a "dictionary" or a "symbol base". The specific definition of a symbol set as here is "the set of symbols believed to be successfully transmissible through the end-to-end transmission channel [based on best estimates of the available channel characteristics at that specific point in time]"

• "codebook" means "the set of code points in use by the AMR codec at any point in time". Note, this differs from the symbol set because the AMR codec may not (and almost certainly will not) be the only codec in use - the end to end transmission across phone networks can normally be expected to include other codecs as well.

Thus we have two terms, one for a specific part of the transmission (the lossiest part, the AMR codec in the mobile network), and one for the end-to-end channel. Figure 5 shows an example of the use of speech-coding algorithm parameters to encode data for transmission in the voice path through a telephony network - in this case using code-excited linear prediction (CELP).

Initially, only an audio path (supporting the phone call) can be assumed to exist. The audio which is most likely to successfully transit a CELP-constrained channel is that which itself comprises CELP parameters. The data to be sent is therefore encoded as CELP parameters and passed through a CELP decoder to produce audio data signals. These audio data signals are sent across the intermediate networks and subsequently converted back into CELP parameters and decoded into the data.

A transaction protocol modem, preferably encoded as software, is provided for the encoding / decoding of the data into / from CELP parameters.

For the path from mobile phone (smartphone 30) to server (MPCP 50), data is formatted in this case as CELP parameters at the mobile phone (whereas usually, voice is encoded into CELP parameters at the mobile phone) and transmitted (as regular data signals) across the air interface to a CELP decoder in the mobile network for subsequent transmission as audio across intermediate networks to a CELP encoder at the server, where the data, reconstructed as CELP parameters, is determined.

For the path from server (MPCP 50) to mobile phone (smartphone 30), data is formatted as CELP parameters and passed through a CELP encoder at the server, then sent as audio across the telephony network to a CELP encoder which transmits the data, reconstructed as CELP parameters to the mobile phone (whereas usually, CELP parameters received at the mobile phone are decoded into voice).

Generally, when a parameter is sent into a CELP decoder the output is sound. When this sound is in turn sent into a CELP encoder, the result will be a parameter set which should match the original. In practice, degradation will cause the wrong parameter set (especially an error signal) to be selected. Understanding the neighbourliness of parameters sets (ie. how similar, and therefore how confusable with each other, they are) then if a transmission error is detected (eg. by the checksum calculation) another attempt can be made to decode using a parameter set adjacent to the one previously determined to see if that produces a correct result.

The master symbol set comprises all possible permutations of CELP parameters (outputs from a CELP coder, including those which do not sound like human speech). This symbol set is reduced by:

• Lossiness of subsequent codecs, ie. they result in sounds which cannot be distinguished after the subsequent codec has coded them.

• Similarity of audio output to another symbol in the same set, meaning that they cannot be distinguished, even if no other intervening codecs cause information loss. Determination of the neighbourliness of parameters sets is familiar from vector quantisation techniques.

Figure 6 shows an example of a vector quantisation, showing how a vector space (in this case a two-dimensional space) may be divided into regions (termed encoding regions) such that any point in the space may be associated with a region and approximated by a representative point or dot (termed a codevector) within that region (the set of all the representative points or codevectors is termed the codebook). In the example, there are 16 regions, therefore requiring at least 4 bits to be uniquely identified; hence this is a two- dimensional, 4-bit quantisation.

Each dot on the vector quantisation diagram may be viewed as a symbol in the codebook; each region encompasses a range of sounds. The aim is to have the transmitting device emit sounds which map most closely onto specific dots. The more accurately this can be done, the fewer errors will be introduced by encoding. Conversely, if the transmitting device consistently emits sounds which are on the borders between regions there is a high probability that the coder will transmit the wrong entry from the codebook, causing a high error rate.

Preferably, when sending audio into a codec to produce a symbol, in order to achieve the most reliable encoding of the audio into the desired vector quantisation parameter set, the sound sent is that which most resembles the most unique (most distant from all others) region in the vector spacing being quantised. Where audio is sent into an encoder (as opposed to sending AMR parameters directly), the coder will be adapting the codebook it uses to encode the audio every sub-frame. Since the symbol set available to the modem is a consequence of the codebook in use, it follows that it may be necessary to track the changes in the codebook, and change the symbol set (range of input sounds) in use.

In other words, as the codebooks are adapted each sub-frame (so multiple samples), so the symbol set is modified each frame to keep step with this. The best way to encode "sample data" will change from frame to frame, depending on the data which surrounds "sample data".

For a transmitting device, transmitting sound into a third-party AMR encoder without knowing what the AMR coder characteristics are, an estimate is made of what would be an appropriate symbol set to use.

This may be achieved, for example, by considering the audio received in the reverse direction across the same link. As an approximation, it can be assumed that this audio was transmitted using the same characteristics as will be available to the transmitting device.

In this case, the transmitting device can analyse the received audio for its spectral characteristics and determine from these the bandwidth and characteristic frequencies transmitted. This will enable it to estimate the AMR coder characteristics.

[Generally, bandwidth is considered to be the range from lowest to highest transmitted frequency; however, this range may be discontinuous in a way which is characteristic of the AMR parameters. The absence or presence of certain frequency bands may signal the AMR parameter set. For example, parameter set "A" might never transmit audio in the range 40Hz-80Hz.]

Since the instantaneous signal received will be additionally constrained by the frequency characteristics of the sound originally coded, it follows that such an analysis must be averaged over a sufficiently long window of time that the analysis is not unduly coloured by the spectral characteristics of the sound originally coded.

The receiving device may make an estimate of how well-matched the symbol set and the codebook are, and report this evaluation to the transmitter to allow it to optimise its transmission.

In the case of an ultimately successful transmission of data, the receiver will have a copy of the transmitted data. This copy will have been generated by a combination of decoding the transmitted data, applying error correction techniques to regenerate data lost in transmission, applying checksum and similar checks to confirm the accuracy of the resulting data, and potentially also the result of retransmission requests for data which could not be recovered from the initial transmission.

Once the receiver has a) a correct copy of the transmitted data; and b) information about the overall error rate and specific problematic symbols, arising from its own decoding efforts, it can make its own attempt at encoding the data it has just received using its own understanding of the codebook(s) in use. By comparing this with the received codes and the errors in receiving them, it can indicate to the transmitter that certain codes are not appropriate to the channel in its current state, and should be avoided.

The consequence of a symbol set which is often changing is that the a piece of data "X" may be transmitted in more than one way, depending on the current estimation of the codebook in use. Since the codebook in use is affected by the average requirements of a number of samples (i.e. all samples comprising the subframe), it follows that the data proximal to data "X" will affect the representation of data "X".

The following table is an example from the G.722.2 ITU standard for AMR-WB:

Table i/G.722.2 ~ Bit allocation of tiie AMR-WB ceding algorithm for 28-185 frame

As this data set is sent once every 20ms this limits the data transfer to at most only 50 symbols/ second; however, these symbols can be drawn from a large set, and increasing bandwidth means they can be sent with greater clarity (more symbols, or lower error rate).

G722.2 states: "The different parameters of the encoded speech and their individual bits have unequal importance with respect to subjective quality". This means the symbol set may be reduced from the theoretical maximum, as some sets of input data to a CELP decoder may produce audio output which is hard to distinguish from an adjacent set of input data. This is especially likely to be true when lossiness from other (chained) codecs is taken into account. Use case - contactless payment

An example of the use of the transaction protocol follows.

Figures 7 (a) to (i) show an example use case: a contactless payment made during a voice call, showing (on the left) the display at the Agent computer and (on the right) the smartphone of the Caller. In the following, a voice call between the Caller and an Agent of the contact centre is in progress:

(a) Agent requests ID & Verification data from the Caller;

(b) A corresponding prompt appears on the smartphone screen. The requested fields (in this case, date of birth and postcode) are either entered by the Caller or preferably pre-filled by the app on the smartphone. The Caller approves or consents to the sending of the data.

(c) The corresponding fields are filled on the Agent screen and checked to authenticate or verify the identity of the Caller. If successful, the Agent then proceeds to fill in the payment amount and request payment. At this point, if not earlier, the initialisation signal is sent from the Agent computer to the smartphone (generally, this occurs before, or as part of, the first data exchange) and the initialisation handshake is used to determine a data path and protocol for the following data exchange, which may result in the entire exchange proceeding via the use of the transaction protocol in the audio channel. (d) The smartphone display prompts the Caller for payment. The Caller uses a 'contactless' payment card or smartcard, holding the card to the smartphone.

(e) The payment card has been read successfully and details are sent to initiate payment.

(f) Payment details appear on the Agent screen. Preferably, for security reasons, only a subset of the payment details is made visible to the Agent, the rest being masked.

(g) The Caller then authorises the payment by entering their PIN for the payment card via the smartphone, the details being sent to effect payment.

(h) A notification that the PIN is correct is displayed on the Agent screen.

(i) Payment is effected, the payment status being displayed on the Agent screen and confirmation on the Caller's smartphone. It will be appreciated that the above process describes a way of effecting a 'contactless' payment during a telephone call, potentially solely using the voice channel ie. when no dedicated data channel is available.

Security aspects Generally, especially for financial transactions, the transaction system may require the consent of the user before certain data is transmitted via the smartphone. This consent may take a number of forms, usually including the steps of authentication (determining the identity of the user) and authorisation (determining the rights or permissions of the user). User authentication and/or authorisation may be combined with the step of obtaining user consent or separate, depending on the nature of the data being exchanged. The consent step may also include an authorisation step.

Authentication may be local, for example authenticating against data stored within the phone (eg. via Apple TouchID or similar) or remote, for example authenticating against data held on an external device (e.g. smartcard, Chip and PIN payment card etc.) or an authentication server over the network via a data channel.

External devices such and/or authentication servers may be provided as part of transaction system, or not, in which case the transaction system provides a conduit for the data traffic between the authentication servers and the user handset.

Usually, only if the user has consented to the data transfer - and, if appropriate, has proved their identity and/or approved the transaction - will the data be (fully) transmitted (in some scenarios, such as with contactless payments, there may be an exchange of data between bank and smartcard before the user enters their PIN - but only when the PIN is entered does the smartcard send the authentication data).

Any of the authentication and/or authorisation processes may involve an initial handshake or exchange of preliminary data in order to set up the necessary encryption/ security for the following specific operation. For example, the smartphone may send a nonce to the server, which computes upon it (using secret data) before returning it (or data computed from it) to the smartphone. The smartphone combines this intermediate result with other data (which may be stored on the phone and/ or provided by the user), optionally in a cryptographic operation, before returning the information to the server. Use of the transaction protocol by other apps

In some embodiments, an app running on smartphone 30 may make use of the transaction protocol as a secure data channel, using it to send and/or receive (preferably encrypted) data during a call. The app may be configured with the necessary code to run the transaction protocol itself, or alternatively may make use of the transaction protocol being provided by the smartphone 30 essentially transparently. Either way, the app may be required to be registered with the smartphone 30 and/or have enabled appropriate permissions to allow the use of the transaction protocol.

Use case - remote troubleshooting In this example, a smartphone 30 sold by a mobile network provider has pre-loaded an app which responds to queries sent by the provider using the transaction protocol. This may allow the provider to troubleshoot problems, for example by querying phone settings directly, without having to guide the caller through the sometimes tortuous process of discovering the relevant settings themselves. Use case - remote and lone worker monitoring

In this example, remote monitoring data is transmitted during a phone call, for example placed to a lone worker, using the transaction protocol, back to the monitoring organisation. The data may for example be environmental data, either gathered by the handset or smartphone 30 itself or by some external component linked to the phone eg. via Bluetooth. In some embodiments, a monitoring app on the smartphone 30 is configured to automatically answer a call if the lone worker does not answer within a predetermined time, sending GPS coordinates and health telematics regarding the worker back to the central monitoring station to allow the appropriate emergency response to be co-ordinated.

Customisation In some embodiments, user interface and other presentation characteristics may be specified as data transmitted via the transaction protocol, for example during initialisation. This allows organisations to apply their own look-and-feel to the standard Ul experience without requiring an app to be present on the phone.

Complementary uses In some embodiments, the transaction protocol is used to provide complementary functionality to an existing interaction or data exchange. Typically, the user will already be engaged with an entity via a communication channel and wishes to take advantage of one of the capabilities provided by the transaction protocol on a suitably enabled device.

Example use cases include:

- 'Chip & PIN' variant A user or consumer shopping on the web needs to pay for their order. At present, this is done by the user entering the PAN (primary account number) and CVC (card verification code) numbers into a web form - which is prone to fraudulent transactions since PAN/CVC are trivially easy to copy. Instead, in this variant the merchant places an outbound call to the user's or customer's transaction protocol-enabled smartphone. The payment is requested using the transaction protocol, for example the user sees a message indicating the payment being requested. The user taps their smartcard to their smartphone, resulting payment, whether via EMV, ApplePay or other similar next generation payment methodology. In this way the merchant has been able to take payment in a 'cardholder present' way, thus achieving lower interchange rates from their bank. Essentially, the transaction protocol has been used to allow the user's or consumer's smartphone to act as a chip and PIN device for the web-based retailer.

- Two- or dual-factor authentication

A user wishes to authenticate securely, using a form of dual-factor authentication, on a web page, on a voice call, or in person when visiting a secure facility. In this variant the entity with which they wish to authenticate places an outbound call to the transaction protocol-enabled smartphone. The authentication may comprise one or more of:

• Using the smartphone NFC reader to read an object or token (eg. access card, bank card etc) which the user has in their possession

• Using the a biometric sensor (eg. iris scanner, fingerprint scanner, etc) of the smartphone to capture the user's biometric

• Using a certificate stored on the smartphone, potentially in combination with a PIN/ passcode/ biometric computation

The data obtained by the transaction protocol-enabled smartphone is then transmitted to the entity with which the user wishes to authenticate. The bidirectional capability of the transaction protocol means that the actual data exchange is not limited to a simple challenge & response, but can encompass any cryptographic technique involving multiple to-and-fro exchanges, eg. TLS.

In the complementary uses or variants described above it may be desirable for the smartphone to automatically answer the incoming call and immediately display suitable display screen. In this way, although the underlying communication still relies on a phone call, from the perspective of the user the transaction protocol-enabled smartphone behaves as a task-specific device (in the same way that a chip and PIN machine in a shop can be thought of by the user as simply a black box against which they tap their card).

It will be understood that the invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.

Reference numerals appearing in any claims are by way of illustration only and shall have no limiting effect on the scope of the claims.