GB2610792A - Wireless data transfer method - Google Patents

Abstract

A method of controlling a remote device wirelessly comprises: transmitting data encoded in an audio signal from an audio speaker to an audio receiver of the device, where the data encodes a software update for installation and execution on the remote device without local authorisation. The signal may encode the data using a low data transfer rate ultrasonic pulse width modulated carrier wave having a Tukey pulse envelope, which may be decoded by splitting the signal into time blocks and detecting the carrier wave in each block with the Goertzel algorithm. The pulse may have non-linear rising and falling edges, with a plateau between the edges having longer duration than the edges.

Description

Wireless data transfer method The present invention relates to methods of controlling a remote device wirelessly, and is applicable to the field of wireless telemetry.

In the past, wireless data transmission has largely been by electromagnetic radiation (EM), such as via wifi networks or Bluetooth, however there remains interest in using other wireless methods.

The US army research laboratory publication "an examination of the feasibility of ultrasonic communications links" (Tofsted et al, available at www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA522291 on 8th May 2013), discloses that in complex environments which cause interfering reflections, and without the benefit of line-ofsight transmission, a pulse width modulated audio signal can be reliably transmitted at around 1 bit per second and this may be useful for distinguishing friend from foe

in a battlefield environment.

Other uses of audio data communication have also been proposed, although few if any have been commercialised. Examples of proposed uses for audio data transfer include: 1) The use of data encoded in audio signals in a TV broadcast, which a smartphone preloaded with a suitable app could detect, to open a specified URL in the data (www.engadget.com/2012/06/13/yamaha-and-fuji-tv-make-infosound-apps accessed 21st May 2013), or 2) The use of an audio data transfer protocol to permit users of smartphones (each preloaded with a suitable app) to transfer pictures, contacts or other user data. To achieve high data transfer rates, line of sight and close proximity was required (www.computerworld.com/s/article/9217790/Sound_based_system_promises_chipl ess_NFC_now accessed 21st May 2013).

A unifying feature of these known systems is that the audio data transferred is solely of an informative nature. In the first example of the transmitted URL, the data is information only, because the destination computer device is pre-programmed to receive the URL data and to act on it in a predetermined manner. Similarly in the second example, the transfer of pictures and contacts between phones, is a transfer of information only.

In contrast, the inventor proposes that the audio transmitted data could encode a 'software update' that changes the way that the receiving computer device (2) operates. The inventor further proposes that the receiving device (2) loads and executes the received data as computer code without any instruction from any other party (i.e. without confirmation from a human operator in control of the receiving device).

According to a first aspect of the invention there is provided a method of wirelessly controlling a computerised device, the method having the steps of: Positioning an audio speaker of a transmitting device (1) in proximity to an audio enabled computerised receiving device (2), Controlling the audio speaker to transmit an audio signal (3) having encoded therein a data code, according to an audio data transfer protocol, Receiving the aucio signal (3) with an audio receiver of the computerised receiving device, Extracting the encoded data code from the received audio signal (3) and storing the data code in the computerised receiving device, Wherein The data code comprises one or more of: a new executable computer program; code suited for substitution and/or addition into a computer program present on the computerised receiving device along with insertion location data for generating a new executable computer program, or instructions to modify a computer program present on the computerised receiving device for generating a new executable computer program: The computerised receiving device (2) is configured to interpret the extracted data code to generate and store a new executable computer program, The computerised receiving device (2) is configured to accept the data code, an authorisation code provided therewith, or the selected audio data transfer protocol used, as authorisation to execute the data code as an executable computer program, and The computerised receiving device (2) is configured to execute the new executable computer program with and on the computerised receiving device (2) without local authorisation.

This has the advantage that software can be updated on devices where it would be otherwise difficult to do so.

The term 'software update' includes addition of a new software program as well as modification of a pre-existing software program or operating system.

To prevent unauthorised modification or installation of computer code, an authorisation code or other authorisation security provision or protocol may be required from the transmitter (1) too, and this is typically included within the transmitted message immediately before or after the executable code. However in some situations where tampering is not a concern, such authorisation may not be needed (e.g. within a secure site, and/or where the transmission protocol is kept confidential and thus is only known to the authorised transmitting party/ies).

Data transfer systems can be categorised into two types: 1) Those where one party owns both devices, or where there is a trust relationship, typically supported by an end-user licence agreement (e.g. between a PC user and Microsoft Inc).

