GB2390459A

GB2390459A - Interactive digital television

Info

Publication number: GB2390459A
Application number: GB0312651A
Authority: GB
Inventors: Neil Cashman; Walter Perotto; Alexander John James Miller
Original assignee: GOINTERACTTV Ltd
Current assignee: GOINTERACTTV Ltd
Priority date: 2002-05-31
Filing date: 2003-06-02
Publication date: 2004-01-07
Also published as: GB0312651D0

Abstract

Digital television audio / video content and interactive content are transmitted to a receiver (53, 54). A viewer makes a response to the interactive content and response data from a number of viewers is routed to interaction data processing means (58) for processing. The interaction data processing means (58) is part of an interaction management system which is capable of receiving and processing (a) response data from a range of different interactive applications and / or (b) response data from interactive applications programmed on a range of different software platforms. The interaction management system has an application programming interface and the response data from different interactive applications and interactive applications programmed on different software platforms is compatible with the application programming interface. The response data representing a particular response to a particular interactive application includes an identifier which identifies the particular interactive application to the interaction management system so that at least part of the response data is routed to be processed in accordance with criteria stored in the interaction management system relating to the particular interactive applications. Processed response data in respect of the particular interactive application is provided to a party (51) associated with the particular interactive application.

Description

Interactive Digital Television Systems 5 This invention relates to digital

interactive television.

Interactive applications for digital television are becoming increasingly popular. Por example, a shopping programme may allow viewers to order and pay for items displayed on the programme, whilst a survey may give viewers options to vote for.

10 Typically, the programrne and the interactive content are broadcast to a viewer's home, where the interactive content is decoded by a set top box (STB) connected to a television. To forward a viewers inputs, typically made by keystrokes on a remote control for the STB, the STB may be connected to a conventional telephone line via a modem, or in the case of cable television the inputs may be transmitted along cable 15 provided by the cable service provider.

There is more than one digital television service provider. For example, in the United Kingdom there are cable service providers, a terrestrial digital television provider and a satellite digital television provider. These use different programming 20 languages for interactive content and their STB's are accordingly different.

Programmes which are broadcast by digital television service providers come from a number of sources. In some cases, the service providers themselves may be responsible for some channels, but a service provider will often provide channels to 25 other service providers. In other cases, third party broadcasters may provide channels for the digital service providers to disseminate. If interactive content is provided on a channel controlled by one digital television service provider, then it may be accessible only to subscribers to that service providers. The interactive content will be incompatible with the STB's used by subscribers to other service subscribers. If a 30 third party broadcaster wants to provide interactive content, then it may be necessary to select a digital television service provider or to have the interactive content written in a number of programming languages so as to be compatible with other STB's.

À 1 With the increased ease of producing interactive applications and providing them for different platforms, there is the likelihood that there will be a greater use of interactive applications which can operate effectively across multiple platforms.

5 Viewers will come to expect the same interactive functionality irrespective of the digital television service provider and the functions of their own STB's. For programme content providers, this increases the need to deal with the interactive responses. These may come from different STB's with different software platforms, and via a number oftransmission routes. The interactive responses have to be 10 captured, stored and analysed. The viewer may need to be identified, checks made for multiple responses if for example votes are being counted, and so forth.

Viewed from one aspect, the present invention provides a system for monitoring interactive viewer responses to interactive television content, in which digital 15 television audio / video content and interactive content are transmitted to a receiver, a viewer makes an interactive response to the interactive content and response data is routed to interaction data processing means for processing, the data processing means receiving response data from a number of viewers; wherein the interaction data processing means is part of an interaction management system which is capable 20 of receiving and processing (a) response data from a range of different interactive applications and / or (b) response data from interactive applications programmed on a range of different software platforms, the interaction management system having an application programming interface and the response data from different interactive applications and interactive applications programmed on different 25 software platforms being compatible with the application programming interface; wherein the response data representing a particular response to a particular interactive application includes an identifier which identifies the particular interactive application to the interaction management system so that at least part of the response data is routed to be processed in accordance with criteria stored in the 30 interaction management system relating to the particular interactive application; and wherein processed response data in respect of the particular interactive application is provided to a party associated with the particular interactive application.

Thus, if a broadcaster wishes to include interactive content in a programme a developer may be asked to write a suitable interactive application. Providing the developer complies with published details of the application programming interface 5 ("APT"), the platform used to construct the interactive application and the platform on which it will run at the receiver end will be irrelevant in terms of processing responses. Versions of the interactive application can be provided for different platforms according to the digital television service provider, for example for satellite and cable transmission. A broadcaster can use interactive applications 10 developed by different people, concentrating on assessing design features without worrying about the development software used and how responses will be processed. The broadcaster will specify that the application must be compatible with the interaction management system API, and will use the interaction management system to process responses.

To receive large numbers of responses to an interactive application and to process them speedily requires considerable communications and data processing resources.

