WO2009040549A2

WO2009040549A2 - Receiver for digitally broadcast signals

Info

Publication number: WO2009040549A2
Application number: PCT/GB2008/003282
Authority: WO
Inventors: Pirow Englebrecht; Martin Orrell; David Tegerdine
Original assignee: British Telecommunications Public Limited Company
Priority date: 2007-09-27
Filing date: 2008-09-26
Publication date: 2009-04-02
Also published as: WO2009040549A3; GB0718904D0

Abstract

A receiver (10) for a signal conforming to a digital broadcast protocol, the receiver comprising receiver hardware (12) arranged to tune to a broadcast signal and a receiver software application (16) comprising a plurality of software components arranged to exchange control and/or signalling information with said hardware (12) and to process data derived from said broadcast signal and provided by said receiver hardware(12). The receiver further comprising interface means (14, 14a, 14b) arranged to enable one or more data streams to be provided from said receiver hardware (12) to said receiver software and to enable control and/or signalling information to be exchanged between said receiver software application (16) and said receiver hardware (12) and interface means (44) arranged to enable another additional software application (46) to access one or more data streams provided by said receiver hardware (12) and to enable said receiver software application (16) and said other additional software application (46) to exchange control and/or signalling information.

Description

RECEIVER FOR DIGITALLY BROADCAST SIGNALS

The present invention relates to a receiver for digitally broadcast signals, in particular but not exclusively to a receiver for digitally broadcast television signals which is arranged to authenticate a third-party software application to enable the software application to control one or more operations of said receiver.

Receivers for digital broadcast signals are well known in the art and can be provided integrally or as additional components in a number of different types of host devices such as mobile communications handset and set-top boxes as well as stand alone devices.

Recently, there has been a demand to enable additional services to be provided on devices which receive digitally broadcast signals. The additional services utilise one or more media types of broadcast data stream which are extracted from a digitally broadcast signal. The software applications which implement these services on the host device may be developed by a third party. A problem exists as such software applications require access to the digital broadcast data streams.

United States Patent No. US2005/0283800 entitled "Interactive Television Program Guide System That Serves As a Portal" describes a program guide program application interface between the program guide application and the non-program-guide application. The program interface can perform authentication and access rights determination functions. If, however, a program other than the program guide wishes to change a channel, the program guide application is still used to implement the channel change. The non-program guide application is not able to directly control the receiver hardware. As a result, both applications must always operate at the same time and compete for resources, which is not desirable in devices with limited memory, processing and/or power resources for example.

Thus the invention seeks to overcome the limitations of prior art digital broadcast receivers and third party software applications by providing a digital broadcast receiver which has an additional interface which enables the third party software application to directly control one or more operations of the digital broadcast receiver.

The receiver apparatus of the invention enables additional software to be installed on a host device which has not been previously authenticated for operation with the receiver and enables the additional software to authenticate itself with the receiver apparatus for controlling one or more operations of the receiver. 8 003282

The aspects of the invention are as set out below and by the accompanying independent claims and preferred embodiments are set out below and by the dependent claims.

One aspect of the invention seeks to provide a receiver for a signal conforming to a digital broadcast protocol, the receiver being supported by a host device and arranged to be controllable by an additional software application also supported by said host device, the additional software application requiring authentication to control one or more operations of the receiver in order to access one or more data streams of said signal, the receiver comprising: receiver hardware arranged to tune to a broadcast signal; a receiver software application comprising a plurality of software components arranged to exchange control and/or signalling information with said hardware and to process data derived from said broadcast signal and provided by said receiver hardware; an interface arranged to enable one or more data streams to be provided from said receiver hardware to said receiver software and to enable control and/or signalling information to be exchanged between said receiver software application and said receiver hardware; and another interface arranged to enable another additional software application to access one or more data streams provided by said receiver hardware and to enable said receiver software application and said other additional software application to exchange control and/or signalling information, wherein said other interface enables said additional software application to send control and/or signalling information to said receiver software to control one or more operations of said receiver hardware to provide said additional software application with access to a data stream of said signal over said other interface.

One aspect of the invention seeks to provide a method for controlling a receiver using an additional software application provided on a host device, the receiver comprising receiver software arranged to control the operation of receiver hardware, said receiver hardware being capable of receiving a signal conforming to a digital broadcast protocol. The additional software application requires authentication by said receiver application prior in order to control the operation of said receiver hardware and/or receive one or more data streams from a broadcast signal. The additional software application may be developed by a third party and installed on said host device subsequently to and independently of said receiver software application. The method comprises the additional software application provided on the host device generating one or more control and/or signalling messages to tune said receiver hardware to a selected signal. At least one of said one or more control and/or signalling messages provides an identifier for said additional software application and/or an identifier for said host device and/or an identifier for a user of said host device. The method further comprises: sending said one or more control and/or signalling messages through an interface to said receiver application to control the operation of said receiver hardware. The interface may be separate from the interface used by said receiver to send data streams to the host device and/or receive user input commands from said host device. The method further comprises said receiver application processing the received one or more control and/or signalling messages to extract at least one of said one or more identifiers. The receiver application then performs an authentication check to determine in dependence on one or more extracted identifiers if said additional software application is authorised to control said receiver. If said receiver software determines said additional software is authorised to provide control and/or signalling messages to control the operation of said receiver hardware, the method further comprises said receiver application processing said received one or more control and/or signalling messages. The receiver then responds to coded information and/or instructions extracted from said messages.

Another aspect of the invention seeks to provide a method for accessing a content data stream provided by a broadcast digital signal received by a receiver arranged to operate with a host device, the receiver comprising receiver hardware and receiver software. The receiver hardware is arranged to be tuned to a broadcast signal in operation. The receiver software is arranged to control operation of said receiver hardware (12). The receiver software may use an interface to receive one or more data streams including content data streams from said receiver hardware and to provide control and/or signal information to said receiver hardware and may use another additional interface to output one or more of said content data streams provided by said receiver hardware to another software application operating on said host device and additionally exchange control and/or signalling information with said other software application. The method of this aspect comprises: installing a software application on said host device; said receiver authenticating said software application using said receiver software; providing one or more control and/or signalling messages from said software application via said other additional interface to said receiver software to control one or more operations of the receiver hardware in order for said software application to selectively access one or more content data streams extracted by said receiver from said broadcast digital signal.

Another aspect of the invention seeks to provide a receiver for a signal conforming to a digital broadcast protocol, the receiver comprising: receiver hardware arranged to tune to a broadcast signal; a receiver software application comprising a plurality of software components arranged to exchange control and/or signalling information with said hardware and to process data derived from said broadcast signal and provided by said receiver hardware; interface means arranged to enable one or more data streams to be provided from said receiver hardware to said receiver software and to enable control and/or signalling information to be exchanged between said receiver software application and said receiver hardware; interface means arranged to enable another additional software application to access one or more data streams provided by said receiver hardware and to enable said receiver software application and said other additional software application to exchange control and/or signalling information.

In one embodiment said other additional software application comprises a plug-in software application installed on said receiver and sharing the operating system of said receiver.

In one embodiment said other additional software application is installed on said device after said receiver has become operational.

In one embodiment said interface means comprises: interface means arranged to enable one or more data streams to be provided from said receiver hardware to said receiver software application; and interface means to enable control and/or signalling information to be exchanged between said receiver software application and said receiver hardware.

In one embodiment said interface means comprises: first interface means arranged to enable said other additional software application to access one or more data streams provided by said receiver hardware; and second interface means to enable said receiver software and said other additional software application to exchange control and/or signalling information.

In one embodiment said interface means shares one or more physical resources with said interface means.

In one embodiment said additional software application can be launched in either background or foreground operational modes, and wherein said receiver software application controls how said additional software application is launched.

In one embodiment said additional software application can be executed in either background or foreground operational modes and wherein said additional software application determines its operational mode by retrieving a flag indicating said operational mode from the command line provided by said receiver software application.

In one embodiment said flag is set when said additional software application is installed.

In one embodiment said flag is set by said receiver software application prior to said additional software application being launched by said receiver software application.

In one embodiment said additional software application controls said receiver hardware in order to access a predetermined software channel associated with said additional software application. In one embodiment said receiver software application launches said additional software application automatically when it receives a data stream associated with said additional software application.

In one embodiment said receiver is associated with a host device and said receiver comprises means to output one or more data streams from said receiver software application and/or said additional software application to said host device.

In one embodiment said one or more data streams output comprises one or more of the following: video output; audio output; and/or text output.

In one embodiment said receiver software provides video output to said host device and said additional software application provides audio output to said host device.

In one embodiment said receiver software provides video output to said host device and said additional software application provides text output to said host device.

In one embodiment said receiver software provides video output to said host device and said additional software application provides video output to said host device.

In one embodiment said receiver software provides audio output to said host device and said additional software application provides video output to said host device.

In one embodiment said receiver software provides audio output to said host device and said additional software application provides text output to said host device.

In one embodiment said receiver software provides text output to said host device and said additional software application provides video output to said host device.

In one embodiment said receiver software provides text output to said host device and said additional software application provides audio output to said host device.

In one embodiment said receiver software provides text output to said host device and said additional software application provides text output to said host device.

In one embodiment said output streams from said additional software application and said receiver software application are rendered together prior to display on a display associated with said host device. In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform an authorisation and session key exchange message exchange.

In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform a get current tuned data request message exchange.

In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform a start stream request message exchange.