In these systems software updates are easy to implement using an internet connection (e.g. via wireless router, or via GPRS). The skilled reader has no motivation to seek alternatives to electromagnetic radiation so it is not obvious that it could be advantageous to use audio to transfer a software update.

2) Those wherethe two devices have different ownership.

In these systems the owner of the receiver may have a reason to use audio data transfer. Examples including: A. where a smartphone user wants to use an app to receive files, but where the smartphone does not allow apps to access the smartphone's wifi and Bluetooth connections for security reasons.

B. where the user might want their smartphone to show them information or weblinks encoded in a TV advert, and where EM data transmission is not possible from the TV.

C. where the user might want to identify a person in a battlefield as a friend or foe, and where EM transmission might cause a security risk to the user.

However in these situations, because there is no contractual relationship and trust between the sender and receiver it would not be desirable to receive software updates as this would present a security risk, and so it is not obvious to the skilled reader that it could be advantageous to do so.

The inventor has identified that there are situations where it may be useful to transmit a software update by audio data transfer, and these (non-exhaustively) include modifying the behaviour of: An electromagnetic signal jamming device, in regard to the method it should employ when designing its jamming signals, A sensor, in regard to how it should pre-process or bucket sensor data before transmitting it (e.g. from within an environment that is not conducive to the transmission of EM signals, such as a reactor, bulkhead, pipeline or a steel bridge), A robot, in regard to how it should respond to varying loads, conditions or requirements (e.g. a robotic coupling or grappling arm on a ship, salvage pontoon or reactor).

In the above examples a main reason why transmission of software updates by audio data transfer is beneficial compared to by EM transmission is that in these situations the EM transmission would be blocked en route, however there may be other reasons to avoid using EM signals including to avoid detection of the transmission (such as on the battlefield).

Other locations where audio data transfer of software updates might be valuable include: In a munitions magazine or fuel depot, where EM signals might create a risk of causing a spark and thus an explosion, In a secure office environment, where EM wireless signals are forbidden, In a battlefield, where EM jamming prevents use of EM wireless signals, In an EM emissions testing laboratory, where EM signals other than those relevant to ongoing tests should be avoided.

In some situations the audio data transfer can be completed from close proximity and/or with line-of-sight transfer, however in other situations this may not be possible. The inventor has further inventively identified that in some situations low data rate audio transfer is not only tolerable but can be preferable to the alternatives available.

The audio data transfer of a software update at low data rates may beneficially utilise data compression techniques such as the transfer of a one or more small portions of substitute and/or addition code along with a location to substitute and/or add the portion(s) into pre-existing code at the receiver device (2).

The inventors have identified that data rates in the region of 1 byte per second can be useful in transferring a software update in certain situations.

It is known that audio data transfer can beneficially rely on frequencies above 18kHz, as this is inaudible to most people (and at slightly higher frequencies, all people) and thus does not cause annoyance, and accordingly the inventors propose that the use of ultrasonic signals will usually be preferable.

Tofsted et al have further proposed a pulse modulation scheme using a sinusoidal pulse envelope to mitigate the problem that the pulses can create audible clicks.

Alternative envelope designs are possible and the inventors have identified that an s-curve-edged, plateaued-top waveform is a good compromise between the need to make the pulses inaudible and the need to ensure the pulses are easy to detect reliably, for example by a digital algorithm despite low signal strength, and without recourse to complex or resource intensive algorithms. In particular the inventors have proposed a tapered cosine window or a Tukey window as suitable waveforms for the pulses. A waveform having a plateaued-top that is long in duration compared to the tapered/s-curved edges is beneficial because to a digital system this does not appear very different from a square (i.e. digital) pulse, and as a result it is easy for a digital system to detect the length of the pulse.

The inventor has identified that the pulse lengths are beneficially limited to a small number of well differentiated discrete lengths (preferably two, defining a 0 and a 1) that differ by an amount greater than the delay (D) expected to be present in any echo interference. Similarly the receiver device (2) can beneficially quantise the incoming signal into time blocks of a duration comparable to or greater than the delay D, with the typical result that identification of the presence or not of the signal in each time block is sufficient to determine the length of each pulse and thus decode the message.