These do not have to be assembled for each interactive application, nor does the broadcaster have to use interactive applications only from a developer who already 20 has access to such resources. The interaction management system can process responses for any compatible application, and provide results to any broadcaster or other interested party. A number of broadcasters can use the interaction management system simultaneously, as incoming responses are routed for correct processing and results are routed correctly. The interaction management system serves as a hub, 25 receiving response data from various sources, processing it, and providing the results to various parties.

The interaction management system will host response processing routines for any interactive applications, these response processing routines complying with the API The API may be MEL based. It preferably handles advanced features such as encryption of data and security, for example to handle secure credit card

transactions if goods are to be purchased using an interactive application. The API should be scalable so that it can be adapted to handle a range of fields such as

entertainment, retailing and advertisements.

5 The interaction management system may communicate with viewers, confimning selections made, reporting on the progress of a credit card transaction or product ordering, and so forth. In a retailing context, the interaction management system may communicate data to a payments gateway or to a product ordering system. In a simple viewer response application, such as registering votes for listed performing 10 artists, the results could be provided for example to a web server accessible by a broadcast company or other interested party.

Preferably, there is also provided a system for facilitating the manner in which utilities can be incorporated in an interactive application. Such utilities may handle, 15 for example, voting for favourite people in a television show, profiling viewers, or providing help. A utility will provide, for example, the basic format for handling votes and the developer of an application will insert the details for a particular application / television programme. This system may be incorporated in the interaction management system as described above or may be implemented 20 independently. Thus viewed from another aspect the present invention provides a system for monitoring interactive viewer responses to interactive television content, in which digital television audio / video content and interactive content are transmitted to a receiver, a viewer makes an interactive response to the interactive content and response data is routed to interaction data processing means for 25 processing, wherein the interaction data processing means is part of an interaction management system which is capable of receiving and processing response data from a range of different interactive applications, and the interaction management system has a utilities application programming interface whereby an interactive application which is compatible with the utilities application programming interface 30 may access a plug in utility stored by the interaction management system so that the utility can be dynamically inserted into the application.

Thus, a third party provider of an interactive application will provide a section of the application in which a call to a specific utility will be specified. When running, the application will use the utilities application programming interface to access the utility stored in the interaction manager so as to upload the utility to the application.

An area of the interaction management system can be reserved for storing utilities, and a library of utilities can be created.

There is also described herein a way of enabling various tools to be used when 10 designing an interactive application, whilst facilitating compatibility with particular interactive television platforms. In general, designers of interactive television applications use a variety of content entry tools. They require content formatters to format the application in accordance with a particular interactive television platform.

15 Thus, an invention disclosed herein provides a system for developing an interactive application for a digital television platform, in which content entry tools provided by a content entry application are used to provide the den nition of an interactive application, and a content formatter converts the definition of the interactive application into an application compatible with a digital television platform, 20 characterized in that the content formatter is provided with an application programming interface and can process interactive application definitions which are created by a plurality of different content entry applications and which comply with the application programming interface.

25 Thus, the designer of an interactive application can use a preferred content entry application, and provided it complies with the API of the content fo'Tnatter it will be formatted so that it complies with the necessary digital television platform or platforms. 30 The content entry application may include editing tools, giving access to such features as text, images, graphics, buttons, list boxes, video control, templates, custom elements, carousel statistics and delivery parameters. It may also include s

content formatting, but this will not be to produce a final application compatible with a digital television platform. Instead it would produce an interactive application definition complying with the application programming interface of the content formatter in accordance with the invention which produces the final application. It 5 will be appreciated that the expressions "content entry application" and "content formatter" include arrangements in which two or more physical applications are used together or in sequence.

An embodiment of a system in accordance with the invention will now be described 10 by way of example and with reference to the accompanying diagrams in which: Figures IA and IB constitute a schematic layout of an interaction management system; 15 Pigure 2 shows how utilities are handled by the interaction management system; Pigure 3 shows how content editing tools are used to create an application definition which complies with the API of the content formatter, 20 Pigure 4 illustrates a flow diagram for the interpretation process carried out by the content formatter, and Figure 5 is a further diagram illustrating the interaction management system 25 Referring now to Figures lAand lB,numeral I designates a site of a first broadcaster. Here, audio / video content 2 is combined with data 3 at a head end 4.

The result is a programme with interactive content which is broadcast at an appropriate time. The resultant digital signals are sent to a satellite broadcasting provider 5 for uploading to a satellite via a dish 6. The signals are also sent to a 30 terrestrial digital broadcasting provider 7 for broadcast via an antenna 8. However, the data for the interactive application is different because the set top boxes for the satellite and terrestrial systems are different and run different software. At a first

home 9, a satellite receiving dish 10 receives the signals and feeds them to a set top box I I connected to a television receiver 12. A remote control 13 is provided for the set top box. This is used to enter responses to interactive content in the programme.