In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform a pause stream request message exchange.

In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform a continue stream request message exchange.

In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform a stop stream request message exchange.

In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform an audio control command message exchange.

In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform an audio control request message exchange.

In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform a suspend operation message exchange.

In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform a resume operation message exchange.

In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform a terminate operation message exchange.

In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform a get receiver application software status request message exchange. In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform a keepalive message exchange.

In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform a show receiver software application data message exchange.

In one embodiment said message exchange brings said receiver software application into foreground on a display to which said receiver software application and said other software application are both capable of providing output to.

In one embodiment said data brought into foreground comprises an electronic programme guide for a service broadcast digitally to said receiver over a digital broadcast communications network.

In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform a show said other software application data message exchange.

In one embodiment said message exchange brings said other software application into foreground on a display to which said receiver software application and said other software application are both capable of providing output to.

In one embodiment said interface means is arranged to enable said receiver software and said other software application to perform a generic data message exchange.

In one embodiment said received digitally broadcast signal comprises a television signal.

In one embodiment said received digitally broadcast signal comprises a radio signal.

Another aspect of the invention seeks to provide a receiver software application arranged for use in a receiver according to the first aspect.

Another aspect of the invention seeks to provide a software application arranged for use in a receiver according to the first aspect.

Another aspect seeks to provide a host device comprising a receiver according to the first aspect. Another aspect seeks to provide a communications network arranged to provide broadcast signals to a receiver as according to the first aspect.

In one embodiment, the communications network comprises means to digitally broadcast signals to a plurality of receivers according to the first aspect, whereby when each said receiver processes said received broadcast signals and decodes them a self-executing code for an additional software application is obtained which an operating system associated with said receiver software application of each said receiver is then able to install.

The additional software uses either the same operating system as the receiver or the same operating system as the host device. The receiver comprises both hardware and software components, and the additional software interfaces with the receiver software to access one or more data streams provided by the digitally broadcast signals and to exchange control and/or signalling messages with the receiver software and/or hardware. This enables third party applications to share control of the receiver hardware with the receiver software and enables third party applications to access to a digitally broadcast data stream.

The present invention seeks at least in part to provide a receiver for digitally broadcast signals comprising both hardware and software and having one or more interfaces such that a receiver software application can control both the operation of receiver hardware and at least one characteristic of an additional software application such as a third party plug-in. In addition, the interface enables one or more streams output by the receiver hardware to the receiver software to be made available to the additional software application.

Those of ordinary skill in the art will find apparent that the above aspects and accompanying independent claims can be suitably combined with each other in any appropriate manner and with any combination of appropriate preferred embodiments as set out above and by the accompanying dependent claims.

An additional software application such as a third-party "plug-in" is referred to here by the generic term "plug-in software application" or PSA. According to one embodiment of the invention, a PSA is associated with a start-up screen, referred to herein as a "splash screen", after which subsequent screens are shown with the PSA providing text and/or audio and/or video content (both still and moving images). Alternatively, the text/audio/video content stream output by the PSA may supplement the text/audio/video content stream provided by the receiver software application (RSA). This supplementary PSA derived output may be provide as an overlay or sub-set of the screen area (e.g. PSA video-on RSA video), or as additional video or text to an RSA output audio stream, or as additional audio to a RSA output text or video stream, or any other feasible combination of output from the PSA or RSA.

In some embodiments of the invention, when a PSA is launched, it always defaults to provide a "splash" screen. This occurs when a user selects the PSA to be actively launched in which case it will operate in foreground (foreground operational mode). In some embodiments, the RSA commands the PSA to launch as the PSA is associated with a particular data service. In one embodiment of this type, when the data stream associated with that service is tuned to by the receiver, the PSA automatically starts up in background mode and does not provide a "splash" screen when launched, so that the subsequent text/audio/video output provided by the PSA is perceived by a user of the device to be part of the RSA offering. In some embodiments of the invention, a PSA operates either actively in foreground or passively in background. In an alternative embodiment, a PSA can operate in both modes, according to how they are activated (i.e., actively by a user of the device or passively by the RSA tuning to a particular data stream associated with that PSA).

In one embodiment of the invention, the mode of operation of the PSA is determined by a flag on the command line which launches the PSA to indicate the type of launch mode (foreground or background). In this embodiment, the PSA immediately scans the command line when launched to determine its mode of operation. This flag can be permanently set to a particular value or it can in some embodiments be dynamically updated by the RSA.

In one embodiment the RSA is provided as a separate component to the host device, for example as an accessory product to the host device. The RSA is arranged to configure the output from the receiver hardware in to a format which provides digitally broadcast content data rendered for the video display of the host device. The content data and/or control information is transmitted to the host device either via a wired or wireless connection. An example of such a host device comprises a mobile communications device such as a mobile telephone handset and the host application receiver control is supported by a separate operating environment either within the host device or externally in the form of an accessory product such as a headset of earphone(s). In one embodiment, the control and/or content information between the headset earphone(s) and the host device can be communicated for example, by a short range wireless protocol such as Bluetooth™ and/or via a Universal Serial Bus interface attached to the host device. Other examples of host devices include any device having an appropriate communications capability, for example, a personal computer or handheld device such as a Personal Digital Assistant (PDA).

Embodiments of the invention will now be described with reference to the accompanying drawings which are by way of example only and in which: Figure 1 shows a functional block diagram of an exemplary DAB ensemble as is known in the art;

Figure 2a shows a functional block diagram of an exemplary receiver having a receiver software application according to one embodiment of the invention;

Figure 2b shows a functional block diagram of an alternative exemplary receiver having a receiver software application according to another embodiment of the invention;

Figure 3 shows the software architecture for an additional software application arranged to exchange control and signalling information via an interface with a receiver software application and to receive one or more data streams derived from receiver hardware according to an embodiment of the invention;

Figure 4a shows a message exchange for authorisation and session key exchange between a receiver software application (RSA) and an additional software application (PSA) according to an embodiment of the invention;

Figure 4b shows a tune data message service request message exchange according to an embodiment of the invention;

Figure 5 shows a start stream request message exchange according to an embodiment of the invention;

Figure 6 shows a pause stream request message exchange according to an embodiment of the invention;

Figure 7 shows a continue stream request message exchange according to an embodiment of the invention;

Figure 8 shows a stop stream request message exchange according to an embodiment of the invention;

Figure 9a shows an audio control command message exchange according to an embodiment of the invention;

Figure 9b shows an audio control request message exchange according to an embodiment of the invention; Figure 9c shows a suspend operation message exchange according to an embodiment of the invention;

Figure 9d shows a resume operation message exchange according to an embodiment of the invention;

Figure 10a shows a terminate operation message exchange according to an embodiment of the invention;

Figure 10b shows a get RSA status request message exchange according to an embodiment of the invention;

Figure 10c shows a keepalive message exchange according to an embodiment of the invention;

Figure 10d shows a show RSA data message exchange according to an embodiment of the invention;

Figure 11a shows a show PSA window according to an embodiment of the invention;

Figure 11b shows a generic data message exchange according to an embodiment of the invention;

Figure 12 shows a typical operation start message exchange sequence according to an embodiment of the invention;

Figure 13a shows a channel change operations message exchange sequence according to an embodiment of the invention;

Figure 13b shows a continuation of the channel change message exchange sequence shown in Figure 13a.

Figure 14 shows a termination operation message exchange sequence initiated by the RSA 16 according to an embodiment of the invention;

Figure 15 shows a termination operation message exchange sequence initiated by the PSA 46 according to an embodiment of the invention; and

Figure 16 shows an incoming call scenario message exchange sequence according to an embodiment of the invention. The detailed description set forth below in connection with the appended drawings is intended as a description of the presently preferred embodiments of the invention and is not intended to represent the only form in which the invention may be practiced. It is to be understood that the same or equivalent functions may be accomplished by different embodiments that are intended to be encompassed within the spirit and scope of the invention.

The terms mobile communications device and wireless device are used interchangeably to refer to electronic devices that send and received information using radio frequency communications methods. Such devices include, for example, cellular telephones, portable computers, and other hand-held devices like personal digital assistants (PDAs).

In the drawings, like numerals are used to indicate like elements throughout.

The invention will now be described with reference to the accompanying drawings. Functional equivalents to features of the invention which are apparent to those of ordinary skill in the art and/or features already known to those of ordinary skill in the art as necessary for implementing the invention may be omitted from the following description for brevity and clarity.

Figure 1 shows as an exemplary digital broadcast signal structure, a digital audio broadcast DAB ensemble DAB X comprising a number of services, Radioα, Dataβ, Videoχ, and Radioδ. Radio δ is a service comprising only an audio component. Radio α comprises both an audio component and a data component. Video χ comprises an audio component, a video component and a data component. Data β comprises two different data streams data "a" and data "b". Radio α data, Data βb, and Video χ data all share the same data sub-channel, i.e., the same data component. Different data components (Radio α data and Data β data b) share a packet mode sub-channel. Different stream mode components each have an individual sub- channel. The Multiplex Configuration Information (MCI) and Service Information provides service labels and programme type codes to a Fast Information Channel (FIC). The FlC provides information on the sizes and positions of the sub-channels in the common interleaved frame (CIF) and their respective code rates. Further information about each service, such as service label, programme type, programme number for recorder control, indications of announcements, alternative frequencies, etc., can all be provided using data channels under the DAB system. For further background information on DAB technology, the reader is referred to Digital Audio Broadcasting, Principles and Applications of Digital Radio, Edited by Wolfgang Hoe and Thomas Literacy, 2^nd Edition, Wiley, 2003, ISBN 0-470-85013-2, the contents of which are hereby incorporated by reference.