This arrangement has the benefit that it is only necessary to identify the presence or absence of the signal in each time block, and as a result it is possible to utilise an algorithm that does not require a great deal of processor power. The inventor has identified that the Goertzel algorithm can be beneficially used to minimise the processing power required by the receiver device (2).

According to one embodiment of the invention the audio signal (3) is a pulse modulated ultrasonic carrier wave where the pulses are provided with non-linear rising and falling edges.

Optionally the receiver device (2) receives an incoming audio signal (3) on a continuous basis and discards the processed data until a predetermined code (e.g. "STX") is detected in the processed data stream. Similarly, once an end of message signal is received (e.g. "EOT") the receiver device (2) reverts to discarding processed data.

One difference between the prior art systems and the present invention is that on receipt of a message (or part of a message identified as new computer code) the receiver device loads the new computer code (or replaces current computer code with it) to form a computer program and then executes that program (compiling it first if necessary). A computer program can be distinguished from data (that can be used by code) by several characteristics. Firstly a computer program is generally bounded by start and stop delineation symbols which denote the code to be executed. Secondly a computer program is written in a programming language.

Thirdly a computer program generally contains a variety of different instructions such as conditional statements and loops. Fourthly a computer program, once activated, can generally cause a computer to undertake multiple actions (and a wide variety of actions) without needing authorisation from a user. By contrast a web address is not a computer program because it is not an instruction. For the receipt of a web address to be automatically actioned (as if it was an instruction to open a web page) a computer program must have been pre-installed and configured to identify that a web address has been received and to automatically open the relevant web page.

The techniques described herein can be advantageously used for covert operations such as military or law enforcement surveillance. The technique is useful because new and useful covert software techniques (e.g. for evading virus scanners, or for transmitting data covertly) may be developed after software code has been successfully installed on a target PC or other device, and the described method permits the covert software to be updated to perform new tasks.

According to a preferred embodiment of the invention there is provided the step of splitting the received audio signal (3) into at least five time-blocks per data bit.

To free up computer resources between messages, the signal may begin with a long, easily identified signal (e.g. a continuous note ten or more seconds long), so that the receiver device (2) only needs to analyse a short (e.g. 0.02 second) audio sample occasionally (e.g. every 5 seconds).

Optionally the receiver device (2) may be configured to also transmit data (typically information rather than a software update) back to the transmitting device (1) using methods described herein. Such return signals may be in response to an 'end of message' transmission from the transmitting device (1) or at predetermined times or intervals. Generally the two devices should be prevented from transmitting at the same time (or else, at the same carrier frequency).

Where return of audio signals is not possible (e.g. the device lacks powerful enough speakers), other transfer modes can be used. Examples include: 1. Where the device is a PC it could vary screen brightness to get data out of a building. 2. Where a user is Able to get close to the target PC but does not wish to connect a cable, or where the user has line of sight to the PC via a window, the PC could transmit data via its screen, to be received by the user's video camera (optionally at high data rates via time-varying OR codes, or at low data rates via stlibtle changes in brightness via variation in device RF leakage). 3. Where the PC is in an unoccupied room but not visible from the window, it could vary its screen brightness such that at night the overall brightness of the room can be monitored from a distance. 4.11 the device is one which produces unintentional/leakage RF signals, a example of a device with strong RF leakage is a cathode ray monitor then the PC can vary its main or peripheral power use such that variation in the strength of the RF leakage encodes the data.

The transmission of an audio signal encoding data is intended to include indirect methods of causing an audio signal to arrive at the receiving device including: 1. causing a remote networked computer that is near to the receiving device to emit the audio signal via it's speakers, 2: broadcasting the signal through a distributed broadcast system such as a tannoy system or by modifying or interfering with a commercial TV or radio signal, or 3: transmitting a laser beam through a window onto a surface in a room where the receiving device is located to cause local heating of that surface, at a high frequency such that the time-varying local heating causes local emission of sound waves encoding the data, 4. Transmitting the audio signal through the infrastructure of a building such that it can be detected in rooms within thbt building, e.g. via infrasound.

However the audio signal is preferably transmitted from an audio speaker and preferably is transmitted through the air from the speaker and the signal is preferably received by a microphone of the receiving device, such as an integrated microphone, and in particular the transmission of the audio signal is by transmission of sound waves through a bulk medium such as air. Furthermore the whole software update receiving and installation process is preferably performed without local authorisation.