Response data is fed to a modem 14 and then to the conventional telephone network 5 15. At a second home 16, an antenna 17 receives the terrestrial broadcast signals and feeds these to a set top box 18 connected to a television 19. A remote control is provided for the set top box, but in this installation it cannot be used to transmit responses. instead, a conventional mobile phone 21, communicating with a mobile telephone network 22, is used to transmit a text message or a series of key strokes to 10 a telephone number. Thus, this illustrates that the same basic interactive application may be written for two different platforms and that a response can be in the form of digital data transmitted over a telephone line or in the form of a text message or a series of keystrokes using a mobile telephone.

15 Numeral 23 indicates the site of a second broadcaster. Here, audio / video content is combined with data 25 at a head end 26 to create art advertisement. This is fed to a cable television provider 27. The platform for the interactive application is different to those for satellite or terrestrial digital. The data i s transmitted to a third home 28 by fibre optic cable 29, where the data is received by a set top box 30 connected to a 20 television 31. A remote control 32 for the set top box is provided, and this can be used to submit responses to interactive content in the advertisement. The responses are processed by the set top box and transmitted back to the cable service provider along the fbre optic cable 29. Thus, this is an example of a second interactive application, which may have been developed in an entirely different manner to the 25 first application, running on a third platform and generating responses through a third route.

Numeral 33 designates an Interaction Management System which can deal simultaneously with all of the response generated. Within the Interaction 30 Management System 33 is an interface 34 connected to the cable television provider 27 to receive responses sent baclc from home 28, and of course all of the similar homes connected to the service at watching the interactive programme. A GSM

modem 35 receives signals from the mobile telephone 21 used at home 21, and of coume at other homes in a similar situation, and a text message or series of keystrokes are converted into suitable data. A conventional modern 36 is connected to the conventional telephone network to receive response data from home 9 and 5 similarly equipped homes.

The data is fed though an application programming interface API, where data in a standard format required by the interactive management system is generated from the received data. This is fed to a module 37 which identifies the particular 10 interactive application that a particular set of response data refers to, by reference to criteria stored in the management system 33. In the example shown, response data from home 28 is identified as relating to one interactive application and routed through module 38 to a processing. Response data from homes 9 and 16 is identified as relating to another interactive application and routed through module 39. The data 15 from module 38 is processed at 40 to extract the required data for supplying to the broadcaster at site 23, and fed to a data server 43 at the broadcaster's site or otherwise accessible to the broadcaster. Similarly, data from module 39 is processed at 41 to provide data which is supplied to a server 42 at broadcaster's site 1.

20 By way of example only, at site 23 the broadcaster could analyse responses to an interactive advertisement, whereas at site 1 the other broadcaster could analyse responses to an opinion poll. The nature of the particular interactive applications, the responses, and the treatment ofthe responses are not relevant to the object of eh invention, which is to provide a versatile system for handling responses from a 25 variety of sources, using a variety of platforms and transmitted through a variety of routes. The provision of an APl, combined with response data complying with that API, enables the Interaction Management System to meet this object.

The above example is merely by way of illustrating the manner in which the 30 interaction Management System can handle various scenarios and is not intended to be limiting.

With reference now to Figure 2, Interaction Management System 33 is provided with an area 44 which is reserved as a library for utilities 45, 46, 47 and so forth to be plugged in by third parties, to work with their interactive applications. The software provided to create the utilities may be provided on physical media such as a 5 CD ROM, or be downloaded from a remote site. A utilities API 48 is provided. An interactive application 49 created by a third party includes a section 50 which will make use of a utility such as 45, in the utility library 44. This is achieved by issuing a call to the library in a manner compliant with the utilities API. The plug in utility can then be inserted dynamically into the interactive application 49.

For example, the utility 45 may be the basic structure of a help file for use in an interactive application, in which a particular help topic may have a topic heading and associated text. The developer of the application will specify the topic headings and text in a format compliant with the plug in utility. By calling the utility, when the 15 application is running, a help routine becomes available within the interactive application. Similarly, a plug in utility could specify the basic structure of a voting routine. The developer would specify, for example, a heading for a voting screen, an instruction for the audience (such "vote for your choice"), and a list of choices to vote for with associated numbers. The plug in utility would display this in an 20 appropriate manner on screen, and could also ensure that viewer responses are communicated to the interaction management system in a form complying with the general API for the interaction management system.

Referring now to Figure 3, an interactive content author is provided with a display 25 102 and input device 104. These can take any form appropriate for displaying the development of the interactive application and allowing input from the author. They might be of the form of a conventional personal computer or form part of broadcasting studio apparatus. The system may be used to create an application conforming to the APT of the Interaction Manager as discussed above but is not 30 exclusively for such use.

As illustrated, the display 102 and user input 104 interact with a controller 106 embodying an interactive content authoring tool. The authoring tool is arranged to provide to the author, by means of the display 102, the supply of simple authoring tools, together with various tips and guidelines for assisting the author in the 5 development of the application. In particular, these allow non-specialised personnel (nonprogrammers) to create interactive content, for instance idea capture, addition of resources (images/text...) addition of behaviour etc. Control is achieved by means of the input 104.