The invention provides a method for third party applications to access a digital data stream. In one embodiment, the data stream accessible is extracted from a signal comprising a plurality of data streams, for example, a audio or data or video sub-stream of a composite media-stream such as the audio, data and video sub-streams shown in the DAB Ensemble of Figure 1. In order to provide a means for an additional software application (e.g. such as a so-called "plug-in application") to access the received digital data stream, the invention provides an additional interface to the receiver software application (RSA) of a digital broadcast receiver which comprises both hardware and software components.

The digital broadcast receiver is provided on a host device, for example, a set-top box, a computer, a portable computer, or a portable communications device such as a mobile communications handset. Thus examples of host devices include any device capable of receiving communications over a wired or wireless connection and having a display capable of outputting digitally broadcast signals, for example, those which conform to the DAB standard format.

Figures 2a and 2b of the accompanying drawings provide schematic functional block diagrams of a receiver 10 according to an embodiment of the invention which is arranged to receive digitally broadcast signals. The receiver 10 comprises a hardware subsystem 12 which via one or more interfaces 14a,14b (shown as interface 14 in Figure 2aO communicates with a receiver software application subsystem (RSA) 16.

As an example of the type of digitally broadcast signals which are received by receiver 10 include television, radio, and electronic programme guide information channels encoded within a signal conforming to the DAB protocol. In one embodiment, the RSA 16 utilises one or more resources shared with the receiver hardware 12 (for example, memory, power supply, circuitry and/or CPU resources) and/or with the operating system (not shown) of the host device. In another embodiment, the RSA 16 is supported by a separate processor and operating system to that provided by the host device. The host device may comprise the receiver as an internal component providing output to its display means and/or audio means, or alternatively the receiver 10 is housed separately from the host device and the receiver connects to the host device to provide output to one or more display means and/or audio output means of the host device.

Figure 2a shows an embodiment of a receiver 10 for digitally broadcast signals according to the DAB format. In Figure 2a, the receiver hardware 12 comprises a RF front end 18, and analogue to digital converter ADC 20, a digital front end 48, an Fast-Fourier Transform (FFT) component 24, a demodulator 26, an optional de-interleaver 28 and a decoder 30 for the FIC information, for example, a convolutional or Viterbi decoder.

De-interleaver 28 enables one or more sub-channel from a DAB multiplex to be output directly by the decoder 30 to the DAB receiver software 16 via interface 14 in Figure 2a. It is possible for all sub-channels in a DAB multiplex to be output to the receiver software 16 if required, but this would generate a large processing load for the receiver software 16 which must then decode the received channels using one or more channel decoders 34. The data streams output from the channel decoders 34 go to the audio output means 36 and/or video output means 38 of the host device as shown in Figure 2a. Alternatively, if data storage means are provided by the host device, the data streams can be stored on the host device rather than immediately played.

As shown in Figure 2a, control and signalling information can be exchanged between the receiver software and hardware via interface 14 which is enables control and signalling information to be exchanged with the user interface 32. The user interface 32 provides control information which the receiver hardware 12 to tune to the appropriate ensemble and select the channel indicated by the user.

The embodiment of a receiver 10 shown in Figure 2b of the accompanying drawings has additional components in hardware to multiplex the de-interleaved channel data streams. This additional hardware comprises multiplexing means 42 which multiplexes a subset of the subchannels received in a DAB signal to which the receiver hardware 12 is tuned, and this sub-set multiplex is output to the DAB receiver software 16 via interface 14a. This enables more than one service channel to be output to the RSA 16 via an interface 14a which otherwise would only enable one service channel from a received service multiplex to be processed by the RSA 16. In the embodiment of the invention shown in Figure 2b, separate interface are provided between the receiver hardware 12 and RSA 16 for data (interface 14a) from that provided for control and/or signalling information (interface 14b). Interface 14b enables a user to generate control signals via the user interface 32 of the host device. The receiver shown in Figure 2b thus enables a plurality of sub-channels to pass through an interface designed to output only a single DAB sub-channel to the RSA 16. The RSA 16 in this embodiment performs a demultiplexing operation using a demultiplexer/router 40 prior to routing the extracted sub- channels to other components of the DAB receiver application for further processing/decoding etc, such as might be provided by decoders 34.

Although the control and/or signalling and data stream interfaces between the receiver hardware 12 and the RSA 16 are shown separately in Figure 2b and as a single component in Figure 2a, those skilled in the art will appreciate that any appropriate number and configuration of interfaces may be provided in alternative embodiments of the invention where practical.

In the embodiments of the invention shown in Figures 2a and 2b, the receiver hardware 12 and/or RSA 16 comprise components which utilise one or more resources specific to the receiver 10 and share one or more resources with the host device. Examples of such shared resources include memory resources, power resources, and processing resources (including the operating system). Alternatively, the receiver hardware 12 may be provided as a standalone module which can be launched on the host device in the form of an add-on, for example, as a USB plug-in device or as a headset or other device which connects in a wired or wireless manner to the host device.

In embodiments of the invention where resources are provided specific to the receiver hardware, the receiver hardware 12 and associated RSA 16 are supported independently from the main operating system and components of the host device. In one embodiment where the receiver 10 is implemented externally, the receiver 10 comprises a device which connects to the host device via a suitable interface, e.g. a wired connection such as one via a universal serial bus (USB) port or via a short-range wireless connection. For example, in one embodiment, the receiver hardware 12 and RSA 16 is located in a headset and interfaces with its host device (for example, a mobile phone handset and/or laptop computer), via either a wired communications link or via a short range wireless communications link such as Bluetooth™.

Although reference has been made to the above receiver hardware 12 and software 16 being implemented for a Digital Audio Broadcast (DAB) standard, those of ordinary skill in the art will be aware that the invention provides a means to control the operation mode of any appropriate PSA which requires access to a digital broadcast data stream, and thus the invention need not be limited to the specific examples of a digital broadcast signal receiver such as is shown in Figure 2a and 2b and described above.

Figures^' 2a and 2b illustrate how the receiver hardware 12 contains components sufficient to tune to a particular DAB ensemble and decode the received signal sufficiently to extract the FIC. The FIC is then provided to the DAB RSA 16. The RSA 16 is able to use this information together with appropriate control information provided by the user interface 32 (and/or the PSA (also referred to herein as the PSA, 46 - see Figure 3) to allow selected individual sub-channels to be multiplexed into a signal which can pass through interface 14/14a to the receiver software 16 for demultiplexing/routing prior to the content of the selected data stream(s) being further decoded and rendered for display by the host device 10 and/or audio output by the host device 10. In this way, the PSA application is able to receive signalling information and identify individual data streams via the FIC information inter alia, and is accordingly able to generate control information to control the receiver software and/or to select which individual channel(s) are to pass through the data interface to the receiver software for further decoding and/or via the plug- in interface 44 to the PSA 46 .

In one embodiment, the decoding processes performed by the receiver application are capable of being changed by downloading appropriate components to upgrade the RSA 16. A similar process may be used to distribute a plug-in application (PSA 16) and/or modify an existing plug- in application 46.

For example, the receiver application and/or plug-in application(s) are able to generate further signalling information to request upgrades which can be communicated using the communications capabilities of the host device. For example, in an embodiment where the host device is a mobile communications or set-top box, a request to upgrade the application and/or correct a fault can be sent over the bi-directional communications network. If sufficient request are generated and associated with particular applications and/or device identifiers, then additional code can be broadcast to the host device via the digital broadcast channel to upgrade the software of a plurality of host device receiver applications/plug-in applications.

It is also possible to distribute the code for plug-in applications via the digital broadcast network to enable distribution to a number of host devices. These signals can be decoded using the receiver software and then launched on the host devices to auto install, assuming that where required, appropriate authentication can be provided. The distribution of the code is either automatic or responsive to a request generated by a user.

In Figure 2b, the receiver hardware 12 receives sufficient control information from the user interface 32 and/or plug-in application 46 to control the operation of the DAB receiver 10 to select using the FIC for a channel determined from the MSC of a received DAB signal which sub-channel(s) should be multiplexed together by multiplexer 42 . This enables a plurality of channels to access an interface configured to only allow a single signal to cross to the DAB RSA 16. In this way, the interface 14/14a is capable of allowing a plurality of sub-channels to pass through as a multiplex to the receiver software 16 together with appropriate signalling information (extracted from the FIC) for use by the RSA 16 to selectively demultiplex and extract one or more sub-channels from the received DAB multiplex. This enables thp RSA 16 to provide control information to the receiver hardware 12 via interface 14b to select which frequency the receiver 10 needs to tune to receive a particular multiplex carrying the selected service channel. All further decoding of actual content etc can take place using the RSA 16. In Figure 2b control information received via interface 14b from the user interface 32 (and/or PSA 46 via plug-in interface 44) enables selection of a received DAB service. This control information determines which of the plurality of the subchannels already demultiplexed/deinterleaved from the received DAB signal are to be multiplexed for communication across interface 14a. The RSA 16 will then need to demultiplex the received multiplex of sub-channels and process them to determine their type in order to arrange for the channels to be appropriately routed to other components of the DAB receiver application, e.g., to DAB bearer channel decoding components and DAB EPG decoding components. In some embodiments, a plurality of decoding operations is performed on each sub-channel received by the DAB application.

Figure 3 shows a schematic diagram of the components of the software architecture associated with a digital broadcast receiver 10 which comprises receiver hardware 14 and a receiver software application (RSA) 16 according to the invention. The architecture and functionality of the RSA 16 is arranged to be reconfigurable and comprises a number of components which individually or in combination provide functionality which allows content from a received digitally broadcast channel to be displayed via the host device. Also shown in Figure 3, is an application interface (also referred to herein as a plug-in interface) RPI 44 between the digital broadcast software/hardware 16/12 and a PSA (PSA) 46. This enables the PSA 46 to access the digitally broadcast data stream(s) that the digital broadcast receiver is tuned to and/or to send control information to tune the receiver to a particular digitally broadcast channel directly. As shown in Figure 3, the interface 44 forms part of the interface provided for the RSI and the hardware but alternatively the two interfaces may be separate components.

Only one data channel and one command channel (CTRL) is shown for clarity in Figure 3 but in practice one or more data channels can be provided in addition to Dynamic Label Segment (DLS) text between the RSA 16 via the plug-in interface 14 to the PSA 46.

The command (CTRL) and the data channel(s) between the PSA 46 and the RSA 16 are provided by pipes through the local host device. The pipes take the form of any appropriate pipes for the relevant operating system of the host device such as are known in the art suitable for this purpose. The pipes provide interprocess communication and may be permanent or persist for only as long as the relevant process is running. Where a pipe is system persistent it exists beyond the life of the process (and is usually deleted when no longer used). The pipes are designed toward master/slave or client-server style communications and work in a similar manner to sockets. The operating system for the RSA 16 (which may be receiver specific or that of the host device) combines the sockets with running each process/processes which use the socket to send and receive data and a transport protocol such as the transmission control protocol (TCP) or the universal datagram protocol (UDP) to enable the processes to communicate with the remote host (or component) for a particular process.

According to one embodiment of the invention, the RSA 16 and PSA 46 establish a data channel by using UDP connections, i.e., via pipe(s) using a UDP datagram sockets and establish CTRL channel(s) by using TCP connection(s), i.e., via pipe(s) using TCP stream sockets. The use of sockets enables the client and server roles of each of the receiver and PSA to be distinguished and means there does not need to be any direct communication between the applications. The socket numbers to be used for each PSA 46 are predetermined in advance prior to the installation on any host device.

In Figure 3, the receiver software 16 controls receiver hardware 12 to selectively tune to digitally broadcast signal channels. As is well known by those of ordinary skill in the art, the channels can convey textual data as well as audio and/or video data streams, for example still images and machine and human readable text. In one embodiment, the RSA 16 is arranged to receive a multiplex of digital audio broadcast (DAB) sub-channels from receiver hardware 12, which are then demultiplexed and selectively then decoded by the RSA 16. In this way, a plurality of channels all associated with the same channel multiplex can be decoded at the same time, providing the RSA has sufficient resources. The RSA 16 is configured to enable the PSA 46 to access just one audio/video/data stream at a time via the PSA-RSA interface (also referred to as the Plugln Interface) 44 as shown in Figure 3, but as those skilled in the art will be aware, in alternative embodiments, more than one data stream may be provided. The data streams are provided to the PSA 46 fully decoded by the RSA 16 in one embodiment of the invention, but in alternative embodiments, the streams are not decoded or are only partially decoded by the RSA 16.

In one embodiment of the invention, the RSA controls the operation of a PSA by requiring the PSA to be registered and authenticated prior to providing access one or more data streams of a decoded broadcast signal. In order for the PSA 46 to interface with the RSA 16, it must undergo security checks to register and authenticate the PSA 46. In this embodiment, to enable the RSA 16 to retain some control over the use of the PSA 46, a user accesses the new service(s) and functionality provided by the PSA 46 via the user interface (Ul) 32 and screen content generated by the RSA 16. This requires the RSA 16 to be running prior to any plug-in being activated.

Once the RSA is running, new PSAs must be registered. In one embodiment, a method of registering a PSA requires the PSA to be provided in executable form, e.g., as a .EXE file, which enables the PSA 46 to self-register with RSA 16. The registration process must be performed before the PSA 46 is able to access a channel/data stream of a channel. In this embodiment, the PSA 46 provides a key unique to the host device to authenticate the plug-in. This key can be generated separately for each host device, for example, where the host device is a mobile communications handset or other device capable of establishing wireless connectivity over a mobile communications network, the key may be generated in a unique way base on the International Mobile station Equipment Identity (IMEI) code or another secure ID code associated with the device. Alternatively, or in addition to the above, the PSA 46 is authenticated using an identifier or key provided by a user and/or with the PSA 46 itself (for example, a product key).

Whilst in the above the identifier is provided by the PSA to the 46 prior to sending any control and/or signalling messages to control the operation of the RSA 16 and/or the receiver hardware 12, it is possible in alternative embodiments for at least one control and/or signalling message to have a format which includes a field within which either directly or as an extension field, an identifier can be provided to appropriately authenticate the PSA.

In one embodiment, PSA 46 is associated with a channel. The PSA is automatically launched when that particular channel is tuned to, and manually started when if a user specifically selects the plug-in to be used with another tuned to channel. Alternatively, the user can select a PSA and the PSA controls the receiver to tune it automatically to the correct channel.

Each channel is able to have up to one PSA associated with it in auto-start mode, although more than one PSA can be associated with a channel when each of the other PSAs is to be specifically selected by the user via the user interface 32. To operate in auto-start mode, the PSA 46 must be indicate this option is to be made available when installed so that an appropriate flag can be set on the command line for launching the PSA.

If such an indication is not present then the option to launch the PSA 46 in auto-start mode will not be available and the PSA 46 can only be launched by a user form the Ul of the RSA 16 or of another PSA 46. Where the auto-start mode is enabled, as soon as the user selects a channel associated with an auto-start PSA 46, the RSA 16 launches the associated PSA 46. The auto- start mode information is made available to the RSA 16 via a configuration file generated during installation of the PSA 46 (see the installation process description herein below). A PSA 46 usually automatically starts up in background mode when commanded to do so by the RSA 16. Alternatively, the RSA 16 may command the PSA 16 to automatically start up in foreground.

POWER MANAGEMENT

Where the host device requires power management, the PSA 46 will shutdown if certain criteria are met. Examples of shut-down criteria include: when no data or invalid data is being received by the PSA 46 from the RSA 16 and no user activity associated with the user interface of the PSA 46 has been detected for a predetermined period of time. This can occur, for example, when the user has tuned to a different service. In this case the PSA 46 will be suspended initially but will terminate itself after this time-out or if the transmission is invalid.

^' In one embodiment of the invention where the host device comprises a mobile communications handset, the RSA 16 forces the PSA 46 to switch to suspend mode due to an incoming or outgoing communications call (e.g. a telephone call). In this case the plug-in will be sent a suspend command message optionally accompanied by an indication of the reason, here a phone call. An example of the message exchange between the RSA 16 and the PSA 46 for such a scenario is shown schematically in Figure 16 of the accompanying drawings and described in more detail hereinbelow.

One embodiment of the invention implements a constraint on the active mode of operation of a PSA 46 (where a user specifies the PSA 46 is to launch directly) which ensures that a PSA request to tune to another channel will not be successful unless the channel requested forms part of the same multiplex as the channel the receiver is currently tuned to.

EXAMPLES OF PLUG-IN SOFTWARE APPLICATIONS (PSAs)

An example of an additional software application PSA 46 according to the invention is a music download application that will synchronise with the play-list of a music or video channel and offer a user the chance to download one or more files providing one or more songs associated with the play-list. Another example is a traffic application which a user can activate to receive the traffic news provided by the currently received radio or television channel, or the weather application. This is particularly useful where the user is tuned to a local radio or television channel. Another example of a PSA 46 is a stock ticker application which updates the display of the host device with one or more stock prices but otherwise does not disrupt the video output of the RSA 16. This information can be overlaid along the bottom of the screen showing the content associated with the currently received video and/or audio content. In one embodiment, the user can preselect to only show the data stream for certain stocks in which case the. remaining broadcast data is suppressed.

When the PSA 46 is installed it creates a hidden text file which contains the following information: a plug-in file name/identifier, e.g. a path for the executable file of the plug-in (...\PluginName.exe); the TCP port; the UDP port; one or more identifiers for the RSA 16 to use to detect the PSA's associated services during a scan phase. A configuration file is also stored by the plug-in in an appropriately named folder (e.g. a PluginName.cfg file will be stored in a "\ProgramFiles\Plugins" folder. The installation of the PSA 46 should complete before the RSA 16 is next started if the RSA 16 is to parse the configuration file for that PSA 46 and cache the • obtained data to enable access at run-time.

The identifiers the PSA 46 provides to the RSA 16 mentioned above are provided in a predetermined order to the RSA and include: a channel transport mechanism identifier (TMId); an audio or data service component type (ASCTy or DSCTy) for a particular channel such as are defined in EN 300401 section 6.3.1 ; a User Application Type (UATy) as defined in ESTI TS 101 756, section 5.10 (which can be set to a "do not care" value; a Channel Primary, which indicates if the channel is a primary and/or secondary component; a plug-in stream TMI for the plug-in; a plug-in stream ASCTy or DSCTy for the plug-in (otherwise as for the Channel); a plug-in stream UATy (otherwise as for the Channel); a plug-in stream primary (which can be set to indicate if the plug-in is the primary component, the secondary component , or if the plug-in Service must be the same as the Channel Service or if the Plug-In must be a secondary component of the Channel service).

The term channel is used in the identifiers to refers to the channel which is "actively" being played on the host device 10. The plug-in stream UATy can be set to indicate electronic program guide information, a received digital broadcast content stream (for example, to a received television channel), or to indicate X-PAD services. As an example, consider the following PSA 46 "XYZPIugln", which does not support the auto-start mode of plug-in operation: _EXE:\ProgramFiles\XYZPIugln\XYZPIugln.exe

_TCP:6002

_UDP:2006

_S-CRITERIA: 1=0,254,65534,1 ,3,254,65334,16

_AS-OPT:0

When the user selects a PSA 46 from the user interface of the RSA 16, the RSA 16 launches the PSA 46 and opens up a listening TCP port (the actual connection port to be opened is preferably determined during the installation of the PSA). When the port is opened the RSA 16 attempts to authenticate the PSA 46 (see Figure 4a described later hereinbelow). If the PSA 46 has not been registered the PSA is able to either automatically or with an appropriate level of confirmation from a user of the host device obtain a registration key via a suitable communications link (e.g. via a wired connection, or a wireless connection either long range (e.g. GPRS, GSM, WiFi, WiMax) or short-range such as Bluetooth™ (in the latter case the short-range connection should be to a suitable relay point e.g. to a device which provides access to a wired or long-range wireless network connection). Once the connection is established the PSA 46 registers with a registration server which maintains information for PSAs 46 able to be associated with the receiver. If the registration process is not successful within a predetermined cut-off time limit the PSA 46 shuts down. The authorisation key to be allocated to the PSA 46 is uniquely coupled to a specific host device and a specific version of the PSA 46. If the PSA 46 is upgraded, a new authorisation key will be required and is provided to the host device using any suitable means known in the art. For example, the PSA 46 could automatically obtain a new authorisation key by generating a request for a new authorisation key prior to installing the upgrade version on the host device. In this way, it is possible for a PSA 16 to automatically upgrade on a host device without an authorisation key needing to be manually entered. The request generated by the PSA 16 provides one or more identifier for the device, subscriber to the received service and/or plug-in service, and the PSA 16. Upgrading the receiver software does not invalidate plug-in authorisation keys.

In one embodiment of the invention, a user of the host device 10 requires a licence key to activate the PSA 16 on the device 10. If no key is available to the user, the PSA 16 shall send an invalid key to the receiver software, and the receiver software shuts the PSA 16 down and closes the port. The authorisation and/or licence keys are two examples of identifiers which can authenticate the PSA to control the receiver.

The receiver software 16 is arranged to output video content (both still and moving images) rendered for a screen accessible via the host device 10, including electronic programme guide information. The screen may be an integral part of the host device 10, or the host device 10 may provide video output to another device which provides the display screen 10. This screen is used to display the video output of the host device 10 and, for example, may be also used to receive user input in certain host devices where the screen is touch sensitive.

The RSA 16 and PSA 46 both generate video content to be rendered on-screen. In one embodiment where the PSA 46 is launched in auto-start by the RSA 16, the receiver video content remains shown on screen and the PSA 16 and PSA user interface remain in-active. The RSA 16 controls the start mode of the PSA 16 by specifying the launch mode in an appropriate way known in the art in the command line, e.g. by providing an appropriate flag such as, for example:

"S" for the "SHOW" mode (where the plug-in user interface and video content is shown on the display;

"H" for "HIDE" mode (where the plug-in user interface and video content is suppressed).

The PSA 46 immediately retrieves the command line and checks the ASCII character set contained when it is launched. If the command line contains the flag for launching in "hide" mode which suppresses the plug-in so that it operates in background (for example, if H is the flag) then, if the PSA retrieves the value 0x48 from the command line, the PSA starts silently in background (although optionally a warning icon or sound-byte may be provided). If the flag for launching in foreground is returned (for the example given above if "S" or the value 0x53 is returned by the command line), then PSA 46 will launch with a splash screen and its video content and user interface are shown in the foreground of the display.

The Plug-In interface 44 shown in Figure 3 enables the PSA 46 and RSA 16 need to exchange messages and allows the PSA to implement certain operations on one or more streams decoded by the RSA 16. The Plug-In Interface 44 provides an appropriate control interface which enables a limited number of message types to be exchanged between the RSA 16 and PSA 46 which enables the RSA 16 to control the types of operation performed by the PSA 46, whilst still enabling a high level of independence between the PSA 46 and the RSA 16. The Plug-In interface 44 also enables the PSA 46 to send control and/or signalling messages to the RSA 16 which enables the PSA 46 to control one or more operations of the receiver hardware, for example, the PSA 46 can selectively cause the receiver to tune to a particular frequency and process the received signal to extract one or more data streams which are then output to the PSA 46.

Examples of message types which can be sent by the PSA and/or RSA through interface 44 include, for example: Command message type: communications initiated by the RSA 16 to command the

PSA 46 to perform/not perform an action;

Request message type: the PSA 46 asks the RSA 16 to perform/not perform an action;

Acknowledge message type: any Command/Request message needs to be acknowledged. Acknowledge message types may provide data in response to a

Command/Request message. If no acknowledge message is generated in response to a

Command/Request message within a predetermined time period the plug-in is terminated.

Apart from the initial message requesting the session key for the PSA 46, which is unencrypted and which initiates the communication between the plug-in and the receiver software, the messages are encrypted using an appropriate encryption technique such as the extended Tiny

Encryption Algorithm (XTEA). If required, the messages can be zero padded where the encryption algorithm operates on a predetermined data length (for example, for XTEA 64-bit blocks of data). Security techniques can be also provided such are known in the art, for example, checking the length of each message and discarding any messages which deviate from this.

Examples of Command messages generated by the RSA 16 include but are not limited to: Plug- In authorisation and session key; Plug-In authorisation status; Suspend Operation; Resume Operation; Terminate Operation; Keepalive; Show Plug-In window; Generic Data; and Audio Control command.

Examples of Request messages generated by the PSA 46 include but are not limited to: Tune data service; Get current tuned data service; Start stream; Pause stream; Continue stream; Stop stream; Audio control request; Get receiver software status; and Show electronic programme guide.

Figures 4a to 16 of the accompanying drawings show in more detail the types of message exchanges which pass between the RSA 16 and a PSA 46 via the Plug-In Interface 44. Figures 4a to 16 show the roles of the RSA and PSA in the message exchange (i.e., their role as TCP master or slave or UDP server or client respectively).

Figure 4a of the accompanying drawings shows the authorisation and session key exchange for the PSA 46. The RSA 16 which is the master application controlling communications via the TCP port sends an authorisation and session key exchange request command message to the PSA 46 to retrieve the authorisation key for the PSA 46 and to set up the session key used to encrypt the TCP control channel. The PSA authorisation and session key exchange command sent by the RSA 16 to the PSA 46 itself is unencrypted. The acknowledgement message provided by the PSA 46 is encrypted using the session key. The RSA 16 then checks the authorisation key and indicates with a status word if authorisation was successful or not by generating a "Plug-In authorisation status command". All subsequent requests by the plug-in are ignored by the RSA 16 if the authorisation is unsuccessful. The PSA 46 then responds with a "Plug-In Authorisation Status Acknowledgement" which is a dummy reply encrypted using the session key.

In one embodiment of an invention, the PSA 46 sends a "tune to new data stream" request message (this message exchange is not shown in the accompanying drawings). Where the new data service forms part of the same multiplex being currently received by the RSA 16 from the receiver hardware 12, the RSA 16 simply terminates the current data stream being output to the host device (or another PSA 46) and initiates sending .the new data stream to the new PSA. If the requested data stream does not form part of a service channel in the currently received multiplex, then the RSA 16 must respond to the request message by attempting to configure the receiver hardware 12 to tune to the service requested by the PSA 46 and will only then send an acknowledgement message back to the PSA 46.

In one embodiment, the PSA 46 identifies a specific channel using identifier(s) for the channel (e.g. the channel name) and the RSA 16 processes the received identifiers to determine the data service ensemble, service and component IDs to tune to associated with the requested channel. Alternatively, the PSA 46 provides the RSA 16 with identifiers for the data service ensemble, service and component IDs for the requested data service. The RSA 16 responds with the tuned ensemble, service, component IDs and the channel name.

Figure 4b shows how the PSA 46 can request access to a data stream that is currently being received by the RSA 16. The PSA 46 generates a "get current tuned data service request" message which requests the current tuned data service ensemble, service and component IDs from the RSA 16. The RSA 16 responds with the currently tuned ensemble, service, component IDs and the channel name.

Figure 5 shows the start stream request message exchange. First the plug-in application 46 generates the request message "Start data stream request from Plug-In" which requests that the currently tuned data service is streamed over a data pipe. The RSA TCP master role component attempts to start the data stream by sending the RSA UDP server component a control message to start streaming data to the UDP client component of the PSA 46. The RSA TCP master role component then responds to the PSA TCP slave role component with a "Start data stream request reply message" and. The PSA (TCP slave) then generates a request to start the UDP client and after this has been received the DAB data stream is sent from the RSA UDP server to the PSA UDP client.

Figure 6 shows the pause stream request message exchange which only affects the UDP link as the PDA 46 needs to continue interacting via TCP. In Figure 6 , the PSA TCP slave sends a "Pause data stream request from Plug-In" message to the RSA TCP master to request that the currently running data stream is paused. The RSA 16 attempts to pause the data stream and sends a "Pause UDP server" message to the RSA UDP server. The RSA UDP server will process this request and if successful, pauses the data stream. The RSA 16 then responds with a "Pause data stream request reply from receiver software" message which is sent to the PDA 46 which details if the request has been successful or not. This request message affects the current data stream running from the RSA UDP server.

Figure 7 shows the continue stream request message exchange in which the PSA 46 sends a "continue stream request from plug-in" message to the RSA TCP master which requests that the currently paused data stream starts again. The RSA TCP master then sends a "Continue UDP Server" command to the RSA UDP server. If the RSA UDP server component successfully processes this request the data stream is resumed and sent to the PSA UDP client component. The RSA UDP server sends an acknowledgement message and/or status response message to the RSA TCP master component in one embodiment of the invention (not shown in Figure 7), after which the RSA TCP master sends a "Continue Data stream request reply from receiver application" status message to the PSA TCP slave which details if the request has been successful or not. Only paused data streams can be continued.

Figure 8 shows a stop stream request message exchange. In this message exchange, the PSA TCP slave component sends a "stop stream request from plug-in" message to the RSA TCP master to request that the currently running or paused data stream be stopped. The TCP master component of the RSA 16 then responds by attempting to stop the data stream by generating a stop RSA UDP server command which is sent to the RSA UDP server component. This is processed by the RSA UDP server to stop streaming the digitally broadcast data stream to the UDP client of the PSA 46. The RSA 16 acting as the TCP master then sends a "stop data stream request reply from receiver application" status message to the PSA TCP slave which indicates if the request was successful or not. The PSA TCP client then generates a command to stop the PSA UDP-client generating a disconnect request from the RSA UDP server component. Only running or paused data streams can be terminated in this way.

Figure 9a shows an audio control command message exchange. The RSA 16 generates a "audio control command" message which commands the PSA 46 to modify the audio levels. This is particularly useful in embodiments where the host device provides other services which may require audio output which takes priority over the digitally broadcast audio stream. For example, in an embodiment where the host device is also a communications device such as a mobile telephone handset, the communications device may control the RSA 16 to reduce audio levels when an incoming communications audio alert is to be played. Where a PSA 46 is providing audio-output to the host device, the RSA 16 needs to ensure that the audio level of the PSA 46 is also capable of being reduced when an incoming communications audio alert is to be played on the host device. The PSA 46 responds to the command message by attempting to modify the audio levels and sends a "Audio Control Command Acknowledge" status message to the RSA TCP master to indicate if the command was successful or not.

Figure 9b shows the audio control request message exchange in which the PSA TCP slave sends an audio control request message to the RSA TCP master which requests the audio levels of the host device be modified. The RSA TCP master then attempts to modify the audio levels of the device and sends an audio control request acknowledge status message to the PSA which indicates if the request was successful or not.

Figure 9c shows the suspend operation message exchange. The suspend command message is sent by the RSA TCP master to the PSA TCP slave force the PSA 46 to suspend any activities that can interfere with the RSA 16. Usually this will be due to an external event such as an incoming communications call in embodiments of the invention where the host device 10 is a communications device. The PSA 46 then acknowledges the command to suspend by entering an idle mode and responds with a suspend operation command acknowledge message. The PSA 46 remains in the idle state until a resume command is received from the receiver software application 16. If the PSA 46 does not respond to a suspend command within a predetermined period of time, the RSA 16 can use the OS of the host device 10 to terminate the plug-in.

Once suspended and in an IDLE state, the PSA 46 does not generate any pop-up windows, dialogue windows, or play audio/video content, or access a communications network (e.g. GPRS, GSM, WIFI, WIMax etc). However, even when in a suspend mode of operation, the PSA 46 still continues to interact with the receiver software application 16 via TCP, and optionally the plug-in user interface will continue to respond to user inputs.

Figure 9d shows the resume operation message exchange. In this message exchange the RSA 16 acting as the TCP master sends a resume operation command message to the PSA 46 which is currently operating in IDLE mode. This commands the PSA 46 to resume its activities. The PSA 46 acknowledges the resume command and resumes normal operation. All of the activities previously stopped (or paused) by the suspend command are restored and the PSA 46 operates in the same operation mode as it operated in before being suspended (i.e., if previously running in background it will continue to run in background).

Figure 10a shows the terminate operation message exchange. Here the RSA 16 generates a terminate command which is sent to the PSA 46. The PSA 46 acknowledges the terminal command. If the termination is due to a power constraint (i.e., power is cut-off and/or battery power is low), the PSA 16 terminates immediately. Otherwise the PSA 16 shuts down properly and terminates in an orderly way. In both cases the PSA 46 will immediately hide its video display/run in background. If no acknowledgement is received from the PSA 46, the RSA 16 will use an operating system shared with the PSA to terminate the PSA 46.

Figure 10b shows the get receiver software status request message exchange. The PSA 46 sends a status request message which requests the status of the RSA 16. The RSA 16 responses to the status request by indicating its current status. In one embodiment of the invention, the status is indicated by sending one or more status words. Examples of status words include: Idle, Tuning, Tuned, Starting stream, streaming, recording, not recording, reserved.

Figure 10c shows the keepalive message exchange. If the RSA 16 has not received any message from a PSA 46 for more than a predetermined period of time, the RSA 16 sends a keepalive command message to the PSA 46 to see if it is still responsive. The keepalive command message contains a keepalive counter value N. The PSA 46 must acknowledge the keepalive command by incrementing the keepalive counter value to N+1 and returning the value in the acknowledgement message. If the returned keepalive counter value is not N+1 , where N is the value of the counter sent by the RSA 16, the acknowledgement message is discarded by the RSA 16. In this case, when the predetermined period of time has passed, the PSA 46 is shuts down by the RSA 16.

Figure 1Od shows a master application (here the RDA) data request message exchange between the PSA 46 and the RSA 16. The PSA 46 sends a "Show RSA data Request" message to the RSA 16 via the Plug-In interface 44. As an example, the RSA data can comprise an electronic programme guide which the PSA 46 can request to bring in to foreground. In other instances, the data requested enables the previously active RSA window to be brought into foreground. In this case, in one embodiment, the PSA, RSA and host device is configured to allow the user to toggle between the RSA screen display and the PSA screen display by subsequently causing a "Show PSA data request" message to be sent by the RSA to the PSA (which is described in more detail herein below with reference to Figure 11a).

In response to the "Show RSA data" request message, the RSA 16 then attempts to bring into foreground the requested window and sends a "Show RSA Data request acknowledgement" message to the PSA 46 to indicate if the request has been successful or not.

Figure 11a shows the PSA data message exchange in which RSA 16 sends a "show PSA data command" message to the PSA 46 (this is shown in Figure 11 as a "Show PSA window" command message). This message is sent every time a user of the host device 10 wishes to return to the user interface of a PSA 46 currently running in background mode. In response, the PSA 46 attempts to bring into foreground its last accessed window and responds with a status message detailing if the command has been successful or not.

The RSA 16 is able to send various additional types of data to the PSA 46 by initiating the generic data exchange shown in Figure 11b. The RSA 16 initiates the exchange by sending a "Generic Data Message" to the PSA 46 (the TCP slave) which specifies the data type in an appropriate configuration file. The PSA 46 receiving the data sends a "Generic Data Message

Reply" message. The PSA 46 is able to discard the data received if not relevant and/or if the PSA 46 cannot utilise the information and/or understand the data format.

Figures 12 to 17 show exemplary operation scenarios for a PSA 46 according to the invention.

Figure 12 of the accompanying drawings shows the sequence of message exchanges that are associated with a typical operation start for a PSA 46 according to an embodiment of the invention. In Figure 12, the RSA TCP master role component sends an unencrypted authentication request message to the PSA TCP slave role component which is unencrypted to request the authentication key of the PSA 46 and to set up the session key. The PSA TCP slave role component then provides the authorisation key to the RSA TCP master component in a message encrypted with the session key. The RSA TCP master component then sends an encrypted Authentication status command to the PSA TCP slave component which is then acknowledged in a return message sent by the PSA TCP slave role component to the RSA TCP master role component. The PSA TCP slave then sends a "Get tuned data service" request message to the RSA TCP master to which the RSA TCP master responds with a message conveying the appropriate ensemble, service, and component ID data to the PSA TCP slave. The PSA TCP slave then sends a "Start Stream" request message to the RSA TCP master, in response to which the RSA TCP Master then sends a "Start UDP server" command to the RSA UDP server, followed by a start stream status command which is sent by the RSA TCP master to the PSA TCP slave. When the PSA TCP slave role component receives the start stream status comment it generates a "Start UDP client" request which is sent to the PSA^" UDP client role component, after which the PSA UDP client is able to receive data from the RSA UDP server. Whilst the data associated with the selected tuned data service is being sent to the PSA UDP client by the RSA UDP server, the RSA TCP master periodically generates keepalive messages which the PSA TCP slave responds to within a predetermined amount of time.

Figure 13a of the accompanying drawings shows the sequence of messages sent for a channel change operation. Firstly the RSA 16 tunes to channel "A", stream X. PSA 16 has auto-start enabled for Channel A and stream X is associated with PSA 16. The RSA 16 sends a "Start Plug-ln#1" command. The plug-in now starts up and responds with a "Get Tuned Data Service" request. The RSA 16 responds with a Get Tuned Data Service reply message which acknowledges the request and provides details of the ensemble identity (ensemblelD), the service identity (servicelD), the service component identity (componentlD), and the channel name (ChName = A).

If the user then elects to view a different channel, for example, channel B, which has no stream associated with a plug-in, the RSA 16 sends a suspend message indicating that this is due to normal operation of the host device 10 to the PSA#1 46a, to which the PSA#1 46a responds with an acknowledgement, and the PSA#1 46a enters an IDLE mode of operation. At some point the receiver tunes to Channel C, which is also associated with stream X. The RSA 16 then sends a Resume command to the PS#1 46a, which responds with a much lower latency than when the PSA 46 was first started for channel A as all the PSA#1 46a needs to do is to resume its operation and provide an appropriate acknowledgement message to the RSA 16. At some point, the user selects a different PSA#2 46b which is associated with stream Y of channel D. This causes the RSA 16 to send a terminate command to PSA#1 46a, when then acknowledges the termination command and shuts down. The RSA 16 then sends a "Start Plug-ln#2 " command to PSA 46b which then responds with a "Get tuned data service" request message. The RSA 16 then attempts to get the requested data service and responds with an appropriate acknowledgement message which provides details of the ensemble identity (ensemblelD), the service identity (servicelD), the service component identity (componentlD), and the channel name (ChName = D).

At some point the receiver is tuned to Channel A again, which is associated with stream X. This causes PSA#2 46b to be terminated, after which the RSA 16 sends a "start plug-in #1" command message to be sent to the PSA#1 46a. After the PSA#1 46a has started up , it then sends a "Get tuned data service" message to the RSA 16.

When the receiver retunes to Channel A, if the messages continue to be sent sequentially, then a very high latency will result as PSA#2 46b needs to shutdown before PSA#1 46a starts. However, it is possible in some embodiments of the invention to initiate the start-up of PSA#1 46a before PSA#2 46b has finished shutting down. This reduces the latency slightly although PSA#1 should not send a "Get tuned Data service" message to the RSA 16 until the previous PSA#2 46b has completely shut down.

Figure 13b continues the operation shown in Figure 13a. In response to the "Get tuned data service" request message sent by the PSA#1 46a to the RSA 16, the RSA 16 responds with an acknowledgement message which provides details of the ensemble identity (ensemblelD), the service identity (servicelD), the service component identity (componentlD), and the channel name (ChName = A). At some point the PSA#2 is selected again by the user, channel D is tuned to, and stream Y associated with PSA#2. This results in the RSA 16 sending a terminate command to the PSA#1 46a which then acknowledges the command and commences to shut down. The RSA 16 then sends a "Start Plugln#2" command to the PSA#2 46b, which after it has started up again responds with a "Get tuned data service" request message. The RSA 16 then provide the acknowledgement message which provides details of the ensemble identity (ensemblelD), the service identity (servicelD), the service component identity (componentlD), and the channel name (ChName = D). Finally on Figure 13b, the receiver is tuned to channel C, with which stream X is associated, which causes the RSA 16 to send a suspend command to the PSA#2 46b, which then sends an acknowledgement message before entering an IDLE mode of operation.

Figure 14 shows a message exchange sequence for a scenario when the PSA 46 terminates due to a low level of electrical power (battery low reason) or if the user exits the RSA 16 and Figure 15 shows a similar message exchange sequence when a user exits the PSA 46. In Figure 14, when the RSA 16 receives notification of a termination event, it sends a terminate command message which indicates the priority level of the termination, shown in Figure 14 by identifying the event as a "low battery" level. This priority level determines the mode of plug-in termination, i.e., whether it is to terminate immediately or whether it can close with a normal shutdown operation. The PSA TCP slave role component then sends a stop client command to the PSA UDP client role component which will continue in this example to receive data until the RSA TCP Master has sent a "Stop Server" command message to the RSA UDP server.

In Figure 15, the PSA 46 receives notification of a termination event, in this case the user exiting the PSA 16. The PSA TCP slave sends a "Stop Stream Request" message to the RSA TCP Master which responds by sending a "Stop Server" command to the RSA UDP server, which stops streaming data to the PSA UDP client. The RSA TCP Master also sends a "Stop stream status" back to the PSA TCP slave which in turn generates a "Stop Client" command to the PSA UDP client process, which then terminates. After this the PSA 46 enters an idle mode of operation and if not further activity occurs within a certain period of time, terminates (this is not shown in Figure 15).

Figure 16 shows a message exchange sequence for an embodiment of the invention where the host device comprises a mobile communications handset and an incoming communications call is received. In Figure 16, the PSA UDP client is shown schematically receiving broadcast data from the RSA UDP server whilst the RSA TCP master exchanges a keepalive message sequence as described hereinabove with the PSA TCP slave. When an incoming communications call is received by the host device 10, an alert is sent to the RSA 16 (for example, the operating system of the host device may provide an incoming communications call event message to the RSA 16), which generates a "Pause UDP server" control message which is sent to the RSA UDP server to stop sending data to the PSA UDP client. The RSA TCP Master then sends a suspend command message to the PSA TCP slave. The PSA TCP slave then sends a suspend acknowledgement message as a response to the RSA (TCP master) and then assumes an IDLE mode of operation. When the communications call ends, an appropriate mechanism informs the RSA TCP master which sends a resume command message to the PSA TCP slave, which responds with a suitable acknowledgement message. When the RSA TCP master receives an acknowledgement message which indicates the PSA is no longer in an IDLE state but has resumed its previous mode of operation, it sends a "Continue Server" command message to the UDP server so that the RSA UDP server continues to stream broadcast data to the plug-in UDP client.

The data streams output by the RSA to the PSA are processed by the PSA and then returned to the RSA via an appropriate interface to enable the data streams from the PSA to be provided by the RSA to its audio and/or video output component(s). This enables the output from the RSA and the PSA to be rendered together by the receiver prior to be provided as audio out and video out to the host device (e.g. to a headphone jack or loudspeaker subsystem and to a display screen). Alternatively, the PSA provides output directly to the audio out and/or video out of the host device. The host device may also be arranged to simultaneously receive audio and/or video data streams from the RSA and the PSA, and may be arranged to filter one or more of said streams.

In one embodiment of the invention, the PSA is arranged to implement steps in a method for controlling a receiver (10) using an additional software application (46) provided on a host device, the receiver (10) comprising receiver software (16) arranged to control the operation of receiver hardware (12), said receiver hardware (12) being capable of receiving a signal conforming to a digital broadcast protocol, the method comprising: the additional software application (46) provided on the host device generating one or more control and/or signalling messages to tune receiver hardware (12) to a selected signal, wherein at least one of said one or more control and/or signalling messages provides an identifier for said additional software application and/or an identifier for said host device and/or an identifier for a user of said host device; sending said one or more control and/or signalling messages through an interface (44) to said receiver application (16) to control the operation of said receiver hardware (12); said receiver application (16) processing the received one or more control and/or signalling messages to extract at least one of said one or more identifiers; said receiver application (16) performing an authentication check to determine in dependence on one or more extracted identifiers if said additional software application is authorised to control said receiver (10); and if said additional software (46) is authorised to provide control and/or signalling messages to control the operation of said receiver hardware(10), said receiver application (16) processing said received one or more control and/or signalling messages and responding to the instructions provided by said one or more control and/or signalling messages.

One embodiment of the invention the PSA is provided on a receiver (10) for a signal conforming to a digital broadcast protocol, the receiver (10) being supported by a host device and arranged to be controllable by the PSA. The PSA comprises an additional software application also supported by said host device. The additional software application requires authentication to control one or more operations of the receiver (10) in order to access one or more data streams of said signal. The receiver comprises: receiver hardware (12) arranged to tune to a broadcast signal; a receiver software application (16) comprising a plurality of software components arranged to exchange control and/or signalling information with said hardware (12) and to process data derived from said broadcast signal and provided by said receiver hardware(12); interface means (14, 14a, 14b ) arranged to enable one or more data streams to be provided from said receiver hardware (12) to said receiver software and to enable control and/or signalling information to be exchanged between said receiver software application (16) and said receiver hardware (12); and interface means (44) arranged to enable another additional software application (46) to access one or more data streams provided by said receiver hardware (12) and to enable said receiver software application (16) and said other additional software application (46) to exchange control and/or signalling information. The interface means (44) enables said additional software application (46) to send control and/or signalling information to said receiver software (16) to control one or more operations of said receiver (10). Examples of an operation which can be controlled include altering the level of audio output, the frequency to which the digitally broadcast signal is tuned to, and the data stream which is output to said additional software application (46).

Although the receiver software is preconfigured to accept third-party software applications according to the invention, in addition in some embodiments the receiver software can be updated with additional authentication data in order to permit the authentication of new third- party software applications requiring control access over the receiver hardware to receive selected data streams as these become available. The receiver software in such embodiments is either remotely configurable using an appropriate communications channel (for example, the broadcast signal) or it may be configured to receive additional authentication data via interface 14 from the host device. The host device receives the authentication data over a communications network from a remote source directly or indirectly (by connecting to another device such as a computer with an appropriate communications capability). By providing the receiver software with updated authentication data an additional security check is provided which seeks to prevent potentially malicious third party software applications from being authenticated and/or from performing certain functions/operations on the receiver hardware. For example, the receiver software may authenticate an application but ensure that it blocks the application from accessing data signals whose content might incur an unwanted cost for the user or provide inappropriate material to the user. As the software applications of the invention are able to access and control the receiver hardware directly, this separate control functionality needs to be provided to the receiver software.

The scope of the invention is not intended to be limited by the specific embodiments of the invention described herein above where modifications and functional equivalents are known to those of ordinary skill in the art. Instead, the spirit and scope of the invention is to be determined by the accompanying claims when properly construed using the above description.

Claims

1. A receiver (10) for a signal conforming to a digital broadcast protocol, the receiver (10) being supported by a host device and arranged to be controllable by an additional software application also supported by said host device, the additional software application (46) requiring authentication to control one or more operations of the receiver (10) in order to access one or more data streams of said signal, the receiver comprising: receiver hardware (12) arranged to tune to a broadcast signal; a receiver software application (16) comprising a plurality of software components arranged to exchange control and/or signalling information with said hardware (12) and to process data derived from said broadcast signal and provided by said receiver hardware(12); an interface (14,14a, 14b ) arranged to enable one or more data streams to be provided from said receiver hardware (12) to said receiver software and to enable control and/or signalling information to be exchanged between said receiver software application (16) and said receiver hardware (12); another interface (44) arranged to enable another additional software application (46) to access one or more data streams provided by said receiver hardware (12) and to enable said receiver software application (16) and said other additional software application (46) to exchange control and/or signalling information, wherein said other interface (44) enables said additional software application (46) to send control and/or signalling information to said receiver software (16) to control one or more operations of said receiver hardware (12) to provide said additional software application (46) with access to a data stream of said signal over said other interface (44).

2. A receiver as claimed in claim 1, wherein said additional software application selects said software channel dynamically and generates said control and/or signalling information in dependence on said selected software channel.

3. A receiver as claimed in claim 1 , wherein said additional software application is preconfigured to be associated with said selected software channel.

4. A receiver (10) as claimed in any one of claims 1 to 3, wherein said additional software application (46) comprises a plug-in software application installed on said receiver and sharing the operating system of said receiver.

5. A receiver (10) as claimed in any previous claim, wherein said interface means (44) comprises: first interface means arranged to enable said other additional software application (46) to access one or more data streams provided by said receiver hardware (12); and second interface means to enable said receiver software (16) and said other additional software application (46) to exchange control and/or signalling information.

6. A receiver (10) as claimed in any previous claim, wherein said interface means (44) shares one or more physical resources with said interface means (14,14a,14b).

7. A receiver (10) as claimed in any previous claim, wherein said additional software application (46) can be executed in either background or foreground operational modes and wherein said additional software application (46) determines its operational mode by retrieving a flag indicating said operational mode from the command line provided by said receiver software application (16).

8. A receiver (10) as claimed in any previous claim, wherein said receiver software application (16) is arranged to authenticate a control and/or signalling message provided by said additional software application (46) prior to implementing an instruction provided by a said control and/or signalling message.

9. A receiver (10) as claimed in claim 8, wherein said additional software application (46) is authenticated by providing one or more of the following types of identifier to said receiver software appliation (16) to authenticate said additional software application (16) and enable said additional software application to be authorised by said receiver (1) to control the operation of said receiver hardware (10): an identifier for said additional software application; an identifier for said host device; and/or an identifier for a user of said host device.

10. A receiver (10) as claimed in any preceding claim, wherein said receiver (10) is associated with a host device having a separate operating system from said receiver and said receiver (10) outputs multiple data streams to said host device and said receiver (10) comprises one or more data output components arranged to: provide one or more data streams from said receiver software application (16) to the host device; and provide one or more data streams from said additional software application (46) to said host device, wherein a said data stream output from said additional software application to said host device replaces a data stream of the same media type which would otherwise output from said receiver software application.

11. A receiver (10) as claimed in any one of preceding claims 1 to 9, wherein said receiver (10) is associated with a host device having a separate operating system from said receiver and said receiver (10) outputs multiple data streams to said host device and said receiver (10) comprises one or more data output components arranged to: provide one or more data streams from said receiver software application (16) to the host device; and provide one or more data streams from said additional software application (46) to said host device, wherein a said data stream output from said additional software application to said host device is in addition to a data stream of the same media type which is output from said receiver software application, whereby said both data streams of the same media type are processed by said host device.

12. A receiver (10) as claimed in claim 10, wherein said output streams of the same media type from said additional software application (46) and said receiver software application (16) are rendered together prior to being displayed on said host device.

13. A receiver as claimed in any one preceding claim, wherein said receiver software (16) is dynamically reconfigurable by said other software application (46) to enable said other software application (46) to perform one or more control and/or signalling message exchanges with said receiver software (16) via said interface (44).

14. A receiver (10) as claimed in any one of preceding claims 1 to 13, wherein said other software application (46) is installed on said host device after said receiver software (10) is operational in association with said host device, and wherein said receiver software (16) is arranged to receive one or more message requests from said other software application (46) via interface (44) taken from a group comprising one or more of the following message requests: a get current tuned data service request; a start stream request; a pause stream request; a continue stream request; a stop stream request; an audio control request; a get receiver application software (16) status request; a tune receiver request; a get data stream request; and a show receiver software application data.

15. A receiver as claimed in any one preceding claim, wherein said received digitally broadcast signal comprises a digitally broadcast television or radio signal.

16. A method for controlling a receiver (10) using an additional software application (46) provided on a host device, the receiver (10) comprising receiver software (16) arranged to control the operation of receiver hardware (12), said receiver hardware (12) being capable of receiving a signal conforming to a digital broadcast protocol, the method comprising: the additional software application (46) provided on the host device generating one or more control and/or signalling messages to tune receiver hardware (12) to a selected signal, wherein at least one of said one or more control and/or signalling messages provides an identifier for said additional software application and/or an identifier for said host device and/or an identifier for a user of said host device; sending said one or more control and/or signalling messages through an interface (44) to said receiver application (16) to control the operation of said receiver hardware (12); said receiver application (16) processing the received one or more control and/or signalling messages to extract at least one of said one or more identifiers; said receiver application (16) performing an authentication check to determine in dependence on one or more extracted identifiers if said additional software application is authorised to control said receiver (10); and if said additional software (46) is authorised to provide control and/or signalling messages to control the operation of said receiver hardware(10), said receiver application (16) processing said received one or more control and/or signalling messages and responding to the instructions provided by said one or more control and/or signalling messages.

17. A method as claimed in claim 16, further comprising: said receiver software application (16) processing data derived from said broadcast signal and provided by said receiver hardware(12); and extracting one or more data streams from said received signal in response to control and/or signalling information provided by said other software application (46).

18. A method as claimed in claim 17, further comprising: said additional software application (46) accessing said one or more extracted data streams using interface means (44).

19. A method as claimed in any one of claims 16 to 18, wherein said additional software application (46) controls said receiver hardware (16) using one or more control messages in order to access a predetermined software channel associated with said additional software application (46).

20. A method as claimed in any one of claims 16 to 18, wherein said additional software application (46) controls said receiver hardware (16) using one or more control messages in order to access a software channel dynamically associated with said additional software application (46) by a user of said host device.

21. A digital broadcast signal receiver (10) for a communications device, the receiver comprising: receiver hardware (12) arranged to tune to a broadcast signal; a receiver software application (16) comprising a plurality of software components arranged to exchange control and/or signalling information with said hardware (12) and to process data derived from said broadcast signal and provided by said receiver hardware(12); an interface (14,14a, 14b ) arranged to enable one or more data streams to be provided from said receiver hardware (12) to said receiver software and to enable control and/or signalling information to be exchanged between said receiver software application (16) and said receiver hardware (12); at least one other interface (44) arranged to enable a plurality of other additional software applications (46) to access one or more data streams provided by said receiver hardware (12) and to enable said receiver software application (16) and each of said other additional software applications (46) to exchange control and/or signalling information, wherein said at least one other interface (44) enables a plurality of said additional software applications (46) to send control and/or signalling information in parallel to said receiver software application (16), whereby said additional software applications simultaneously receive one or more data streams of said digitally broadcast signal through said at least one other interface (44).

22. A method for accessing a content data stream provided by a broadcast digital signal received by a receiver (10) arranged to operate with a host device, the receiver comprising receiver hardware (12) and receiver software (16), wherein said receiver hardware (12) is arranged to be tuned to a broadcast signal and said receiver software (16) is arranged to control operation of said receiver hardware (12), wherein said receiver software uses interface means (14,14a, 14b ) to receive one or more data streams including content data streams from said receiver hardware (12) and to provide control and/or signal information to said receiver hardware (12) and additional interface means (44) to output one or more of said content data streams provided by said receiver hardware (12) to another software application (46) operating on said host device and additionally exchange control and/or signalling information with said other software application (46), the method comprising: installing a software application (46) on said host device; said receiver (10) authenticating said software application (46) using said receiver software (12); providing one or more control and/or signalling messages from said software application (46) via said second interface (44) to said receiver software (16) to control one or more operations of the receiver hardware (12) in order for said software application (46) to selectively access one or more content data streams extracted by said receiver (10) from said broadcast digital signal.