According to a second aspect of the invention there is provided a wireless data transmitter for wirelessly controlling a computerised device, having: data storage means for at least one of a data code or an audio signal having a data code encoded therein, audio data transmission means, and transmission activation means, The wireless data transmitter being adapted to transmit an audio signal having a data code encoded therein, according to an audio data transfer protocol, Wherein The data code comprises one or more of: an executable computer program; code suited for substitution and/or addition into a computer program known to be present on a target computerised receiving device along with insertion location data for generating a new executable computer program from the known computer program; or instructions to modify a computer program known to be present on a target computerised receiving device for generating a new executable computer program from the known computer program, And, at least one of the data code, an authorisation code provided therewith, or the selected data transfer protocol comprises an authorisation for the computerised receiving device to execute the new executable computer program thereon without local authorisation.

A transmitter loaded with such a code enables uploading of a software update to a remote computer in a manner which overcomes some of the problems inherent in the prior art approaches.

According to a third aspect of the invention there is provided a computer program adapted to control a computer (2) to receive and install a software update from a software update provider, Wherein, The computer program is adapted to control the computer to: read an audio signal (3) from an audio receiver of the computer, extract an encoded data code from the received audio signal and store the data code in the computer, Determine that the data code comprises one or more of: a new executable computer program; code suited for substitution and/or addition into a computer program present on the computerised receiving device along with insertion location data for generating a new executable computer program, or instructions to modify a computer program present on the computerised receiving device for generating a new executable computer program, Interpret the extracted data code to generate and store a new executable computer program, Accept the data code, an authorisation code provided therewith, or the selected audio data transfer protocol used, as authorisation to execute the data code as an executable computer program, and Execute the new executable computer program with and on the computerised receiving device (2) and without local authorisation.

Such a computer program beneficially allows a computer to be updated without recourse to the use of electromagnetic signals.