10 The authoring tool 106 also provides a library of common interactive content elements, such as buttons 108, list boxes 1 10, video control 1 12 and presentation/background templates 114. These provide the author with a selection of

predetermined features which may be manipulated to create the desired application.

Other custom content elements 116 may also be provided.

A library is collection of objects to be used by some software. In general, libraries can be enlarged and customised by adding new objects to them; these new objects can be created either by the user of the software or by the company which created the library. In order to generate a particular interactive application, the authoring tool also allows input of specific project interactive content elements or resources such as images 118, text 120 or graphics 122. These are provided by the author to the authoring tool and may be available from an external data base or memory.

Thus, by combining the common interactive content elements as arranged by the author with the specific project resources provided by the author, the authoring tool is able to create a definition of a generic application.

30 With regard to the use of the interactive application, the authoring tool also requests from the author, the required delivery parameters, for instance the carousel statistics 124, the service parameters 126 and the data base links 128. The service parameters

are described here as part of the delivery parameters. However, the delivery parameters and the service parameters can be considered to be the same thing. The service parameters include application delivery band width, carousel ordering and timing, location (data base) of application resources. Carousel statistics are not part 5 of parameters but they are calculated from parameters. The statistics can quantify, in relation to the carousel's structure, the max. min and average values for key aspects of the application. Example key aspects are: boot-up bme, waiting time for resources, transition time between screens, perceived and objective latency. As illustrated, the definition of the generic application as formed 10 by the authoring tool is stored in an interactive content project file 130.

As also illustrated, a content formatter in the form of an intelligent interpreter 132 is provided. The interpreter 132 has an application programming interface (API) 134 which is XML based. The stored interactive content project file 130 complies with 15 this API and thus the interpreter is able to retrieve the generic application definition stored in the project file 130 and to convert this definition into an interactive application according to any number of predetermined platforms requested by the author. For instance, as illustrated in Figure 3, the interpreter 132 may create specific applications for specific platforms such as open TV, MHEG, Java-HTML 20 etc. In order to achieve this, the interpreter is provided with look-up tables for parameters and functions enabling it to translate the generic application definition into a specific application.

By adding new interpreters, for instance by way of supplementing the lookup tables, 25 it is possible to retarget the interactive content to new platforms. The interactive content design is retained in the generic project file as the generic definition.

Each project file is a binary file containing all the information concerning an application. The necessary information is described in the previous paragraphs: 30 parameters, layout and behaviour. The particular binary format of the file can be of any suitable definition

The process conducted by the interpreter 132 is illustrated in Figure 4.

In step 200, the interpreter first opens the generic application product file 130. In step 202, it determines the file format and in step 204, it determines the platform to S which the application is to be exported.

A project file is written in a particular predefined binary format. The same software could support more than one binary format (e.g. java or xml) , provided it complies with the interpreter's API 134. When opening the project file, the software examines 10 the contents of it to determine if it is a supported format and which one. Once the file is opened, the software will then determine which is the target platform, either from information within the file itself or from user.

In step 206, the interpreter determines whether the plug-ins for the chosen platform's 15 API are available. Without these plug-ins, the interpreter is not able to produce the required specific application. Therefore, in step 208, it alerts the user and the process returns to step 204.

If the required plug-ins are available, the process continues with steps 210 and 212 in 20 which the generic application is converted to the specific application. As indicated, this is achieved by means of look-up tables for the various parameters and functions defined in the generic application so as to provide the actual code required for the specific application.

25 Steps 210 and 212 can be considered to be pert of the same process. The project file is processed to generate source code in a given language for a given platform. The project file is examined and the application for the target platform is generated using a mixture of compilation algorithms (implement the required behaviour) and look-up tables (to translate from the project file format to the specific format required). An 30 example of use of all this is where a button is required to appear on a screen. The project file would contain the indication that a button has to appear with a certain graphic appearance and doing a certain behaviour when selected. The algorithm will

detect that a button is required for, e.g., the API of the platform called Openly. The button will have to display a bitmap and play a sound when selected. The algorithm will then use a look-up table, which for 'button' will return the particular code used by OpenTV to implement a button. This code will have placeholders for the bitmap 5 and the behaviour to implement. The algorithm will use the look-up table again to obtain the code to display a bitmap, will convert the bitmap to the format used by OpenTV and will insert the result instead of the bitmap placeholder. The same process is applied recursively to the button behaviour.

10 In step 214, the interpreter determines whether or not there are any problems with the conversion and, if so, in step 216, notifies the user of these problems. At the same time, the interpreter can also provide a list of modifications it has made in interpreting the generic content to the specific content.

15 In step 218, the interpreter notifies the user of any performance issues with regard to the resulting specific application and the delivery parameters.

In step 220, it is determined whether or not the user has requested a preview of the converted application. If so, in step 222, a preview is displayed for the user, for 20 instance by means of the controller 6.