A preferred embodiment of the present invention will now be described in detail with reference to the accompanying diagrams in which: Figure 1 is a diagram of a transmitting device and a receiving device according to an* 20 embodiment of the invention, Figure 2 shows two interacting flow diagrams illustrating an embodiment of the invention, Figure 3 is a time-line diagram of a transmitted signal showing PWM Encoding of the ASCII Character 'A', and highlighting bits 2 and 4 according to one embodiment of the invention, and Figure 4 is a detailed view of a secticn of figure 3 showing the identification of a Obit and a 1-bit from PWM-Encoded Data using the Goertzel algorithm. ;Detailed description ;Referring to figure 1, a transmitting device (1) is placed in proximity to a receiving device (2) such that an audio signal (3) can be transmitted between them. One suitable method is disclosed in Tofset et al referenced above. ;Figure 2 shows a pair of flow diagrams illustrating a method of transferring a software update via an audio signal. The transmitting device (left hand flow diagram) is provided with a software update code which may be pre-encoded into an audio signal or else the transmitting device encodes the software update into an audio signal. The audio signal is transmitted, typically beginning with a 'start of message' symbol and ending with an 'end of message' symbol, which might include a special character, or might be a predetermined sequence of conventional characters. ;The receiving device listens continuously for the audio signal and typically only begins to record data once a 'start of message' symbol is identified, continuing to build up a text file of the message until an 'end of message' character is identified. ;Typically the receiving device checks for errors, particularly using checksum data for each byte. Optionally additional error checking techniques may be applied to larger sections of the message, or to the whole message. Techniques allowing error correction may also be used, such as data redundancy or even wholesale repetition of the message. ;If the message is free of errors, the receiving device interprets the message as either a computer program, or a software update for modifying a computer program. In the case of a new computer program the receiving device loads and executes the computer program (compiling it first if it is source code), and in the case of a software update the receiving device updates software present thereon accordingly. ;After receipt of a message (and either while or after installing the software update), the receiving device resumes listening for an audio signal (unless the software update controls the receiving device to do otherwise). ;Transmitting device program ("Encoder") The source program is an executable whose purpose is to convert American Standard Code for Information Interchange (ASCII)-encoded text files that contain the source code of scripts written using a scripting language into Pulse Width Modulation (PWM)-encoded data; this is output to binary files that conform to the canonical Waveform Audio File Format (WAVE) standard, and that can be played back through the source device's speakers using commonly available audio programs such as Microsoft® Windows Media Player. ;Note that while all 95 printable ASCII characters are supported, only a subset of the 33 control characters is supported by the source program, and therefore, by implication, by the target program. The subset of control characters that is supported in one embodiment is listed below. ;Character Meaning Decimal Hexadecimal Binary STX Start of Text 2 0x02 0 000 0010 ETX End of Text 3 0x03 1 000 0011 EOT End Of Transmission 4 0x04 0 000 0100 LF Line Feed 10 Ox0A 1 000 1010 CR Carriage Return 13 Ox0D 0 000 1101 CAN Cancel 24 Ox18 1 001 1000 Each character in the input file is converted to its Big Endian (BE) 7-bit representation, and padded (on the left) to 8 bits by the addition of an even parity bit for simple error correction purposes. For example, the character 'A' (decimal 65, hexadecimal 0x41) is represented as binary 11000001. Each bit is then PWMencoded by allocating a fixed period of time to it and then using a different ratio of sound-to-silence (or "on-duty" to "off-duty") data points in order to represent 0-and 1-bits. One embodiment uses 0.125 (i.e. one eighth) of a second as the fixed time period, and 40% and 80% (i.e. 0.05 and 0.1 seconds) on-duty periods for 0-and 1-bits respectively. This corresponds to a data rate of 8 baud (i.e. eight bits, or one ASCII character per second). ;The audio sampling rate in this embodiment is 96 kHz, yielding 96,000 data points per ASCII character, or 12,000 data points per bit. Using the 40% and 80% ratios above, this corresponds to 4,800 on-duty and 7,200 off-duty data points for a 0-bit, and 9,600 on-duty and 2,400 off-duty data points for a 1-bit as shown in figure 3. ;Each data point is stored in the output WAVE file as a 16-bit value in the range -32,768 to +32,767 (i.e. a signed short integer). The value used to represent an off-duty (i.e. silence) data point is 0 (zero). The value used to represent each on-duty data point is calculated according to the basic sine wave formula, expressed as a function of time (t), thus: y(t) = A -sin(2nft + cp) Where A, the amplitude, is the peak deviation of the function from zero, f, the frequency, is the number of oscillations that occur per second of time, and cp, the phase, specifies where in its cycle the oscillation is at t = 0. The following values were found to be suitable: A = 32,767.f = 18,000. 9 = 0 The resulting sinusoidal waveform is then multiplied by a windowing function; in this case a Tapered Cosine Window, or Tukey Window. The mathematics associated with windowing functions will be understood by the skilled person, however, it is sufficient to note that the purpose of applying the Tukey Window to the waveform data is to condition it in such a way that it reduces anomalies that would degrade the ability of the program running on the target device to analyse it. ;Receiver device program ("Decoder') The entry point into the decoder both drives the program and facilitates interaction with the target system's microphone; its primary function is to populate a byte array with the raw audio data received from this device. This is integrated with the bulk (-80%) of the program, which is responsible for concatenating pairs of bytes into an array of short integers, and finally invoking the core code on the array of shorts. These shorts are, barring any transmission errors, essentially the same values as those stored in the source program's output WAVE file. ;The core code is responsible for processing the audio data array received, and for managing a character buffer that is passed to an embedded scripting language for execution. ;The method by which it fulfils these responsibilities is by applying an implementation of the basic Goertzel algorithm (a digital signal processing technique that provides a means of efficiently detecting tones of a specific, user-defined frequency) to the data points received. This algorithm, which the skilled person can readily look up and understand, scans'a block of N shorts from the array and produces a floating point value (magnitude) that increases in the presence of data corresponding to a specific frequency in the block. ;The block size, N, can be one fifth of the number of data points per bit, as encoded by the source program (12,000 / 5 = 2,400), meaning that the algorithm is invoked five times for every bit. If four (or, allowing for transmission errors, three) consecutive invocations result in a value that exceeds a specific threshold, followed by at least one invocation that results in a value that fails beneath it, a 1-bit is recorded. Similarly, if only either one or two invocations of the algorithm result in.a value that exceeds a specific threshold, a 0-bit is recorded. An example showing the output of a signal detector rising and falling to identify a 0-bit and a 1-bit is shown in Figure 4. ;Upon successful receipt of eight bits, the pattern is checked against the bit pattern of the subset of ASCII characters that is supported in order to determine whether a valid character has been received. ;The operation of the decoder is such that, until at least one STX character has been received, no action is taken; the bits are simply discarded. Once this condition has been met, if one of the 95 printable characters, or a CR or LF control character, is matched, it is appended to a dynamically allocated character buffer that is managed by the decoder. Alternatively, upon receipt of a CAN control character, the character buffer is cleared and reset to its initial, default size. Upon receipt of an ETX control character, an embedded scripting language engine is instantiated, directed to evaluate the contents of the character buffer, and then destroyed. Upon receipt of* an EOT control character, the functionality of ETX is first invoked, and then the decoder is terminated. All other characters are simply discarded.

Claims (7)

1. CLAIMS1. A method of wirelessly. controlling a computerised device, the method having the steps of: Positioning an audio speaker of a transmitting device (1) in proximity to an audio enabled computerised receiving device (2), Controlling the audio speaker to transmit an audio signal (3) having encoded therein a data code, according to an audio data transfer protocol, Receiving the audio signal (3) with an audio receiver of the computerised receiving device, Extracting the encoded data code from the received audio signal (3) and storing the data code in the computerised receiving device, Wherein The data code comprises one or more of: a new executable computer program; code suited for substitution and/or addition into a computer program present on the computerised receiving device along with insertion location data for generating a new executable computer program, or instructions to modify a computer program present on the computerised receiving device for generating a new executable computer program, The computerised receiving device (2) is configured to interpret the extracted data code to generate and store a new executable computer program, The computerised receiving device (2) is configured to accept the data code, an authorisation code provided therewith, or the selected audio data transfer protocol used, as authorisation to execute the data code as an executable computer program, and The computerised receiving device (2) is configured to execute the new executable computer program with and on the computerised receiving device (2) without local authorisation.
2. 2. The method of claim [wherein the audio signal (3) is a pulse modulated ultrasonic carrier wave where the pulses are provided with non-linear rising and falling edges.
3. 3. The method of claim 2 where each pulse is provided with a plateau between respective non-linear rising and falling edges, the plateau having a longer duration than the respective edges.
4. 4. The method of any of the previous claims wherein the audio signal (3) is pulse modulated utilising an ultrasonic carrier wave having substantially a single carrier frequency, and wherein the step of extracting the encoded data has the following steps: Splitting the received audio signal (3) into time blocks smaller than a differenceiin duration of the pulses in the audio signal (3), and Identifying the presence or otherwise of the substantially single carrier frequency within each of the time blocks of the audio signal, And wherein: The step of identifying the presence or otherwise of the substantially single carrier frequency is performed using an implementation of the basic Goertzel algorithm.
5. S. The method of claim 4 where in the step of splitting the received audio signal (3) there are at least five time-blocks per data bit.
6. 6. A wireless data transmitter for wirelessly controlling a computerised device, having: data storage means for at least one of a data code or an audio signal having a data code encoded therein, audio data transmission means, and transmission activation means, The wireless data transmitter being adapted to transmit an audio signal having a data code encoded therein, according to an audio data transfer protocol, Wherein The data code comprises one or more of: an executable computer program; code suited for substitution and/or addition into a computer program known to be present on a target computerised receiving device along with insertion location data for generating a new executable computer program from the known computer program; or instructions to modify a computer program known to be present on a target computerised receiving device for generating a new executable computer program from the known computer program.And, at least one of the data code, an authorisation code provided therewith, or the selected data transfer protocol comprises an authorisation for the computerised receiving device to execute the new executable computer program thereon without local authorisation.
7. 7. A computer program adapted to control a computer (2) to receive and install a software update from a software update provider, Wherein, The computer program is adapted to control the computer to: read an audio signal (3) from an audio receiver of the computer, extract an encoded data code from the received audio signal and store the data code in the computer, Determine that the data code comprises one or more of: a new executable computer program; code suited for substitution and/or addition into a computer program present on the computerised receiving device along with insertion location data for generating a new executable computer program, or instructions to modify a computer program present on the computerised receiving device for generating a new executable computer program, Interpret the extracted data code to generate and store a new executable computer program, Accept the data code, an authorisation code provided therewith, or the selected audio data transfer protocol used, as authorisation to execute the data code as an executable computer program, and Execute the new executable computer program with and on the computerised receiving device (2) and without local authorisation. * 14