Finally, in step 224, the interactive application is saved ready for deployment.

In Figure 5 there is shown how an Interaction Management System is used in a 25 return path architecture. A broadcast centre 51 is responsible for the play-out of video services and interactive applications. The resulting multiplex is broadcast via an aerial 52 to a viewer's set top box 53 which is connected to the viewer's television 54 and to the telephone network (PSTN) through a modem 55. When a return path application needs to send information back to the broadcaster, the modem 55 dials up 30 a modem farm 56 through a local Point Of Presence (POP) and the set top box 53 is authenticated by an authentication server 57. The authentication server verifies each call against credentials stored on the viewer's smart cardin the set top box 53. Once

the connection has been established and authenticated it is passed to a back end server 58 of an Interaction Management System that processes the data from the application. Once the back end server 58 has processed the data from the application, the results (either individual or aggregated) are uploaded via the Internet 59 to a 5 public facing server 60 for processing at the broadcasting service 51. There may also be a link to linear play-out and other platforms.

Generally, all calls are authenticated and it is the responsibility of the return path provider to manage this process.

The underlying protocol used by the interactive application to communicate with the back end servers may be HTTP using the POST method. The underlying protocol used for delivery of data to the broadcasting service 51 for post processing may be either PTP or HTTP using the POST method depending on the nature of the service, 15 and the application protocol will generally be XML compliant. If an HTTP POST is used, the content of the POST should simply be an XML document.

A number of different application types are envisaged which include: Simple votes; Competitions; Messaging (offline message composition); and Chat Each of these types of application has broadly similar requirements for the structure of the data reported by the backend server (or servers). Accordingly, the backend server should preferably be configurable for various instances of each type of application without requiring any code changes on the backend servers.

The data back haul requirements for each type of application also vale from type to type but are similar within each type. With this in mind, there will be discussed below the following: the protocol used by the interactive application to communicate with the back end server; the protocol used by the back end server to communicate 30 information for votes and competitions back to the broadcasting service; and the protocol for configuring the back end server to handle different instances of the same application type.

The key aspect of voting services is that they will involve potentially high traffic but do not require the broadcasting service to be aware of each individual vote - instead, the results will aggregated before the information is delivered to the broadcasting 5 service. In the simplest case, a single set of totals for each vote question will be needed but some votes will also include classification questions (e.g. age range) which will require the vote results to be aggregated within the resulting classifications. For example, if there are five questions, one of which is age range, and there are five possible age ranges, then five sets of aggregated results will be 10 required (one for each age range) where each result set has the answers to the remaining four questions.

An important feature of any voting application is that all questions will be multiple choice. There is no requirement for each question to have the same number of 15 possible answers but there will not be any use of free text as the user will simply select which of the possible answers they want for each question.

By way of example, the STB client could add the following AWL message to the body of the HTTP POST request: <req> <session service_id-"6301 " region=" 1"/> <voting_session episode_id="Episode-001" vote_freq="D" app_id="Question Time"> 25 <question id="0" answer=" 1 "A <question id="n" answer-"n"/> c/vOting_session> </req>

The answer for each question is specified using the <question> element which has two attributes, id and answer. The id attribute identifies the question and the answer indicates which answer was selected.

5 The <question> elements themselves are contained within a <voting_session> element which carries attributes - episode_id and app_id - to identify which voting service the data is for. The app_id attribute will typically be used to identify which program series the vote is associated with, and the episode id attribute simply qualifies this to identify the 'episode' of the series. Jointly, the app_id and episode_id 10 will uniquely identify a specific vote.

vote_freq: O - Open D - one per Day 15 W - one per Week M - one per Month C - Closed (i.e. one vote) Voting applications will be provided with a response according to the result of their 20 request. These responses are detailed below: Response Meaning Allow retry? Error OK The request was No correctly processed REPEAT The STB has already No made a vote for the given vote_freq attribute.

BAD CLIENT The STB request is No 42 MESSAGE improperly fomnatted

AUTHENTICATION The Smartcard and No 41 FAILED Subscriber IDs could not be retrieved from H1lP header VOTE FAILED The Ate could not be Yes 40 registered due to a backend specific error Data back haul for vote applications will be in the form of an XML document delivered using either FTP or HTTP using the POST method.

5 The <AggregatedVote> element is the root element for documents giving the results for an aggregated vote. For an aggregated vote, all that is required is the total numbers of each answer for each question in the vote. For example, for a 'people's Oscars' vote, each category (i.e. question) may have a number of possible responses corresponding to the various Oscar nominations (i.e. answers). The 10 CAggregatedVote> element simply contains a list of <Classification> elements, each of which will contain a list of CQuestion> elements. In turn, each CQuestion> element will contain the totals for each answer in a list of <Answer> elements.

Additionally, each cclassification> element may also contain a <Channel> or CRegion> element if classification by channel or region has been requested. If no 15 classification of the results has been requested, then there will simply be a single CClassification> element.

The <AggregatedVote> element takes attributes which specify a start and end time, and each aggregated vote document will contain the results for the specified interval 20 - if a cumulative total has been requested, the start time will always be the start time of the vote, otherwise it will be the time of the last report. The specific vote for which the data has been provided is determined by the Voteld attribute.

The <Question> element has an Id attribute which identifies the question, and each <Answer> element has an Id attribute to identify Me answer and a Total attribute to specify the total number of votes for each answer. <Answer> elements which have an Id attribute with the value -1 indicate the number of times that the question was 5 skipped. For example:

<.9xrnl version="l.O" encoding="UTF-8"?> 10 <VoteAggregate VoteId="myVote" Episode="3 " StartTime="2002-06-05T08: 30: 00" EndTime="2002-06-07T09:35:00"> <Classification> <Channel Id="6301 "/> <Region Id=" 1 "/> 15 <Question Id="3" Answer="O"/> <Question Id=" 1 "> CAnswer Id="-1 " Total="5"/> <Answer Id="O" Total=" 13"/> <Answer Id=" 1 " Total="30"/> 20 <Answer Id=" 2" Total=" 27 "/> <AnswerId="3" Total="12"/> CAnswer Id="4" Total="43"/> </Question> <Question Id="2"> 25 <Answer Id="-1 " Total="5"/> <Answer Id="O" Total="7"/> <Answer Id=" 1 " Total="32"/> <Answer Id="2" Total="5"/> <Answer Id="3" Total="23"/> 30 <Answer Id="4" Total="25"/> </Question>

<[Classification> <IVoteAggregate> 5 The processing requirements for messaging are less complex than for votes as all one really needs to do is pass the content through to a moderation system without any pre-processing. It may not be possible to anticipate the format that may be used by any given moderation system, so the broadcasting service may be responsible for all downstream processing of the messages once they have been delivered.

Although the messages cannot readily be processed by the back end server, it will be desirable to provide aggregation of messages into single documents for the purposes of delivering the message data back to the broadcasting service. It will be significantly easier if these 'digest' messages only carry messages for a given service.

15 For example, if two messaging services are carried simultaneously "Points of View" and "Question Time", say - the broadcasting service would ideally receive different digest documents for each service. This means that there will need to be some agreement about some standard fields although the bulk of the content will

operate on a pass through basis. Other standard fields could include region and

20 channel. Chats and competitions can be handled as extensions of the same class of back end as the key requirement is to capture individual results rather than simple totals.

25 The STB client should add the following XML message to the body of the HTTP POST request: <req> <session service_id="630 1 " region=" 1"/> 30 <messaging_session episode_id="Episode-001" app_id="Question Time"> <message>

Afield id="O">Value</field>

Afield id="n">Value</field>

</message> </messaging_session> c/req> Voting applications may be provided with a response according to the result of their request. These responses are detailed below: Response Meaning Allow retry? Error Code OK The request was No I -

correctly processed BAD CLIENT The STB request is No 42 MESSAGE improperly fom atted AUTHENTICATION The Smartcard and No 41 FAILED Subscriber IDs could not be retrieved from HTTP header REQUEST FAILED The request could not be Yes lo registered due to a backend specific error The following extract is an example: _ <?xml version="l.O" encoding="UTF-8"?> 15 <MessageDigest xmlns:xsi="http://www.w3.org/200 1/XMLSchema-instance" MessageId="QT" Episode="3"> <Message Time="200 1-09- 1 lT09:30:47-05:00" Region=" 1 " Channel="630 l "> CField Id=. ottxcvxcvclpield

Afield Id=" l ">xcv</Field>

CField Id="2">bvdgn ukujytk u7yk Afield>

</Message> Message Time="200 1-09-1 I T09:30:47-05: 00" Region=" 1 " Channel="64 11 "> 5 <Field Id="O">fdg tuyj uiruik rttyu</Field>

<Field Id=" l ">rtylk 9 6Oi6 jrjtyj</Field>

<Field Id="2">rby rty rtyrtyrt<lField>

<IMessage> <Message Time-"200 1-09-1 1 TO9: 30:47-05:00" Region="2" Channel="6305"> 10 <Field Id="O">rtyrty rty rty rt</Field>

<Field Id="2">try tuyi irryi urclField>

</Message> </M es s ageDigest> There will now be described the functionality of code deployed on the Interaction Management platform for games within an interactive TV generic game service.

The specification takes the fonn of a series of Use Cases' each of which describes a

20 piece of functionality required by the code. Each use case precisely describes the interaction between an external entity and code deployed on Interaction Manager.

The services provided by the backend are accessible via http requests, the details of which are specified in each use case. After each request the backend returns a http 25 response whose code specifies the outcome of the request, if the request requires any information from the backend, this is returned in the body of the http response in the format of an XML message.

There may be, for example, two kind of games that make use of the generic game 30 service:

1. Arcade games. These games start calling a use case Get!Session, the backend returns information previously stored for the device from where the GetSession is called; and at the end of the game the user can submit or save his game.

5 2. Pay to play games. These games call an Unlock Game use case to receive the go-ahead from the backend, but no additional information is returned nor is possible to submit or save any game at the end of the game.

Get Session.

10 Participants: Set Top Box (STB) Application Pre Conditions: None.

Description: The STB application makes an HTTP request to Interaction Manager

before a game is played. Interaction Manager will return a list of possible users with their saved games, their keypad preferences, their statistics, as well as an address and 15 a high score table detailing users' scores from that STB. All these information are specific to the game type; the url identifies the game type requesting the session.

Details of the user and address information returned are discussed below, as are details of the high score table information returned.

20 Data required comprises a Subscriber ID and the STB Smart Card ID. This information will be contained in the header of the request and is used to identify the users and their address information.

As regards data returned, the body of the HTTP response will contain an XML.

Post conditions are that the user's session is stored on the database.

In a first scenario, a user's STB that has never been used to play any interactive TV game before, requests a session. The body of the HTTP response will contain an 30 CAL file and thee new STB details are stored on the database. The user's session is

recorded on the database. In an alternative scenario, a user's STB that has already been used to play interactive TV games requests a session but there are no users who have played the Game before. The body of the HTTP response will contain an XML file and the user's session is recorded on the database.

When the STB application invokes Use Case Get Session, Interaction Manager returns user and address information. This is the last address submitted with any interactive TV game from the STB making the request. An unregistered STB could have users, but no address. A registered STB will have users and an address. The 10 STB application must call the STB registration application when the user submits or saves if no address is supplied by the back-end as part of Use Case Get Session, so that the user can enter one.

Interaction Manager returns information for up to n users (configurable) who have 15 submitted game information from the requesting STB. The first users returned are those who most recently played a Game session from the requesting STB. Additional users are those who have played any session within the Interactive TV game service.

The User Information returned includes: ID, First Name; Last Name, and then for the users who have played the game: personal best score; total time spent playing the 20 game; the personal best level they have attained; the total number of games they have played; and any awards they have received.

The data returned comprises user information including First Name, Last Name, 2S personal best score, total time spent playing the Game, the personal best level they have attained, the total number of games they have played and any awards they have received. The data returned also comprises address information which includes House ID, Street, Town and Postcode, and other details. This information is formatted, before being sent to the STB application.

For the STB High Score Table, the Get Session Use Case participates. A pre-

condition is that a user has submitted scores. If this condition is not fulfilled the object returned will contain no high scores.

5 A high score table is maintained for each STB. The table holds the high scores for those users who have played the game on the identified STB. When the user saves or submits a game new, entries for the high score table are resumed from the STB (the number of high scores to return is decided by the STB) and stored in the current table. The table returned to the STB contains the n (configurable) highest scores 10 attained by users playing the Game on this STB. The high score table contains the name and ID of, for example, the top ten (configurable) players and their high scores. After a user or users have completed a game playing session, they may submit their I 5 scores and other information for inclusion in prize draws. This information must include the submitting user's address. The highest score achieved by any player in single player mode is usually submitted for inclusion into the competition, but this is a front end decision; the only constraint imposed by this use case is that only one game per session can be submitted, and a game can have only one player. Where a 20 game uses any of the following game related information attributes, they must be included in the submitted XML with correct value for the game. This is also true when a user saves a game. These attributes include: the time spent playing the game; the score, the level attained; any awards received. Each user who played in this session will send his statistics to the backend, although just the user who is 25 submitting the game will enter into the competition draw.

The statistics include: HighestScore: highest score attained in the playing session by this user; 30 Level: best level reached in the playing session by this user;

Awards: all the awards received by the user across all the playing sessions.

The front end receives the last saved awards during the GetSession use case and it must return the updated awards if the user has received any more in the current session, otherwise it must return the same value that it downloaded.

5 This is because only the Dont end knows how to manage this value, and the backend works just as a repository.

Duration: total amount of time the user spent playing the game in this session; Tries: number of games the user played in the session; Cumulative Score: cumulative score for all the games played in the session.

These statistics encompass the values specified for the game that is being 1 5 submitted.

The user can submit games that were previously saved. In this case the Game tag must contain the ID of the saved game that was continued and finished. If the Game tag doesn't contain this ID, the backend assumes that the game has been started in 20 the current session. If there is this ID the backend erases the saved game referenced by this ID to prevent the user to save a game once and submit many scores from the same saved game. In this way the user can submit just one score from a saved game, because the next time he gets a session the saved game will no longer be returned 25 The body of the HTTP request will contain an XML which must contain the session ID that has been downloaded in the Get Session use case to reference the session for which the user is submitting the garne. Failing to do so would result in the incapacity for the backend to link the two use cases, as the connection with the backend is dropped once the session is downloaded and restored to submit the game. This 30 allows the user to play without being connected all the time to the backend. The required tags in the XML are:

Add: contains the address details of the STB; Usr: contains the submitting user's details; 5 Game: contain details on the game to submit.

See the schema for a more detailed description of the xml format.

The Save Game use case is called when the user wants to save a game instead of submitting it. The user can then resume the saved game in one of the next sessions 10 for the backend returns the saved game in the Get Session use case. The saved game is held in the backend until the user submits the resumed game; after this operation the saved game is reset. The user can save the same game many times, and each time the previously saved game is replaced by the new one. Each user can have up to one saved game at a time, in a preferred arrangement. If the Save tag contains the 15 attribute ID, this means that the user is saving again the resumed game, and replaces the old saved game. This use case is the same as the Submit Score except for the Save tag that replaces the Game tag.

The Save tag contains all the statistics for the game at the moment of saving.

20 The statistics of the saved game affect the statistics of the user in the session, therefore if for example the score of the game happens to be the highest in the session, then it must be reported in the Highest Score for the user, regardless whether the game is finished or just saved. The same applies for the other statistics of the saved game. A saved game is not entered in any competition, even if the score at the 25 moment of saving would entitle the user to enter it. The XML must adhere to the same schema defined for the Submit Scores use case.

The STB application makes an HTTP request to Interaction Manager before a POD (Pay On Demand) game is played. Interaction Manager will unlock the game for the 30 STB. Interaction Manager registers a record every time a STB request to play the game. This record contains the STB ID, the request time, and the game type. Data required comprises a Subscriber ID and an STB Smart Card ID. This infonnation

will be contained in the header of the request and specifies the STB for which the game will be unlocked. It also comprises the Game Type, which specifies the game that needs to be unlocked. This value is passed as parameter in the url There are just a fixed number of values that this parameter can assume. The data returned is an 5 HTTP Status Code representing the outcome of the request, e.g. 200 for OK, 500 for sewer error, etc. A system in accordance with the invention can also be used for responses to TV advertising, including the purchase of products.

The inventions disclosed herein may be expressed as systems, methods, data processing apparatus programmed to be all or part of a system or to carry out all or part of a method, or computer software for programming data processing apparatus to be all or part of a system or to carry out all or part of a method. Such computer 15 software may be in the form of a produce such as a disk or tape storing instructions to be read by data processing apparatus, or may be in the form of signals provided to data processing apparatus over a suitable communications system such as a network, e.g. the Intemet

Claims

1. A systam for monitoring interactive viewa responses to interactive television content, in which digital television audio / video content and interactive content are 5 transmitted to a receiver, a viewa makes an interactive response to the interactive content and response data is routed to interaction data processing means for processing, the data processing means receiving response data from a number of viewers; wherein the interaction data processing means is part of an interaction management system which is capable of receiving and processing (a) response data 10 from a range of different interactive applications and / or (b) response data from interactive applications programmed on a range of diffacot software platforms, the interaction management system having an application programming interface and the response data from different interactive applications and interactive applications programmed on different software platforms being compatible with the application 15 programming interface; wherein the response data representing a particular response to a particular interactive application includes an identifier which identifies the particular interactive application to the interaction management system so that at least part of the response data is routed to be processed in accordance with criteria stored in the interaction management system relating to the particular interactive 20 application; and wherein processed response data in respect of the particular interactive application is provided to a party associated with the particular interactive application.

2. A system as claimed in claim 1, wherein the interaction management system 25 has a utilities application programing interface whereby an interactive application which is compatible with the utilities application programming interface may access a plug in utility stored by the interaction management system so that the utility can be dynamically inserted into the application.

30

3. A system as claimed in claim 1 or 2, wherein the response data is aggregated and the aggregated results are provided to the party associated with the particular interactive application.

4. A system as claimed in claim 1, 2 or 3, wherein the party associated with the particular interactive application is a broadcasting service which broadcasts television signals incorporating the interactive application.

s

5. A system as claimed in any preceding claim, wherein the particular interactive application includes a mechanism for viewers of the interactive television content to register votes.

10

6. A system as claimed in any preceding claim, wherein the particular interactive application includes a mechanism for viewers of the interactive television content to answer at least one multiple choice question.

7. A system as claimed in any preceding claim, wherein the particular 15 interactive application includes a mechanism for viewers of the interactive television content to order a product or service.

8. A system as claimed in any claim 7, wherein the particular interactive application includes a mechanism for viewers of the interactive television content to 20 pay for the product or service.

9. A system as claimed in any preceding claim, wherein the particular interactive application comprises a game for viewers of the interactive television content to play.

10. A system as claimed in claim 9, wherein the interaction management system records scores submitted by viewers and can return scores to viewers subsequently.

11. A system as claimed in claim 9 or 10, wherein the interaction management 30 system can save a game session of a viewer, and can return the game session to the viewer subsequently so that it can be resumed.

12. A system as claimed in any preceding claim, wherein user data is authenticated before being passed to the interaction management system.

13. A system as claimed in any preceding claim wherein data passed to and/ or 5 from the interaction management system is in the form of IL.