GB2403116A - Generating video signals from SMS data - Google Patents

Abstract

The invention is concerned with a system and a method for generating video signals from data messages, specifically with a system that can process large volumes of incoming data messages (e.g. SMS messages) ```Embodiments provide a method of generating a video signal comprising the steps of: ```processing a plurality of messages so as to derive content therefrom; ```generating a video signal comprising said derived content; and ```broadcasting the generated video signal, ```characterized by: ```providing two or more data processing modules, each data processing module being for use in said processing of the messages; ```identifying processing capacity in respect of said two or more data processing modules; and ```allocating the messages among the data processing modules, for processing thereby, in accordance with said identified processing capacity. A further embodiment allocates messages to processing modules dependant on their time of arrival.

Description

240311 6 Method and System for Generating Video Signals

Field of the Tnventlon

The present invention relates to a method and system for generating video signals and is suited particularly, but not exclusively, to generating streamed video signals and/or television video signals from incoming data messages.

Background of the Invention

The medium of choice for conducting conversations is moving from voice to data messaging, with people increasingly using the Short Message Service (SMS) and email for interactive one-to-one dialogues.

Over the last few years, there have been developed combined messaging and broadcasting systems which essentially follow a many-to-one model, whereby many users transmit data messages which are then broadcast on one public medium (e.g. television). In addition to facilitating interactive dialogues between individuals, these systems additionally provide a platform for polling and voting, and for publishing feedback in respect of goods, services and programs of interest.

Various implementations of such systems are described in international patent applications W099/63729, W000/27115 and W0()2/32134.

An advantage of developing technology that supports the combination of messaging and broadcasting is that most people have access to a television, so the potential audience, and thus user base, Is correspondingly large. However, a problem as yet unaddressed by the abovereferenced patent applications is one ol scalability. If indeed large numbers start to make use of such systems at any one time, the processing of and response to large volumes of messages become a problem.

An object of the invention is thus to provide a system that is capable of processing large volumes of messages in an efficient and reliable manner.

Summary of the Invention

According to a first aspect of the present invention there is provided a method of generating a video signal comprising: processing a plurality of messages so as to derive content therefrom; generating a video signal comprising said derived content; and broadcasting the generated video signal, characterized by: providing two or more data processing modules, each data processing module being for use in said processing of the messages; identifying processing capacity in respect of said two or more data processing modules; and allocating the messages among the data processing modules in accordance with said identified processing capacity.

Embodiments of the invention are concerned with processing high volumes of messages for publishing on a publicly accessible medium. In such an environment, the response times offered by conventional First-ln-First-Out (FIFO) processing of messages by a single processing module (such as that described in WO02/32134) are unlikely to satisfy large volumes of users participating in a message-to-screen service.

In accordance with the present invention, rather than simply processing messages one at a time, as described in the afore-mentioned prior art, messages are allocated to a plurality of data processing modules on the basis of their capability to process messages. This means that many messages can be processed effectively simultaneously, resulting in a higher throughput than is possible with known systems, such that the broadcast video signal can include selected content from messages which have arrived during a broadcast period, for example during a television show.

In embodiments of the invention the data processing modules are arranged to display the allocated messages for review and selection therefrom, so that the processing of messages includes, at each data processing module, selection of one or more messages and outputting of data indicative thereof, wherein content of the selected messages is used to generate the video signal.

In one arrangement the step of identifying the processing capacity includes monitoring for processing requests from said data processing modules, and the messages are allocated among said data processing modules in accordance with the number of processing requests received therefrom.

In an alternative arrangement, for each data processing module, the step of identifying the processing capacity includes receiving data identifying a number of messages currently stored for processing thereby, and the allocating step includes distributing the messages such that the processing of said messages is substantially shared among said data processing modules.

Thus in the first arrangement, allocation of messages is based on explicit requests for messages, whilst in the second arrangement allocation of messages is based on the progress that the user is making in processing messages. In both cases, the distribution of messages among the monitors is dependent on their respective processing capacities, since, in the first arrangement capacity information is implicit in the frequency with which requests are issued (those monitors sending requests more frequently than other monitors processing messages more quickly than the other monitors); and in the second arrangement the number of messages having been processed is directly indicative of the processing capacity of a respective monitor.

An advantage of the first arrangement is that the data processing modules are only required to be configured with functionality to request and review messages. This means that each data processing module can be configured with a minimum specification of hardware, and is thus relatively cheap.

Conveniently, the processing capacity of a data processing module can be identified in response to one or more operations that are not explicitly linked to requesting messages. Such an operation may, for example, include a data processing module performing a specified review action.

Further features and advantages of the invention will become apparent from the following description of preferred embodnnents of the invention, given by way of example only, which is made with reference to the accompanying drawings.

Brief Description of the Drawings

Figure 1 is a schematic diagram of a data communications network arranged in accordance with an embodiment of the invention; Figure 2 is a schematic diagram of a system for generating video signals according to an embodiment of the invention; Figure 3a is a schematic diagram of a monitoring processing module shown in Figure 2 according to a first embodiment; Figure 3b is a schematic diagram of a monitoring processing module shown in Figure 2 according to a second embodiment; 1 S Figure 4 is a schematic diagram showing, in more detail, a system for generating video signals according to the first embodiment; Figure 5 is a schematic diagram of a data receiver shown in Figure 2 according to the first embodiment; Figure 6 is a flow diagram showing steps involved in processing incoming messages according to the first embodiment; Figure 7 is a schematic diagram showing a system for generating video signals according to the second embodiment; and Figure 8 is a screen-shot of data displayed by the monitoring processing module shown in Figure 3a.

Detailed Desenption of the Invention Embodiments of the invention are particularly concerned with conlgurations of hardware and software that suited to large volumes of users and can thus handle large volumes of messages. The nature of this configuration will be described in detail later in the desenpton, but first an s example of a system in which such messages arc received and processed will be described.

Embodiments of the invention arc concerned with processing any form of data-carrying-message, from any network device, for the purposes of participating in a many-one service. Although, at the date of filing of the application, common types of messages include SMS, MMS and email, embodiments of the invention can apply to any future type of messages, in particular those that arise with the widespread adoption ol General Packet Radio Service (GPRS) as a communication service.

Figure] shows an example of a message-to-screen network arrangement 1 within which embodiments of the invention operate. As stated above, in this embodiment Terminals Tl, T2 are configured to send messages, e.g. Short Message Service (SMS) messages, Multimedia Messaging Service (MMS) messages or email messages, to a specified destination address DA. For illustrative purposes it will be assumed that the messages are SMS messages and that the destination address DA is an MSISDN number corresponding to a message-to-screen service; it will be appreciated that this is merely illustrative of the route that SMS messages can take, and that the environments in which embodiments of the invention operate are not to be limited to this configuration.

The terminals T1, T2 may be wireless terminals such as a mobile phone, a PDA or a Laptop computer, or fixed terminals such as a personal computer.

An exemplary message-to-screen network arrangement I comprises a mobile network Nl, which receives messages sent from terminals T1, T2; an SMSC gateway G1, which modifies the messages such that they can be transported over a Public Land Mobile Network (PLMN) N2; an internet gateway G2, which modifies messages such that they are suitable for transmission over the Internet N3; and a message receiver Sl, whose address corresponds to the destination address DA of messages sent from the terminals Tl, T2. The message-to-screen network arrangement I also includes a Virtual Private Network link VPNI, which provides a link, through the Internet N3, from the data message receiver Sl to a message processing system S2, described in more detail below. The message-to-screen network arrangement 1 also includes a TV broadcasting system S3, which is arranged to receive data from the message processing system S2 and broadcast the same to one or more television receivers (not shown). Alternatively the message processing system S2 can send the data to specified internet-accessible terminals, such as terminal T3.

As per conventional message-to-screen arrangements such as that described in international patent application WO02/32134, messages are sent by Terminal Tl in response to, for example, a television broadcast that includes an advertisement detailing the MSISDN destination number DA corresponding to a message to screen service. Messages sent to this destination number DA can include free text or one of a plurality of selectable options. Once received by the data receiver S1, the message is transmitted to the message processing system S2, in which embodiments of the invention operate.

Referring now to Figure 2, an embodiment of the invention will be described. In Figure 2, the arrows indicate data flows within the message processing system S2 and the blocks indicate components of the message processing system S2. The message processing system S2 comprises a plurality of data processing modules 201 (in the Figures different modules are referenced as 201a, 201b etc...), hereinafter referred to as monitor modules or simply monitors 201, each being arranged to process received messages in such a manner that a subset of the messages received by the data receiver S I progress from the monitors to a publishing module 203. Decisions as to allocation of messages among the plurality of processing modules are taken on the basis of their respective processing capacities, as described in more detail below. Once messages have been allocated to a monitor 201a, the monitor displays one or more of the allocated messages, receives input in respect of the displayed messages from a user and tags the messages in accordance with the input. As will be described in greater detail below, the tags are essentially acceptance data, which indicate whether a message has been accepted for processing by the 3() publishing module 203.

Once the messages have been tagged, those whose acceptance data indicate that they have been accepted by a monitor 201a, 201b etc. are passed over to the publishing processing module 203, hereinafter referred to as publisher. The publisher 203 is arranged such that a publishing user can further refine the selection of messages, whereupon the selected messages are arranged into a format that is suitable for viewing on a display screen (e.g. a TV, a VDU, a PDA etc.), taking into account the constraints placed by the display medium (in particular size of screen etc.).

Once the selected messages have been formatted, they are combined with program material 205 received from a content provider (not shown) in a video signal processing module 207, and the combination is formatted into a digital image. The combining of the selected messages can be performed using visual display software (not shown) embodied as a Visual Basic Script that is arranged to operate in conjunction with an Active X_ control. The Active X_ control is arranged to manage operation of a Chyron Duet_ application, which, as is well known in the art, is a digital graphics production system for creating text, logos and animation images for video signal applications. These images are then converted into either an analogue video signal, suitable for conventional television analogue broadcasting systems, or into digital signals, for example in accordance with the Serial Digital Interface (SDI) standard for digital broadcasting television systems and web-based video streaming, and output to the relevant broadcasting system S3 for broadcast thereby. The functionality of the video signal processing module 207 is conventional, and will not be described in any further detail.

Tunning to Figures 3a and 3b, embodiments of the invention will now be described in more detail; the figures respectively show first and second embodiments of a monitor tennmal 201, at which a user, referred to as a moderator, performs initial moderation of messages received by the data receiver Sl. Describing first the features that are common to both embodiments, in addition to standard CPU, memory, data bus, Input/Output ports, data storage, and operating system programs, a monitor terminal 20] comprises displaying software 301 and tagging software 303. The displaying software 301 is arranged to receive data from the data receiver S1 and to format and display the received data on a visual display unit (VDU) that is in operative association with the monitor terminal 201. A moderator, viewing the messages displayed on the VDU, can indicate whether or not a message is to be accepted, and can additionally modify the content of displayed messages. These indications are received by the tagging software 303, which tags the messages in accordance therewith (as will be described in more detail below). The Indications thus represent, either directly or indirectly, acceptance data, and the process of marking the data is generally referred to herein as moderation.

Turning now to the features that differ betwocn the two embodiments, in Figure 3a (first embodiment) the monitor terminal 201 includes message requesting software 305, whereas in Figure 3b (second embodiment) the monitor terminal 201 includes message counting software 307. In the first embodiment, requesting software 305 sends a request to the data receiver S1 for messages; this request will typically include acceptance data recorded by the tagging software 303 relating to previously requested messages (in other words messages that already have been moderated by the user). In the second embodiment, shown in Figure 3b, of those messages that have been allocated to the monitor terminal 201, the message counting software 307 is arranged to identify and send to the data receiver Sl data indicative of a number of displayed messages that have yet to be processed.

Thus in the first embodiment, the data receiver S1 receives explicit requests for messages and in the second embodiment the data receiver Sl receives data indicative of the progress that the user is making in processing messages. This information is utilized in the allocation of messages among monitor terminals 201 so that, in both cases, the distribution of messages to monitors is dependent on their respective processing capacities: in the first embodiment the processing capacity information is implicit in the frequency with which requests are issued, since those monitors that send requests more frequently than other monitors are processing messages more quickly than the other monitors and thus have a greater capacity; and in the second embodiment the number of messages having been processed is directly indicative of the processing capacity of the respective monitors, since a high number indicates that a monitor has a significant number of messages yet to process and thus has a low capacity.

These differences have an impact on the way In which the data receiver Sl is configured, and the corresponding different embodiments will now be described in more detail with reference to Figures 4-8.

Turmng firstly to Figures 4 and 5, which illustrate aspects of the first embodiment, the data receiver Sl comprises software 501, 503, 505 arranged to store allocate the stored messages among a plurality of monitor terminals 201a, 201b, 201c and storage DBI for storing messages at various stages of their lifecycle in the screen-to-message system. In Figure 4, the database DBI is shown as comprising three parts - a first DBla storing raw data messages, a second DBlb storing messages accepted by a monitor and a third DBlc storing messages accepted by the publisher 203 and awaiting output to the video signal processor 207. This diagram is schematic, and is intended to illustrate that a subset of those messages initially received are eventually broadcast. In Figure 5, the data receiver Sl is shown to comprise queue managing software 501, which assigns each message a place in a message queue based on the time that the message was received (to); status assigning and checking software 505, which assigns a status to messages in the queue, at time of receipt; at time of allocation; and in response to data received from the message requesting software 305; and message allocating software 503, which allocates messages to monitor terminals 201a, 201b, 201c based on their location in the message queue.

The status data assigned by the status software 505 are used in deciding how to allocate messages. Some examples of such status data, together with the actions taken dependent thereon, are given in Table I (the values of the status data are Yes/No (Y/N)): Allocated Monitored t-tlll,, n Status I D Actions N N N/Y S 1 Available for allocation (freshly received message) Y N Y S2 Mark available for re allocation N/Y S3 Mark reject or accept and remove from Queue N S4 No action

TABLE 1

The displaying software 301, tagging software 303, message requesting software 305, message counting software 307, queue managing software 501, allocating software 503 and status software 505 arc preferably written in the Java programming language. Thc data receiver Sl could, for example, be a Apache HTTP web server linked to a relational database DB1 such as Oraclc_ or MySQL_. Thc message requesting software 305 and displaying software 301 running on a monitor module 201a could be embodied in a Java_ Applet configuecd to request messages from Java_ servlet containers comprising the allocating software 503 and status software 505. The allocation of a time to an incoming message can be handled by the database DBI, so that the queue managing software 501 could be provided by the functionality of the database DBI. The Java_ servlet containers can be configured to run within a Java platform such as Java 2 Platform Standard Edition v1.4.1 (for further information see resources available from Sun Microsystcms_ e. g. at http://Java sun.com/J2se/1.4.1/ and http://Java.sun. corn/products/servlet/'ndex.html).

Thc skilled person will appreciate that the software could be written in any suitable language, and that, instead of configuring the software as servlet containers, they could be Common Gateway Interface (CGI) applications.

The operation of these components of the data receiver Sl will now be described with reference to Figure 6, which is a flow diagram showing steps carried out by the various software modules 501, 503, 505 for an example lifecycle of a message Ml received by the data receiver. At step 601 the queue managing software 501 notes a time of receipt (to) of an incoming message Ml; stores the received message, together with its time of receipt and the identity of the message Ml (sender ID) in the message database DB1; adds the message to a message queue; and assigns an initial status to the message (S1 - meaning message freshly received). Assuming the message queue to be ordered such that the latest received message is at the front of the queue, this received message Ml will be placed at the front (a first in- first out (FIFO) queue could alternatively be used). At step 603 the status software 505 checks for the presence of request messages; for illustration purposes, it is assumed that at least one monitor terminal has sent a request for messages, which, as described above, includes data indicative of the acceptance or otherwise of previously monitored messages.

Since the status software 505 checks for data received from the monitor terminals 201a, 201b, 201c at regular intervals, and the queue managing software 501 operates both in response to receipt of messages into the data receiver Sl and in response to data from the status software 505, it will be appreciated that the steps carried out by the various software modules 501, 503, 505 do not occur in series -- the receiving of messages, checking for status and allocating of messages to a monitor terminal can all occur in parallel. In particular, the skilled person will realize that periodic checks for any request messages can occur independently of specific checks for request messages in relation to individual messages.

At step 605 the status software 505 identifies both the monitor terminal from which the request was received and the processed messages included in the request, together with their respective acceptance data, and modifies (step 607) the attributes associated with the processed messages (attributes having been stored and updated in the database DBI at step 601). For each processed message, this has the elleet of removing the message from the queue (step 609).

3() In the event that the acceptance data indicate that the message should be rejected, the sender of the message is sent a message indicating that his message will not be published (step 608a), and in the event that the acceptance data indicate that the message has been accepted by the monitor, the message is sent to the publisher module 203 (step 608b).

Next, the message allocating software 503 allocates (step 611) messages to the monitor terminal identified at step 605; since, in this example, the message Ml rcccivcd at step 601 is at, or close to, the top of the queue, this message Ml is allocated at step 611 (it will be appreciated that in general, several (a configurable number of) messages are allocated to a monitor at a time). The message allocating software 503 also stores a time (ten) at which the message Ml is allocated to a monitor terminal (step 613) and the status software 505 modifies (step 615) the status to indicate that the message Ml has been allocated to a monitor terminal (status set to S4, meaning that the message M1 is unavailable for allocation to another monitor terminal).

In addition to receiving and processing request messages from the monitor terminals, the status software 505 is arranged to compare (shown in Figure 6 as step 616) the elapsed time since message Ml was allocated to a monitor terminal (t-tn,on). If the elapsed time exceeds a specified time interval (tS), and no request message has been sent from the monitor terminal to whom the message M I was allocated at step 611, the status software 505 is arranged to modify (step 617) the status of that message such that it will be available for re allocation to a different monitor terminal (status set to S2). If, on the other hand, a request message is available, it is processed as per steps 607 - 609, so that the message M1 is either passed onto the publisher 203 or a reporting message is sent to the sender of the message Ml.

The skilled person will realize that, when the publisher 203 comprises a plurality of publishing processing modules, as shown in Figure 4, subsequent allocation of the accepted messages (step 608b) to a respective publishing processing module 203i can also be carried out in accordance with the method described above.

In a typical working environment a moderator leaves his desk (c.g. for a lunch and coffee break) at various times during the day. At these times the moderator will leave his desk before moderating his most recently allocated messages. Since, at step 616, the status software 505 checks for request messages from the monitor terminal (to which messages were allocated at step 611) after a specified elapsed time, and since these breaks will most likely last longer than this elapsed time, these messages will he marked available (step 617) and subsequently re-allocated to another monitor terminal. Thus if a moderator fails to submit a timely request message there are two outcomes: firstly messages originally allocated to his monitor terminal will be reallocated to another monitor terminal and secondly the monitor terminal will not be allocated any further messages for moderation (until such a time as he submits a request message).

Thus in this embodiment, all decision making relating to the allocation of messages is performed by the data receiver, and the monitor terminals 201a, 201b, 201c need only to be configured with functionality to request and review messages. This means that each monitor terminal 201 can be configuecd with a minimum specification of hardware, and is relatively cheap. In addition, since the data receiver S1 makes decisions about message statuses, with or without input from the monitor terminal, the monitor terminal is burdened with very little responsibility to report or even process messages. This embodiment is thus a type of self-organising system.

For those messages that have been re-allocated to another monitor terminal, if the monitor terminal to whom the messages were initially allocated subsequently submits a request (e.g. upon returning from lunch), which includes acceptance data in respect of messages that have since been re-allocated, the status software 505 simply ignores the acceptance data accompanying this request (provided one of the other monitor terminals has successfully processed it).

As described above with reference to Figure 6, messages are allocated to a monitoring processing module 201a, 201b... and displayed by the monitor terminal under control of displaying software 301. An example of an interface 801 invoked by the displaying software 301 is shown m Figure 8. Messages M11, M12, M13... allocated to this monitor terminal are displayed in window 802 of the interface; messages can be marked one at a time (each message can be marked as "accepted" or rejected" by means of buttons 803, 805), or they can be bulk-processed (a selection of messages M 11, M 13, M 16 can be highlighted, and "accept selected"/"reject selected" buttons 807, 809 can be pressed, causing all highlighted messages to be marked in accordance with whichever of buttons 807, 809 was pressed). Clicking on a "Get Messages" button 811 causes the tagging software 301 to tag the messages according to the user markings, whereupon the message requesting software 305 transmits a request message to the data receiver Sl (the get request including both acceptance data in respect of the messages Ml l, M12, M13... and a request for new messages).

To aid the user in accepting/rejecting messages, displaying software 301 can vary the way in which messages are displayed in dependence on the identity of the sender (e.g. different formats or colours could be applied to a message).

The message allocating software 503, when allocating a message to a monitor terminal, can be arranged to identify whether the sender ID associated with the message corresponds to a sender that has previouslysent a message, and if so, whether that message has been accepted for broadcast. If this is the case, the allocating software 503 can assign a flag to the message, which will be interpreted by the displaying software 301 in accordance with a predetermined mapping, and the message displayed in a particular format (several different flags are possible, each having a different meaning). For example, if a message is received from a sender whose message(s) have already been accepted for broadcast, and if the current publishing policy is such that messages from individual senders should only be broadcast a maximum of 5 times in a week, the 6'i' message that week can be displayed in red, indicating to the user associated with this monitor terminal that he should not accept this message.

The second embodiment of the data receiver Sl will now be described with reference to Figures 3b and 7, concentrating specifically on any differences with the first embodiment. As described above, each monitor terminal 201a, 201b, 201c is configured with message counting software 307, which sends, to the data receiver S 1, data indicative of a number of messages yet to be processed by the monitor terminal. Thus, when a new message is received by the data receiver S1, in this embodiment the message allocating software 503 applies a load balancing algorithm to decide on message allocation. Furthermore, in contrast to the first embodiment, status and acceptance data are not stored centrally in a data store DB1 associated with the data receiver S1; instead, each monitor terminal 201a, 201b, 201c... stores messages allocated thereto locally, together with the acceptance data associated therewith (assigned by the tagging software 303 as described above), and automatically sends those messages that have been accepted to the publisher 203. In addition, in the event that a message is rejected, each monitor terminal is arranged to send out rejection messages to the sender of the message. Thus in contrast to the first embodiment the monitor terminals are arranged to carry more of the message processing load than in the first embodiment.

A further aspect of the invention will now be described, which relates to aspects of tracking how received messages are handled. For convenience this aspect will be described in the context of the first embodiment, with reference to Figure 4. As described above, attributes of the message M 1 are stored pro- and post-moderation, and these attributes include: sender message ID (ID); message content (ContentOriginal); time of receipt (to) of message M1 by the data receiver S1; time of allocation (tn,o,,) to a monitor terminal; monitor ID of monitoring module to which the message M1 was allocated (201i); time at which acceptance data received (tn,on ad) from allocated monitor terminal; message content as received from monitor terminal (ContentMonitor); time at which rejection message (to,,,, rag) message sent out; time at which message allocated to publisher (tp,,b); publisher ID of publishing module to whicl1 the message M1 was allocated (203i); time at which acceptance data were received from allocated publisher (tpub ad); message content as received from publisher (ContentPublisher); time at which rejection message (tpub ret) message was sent out; and time at which message was sent to video signal processing module (ted). Some of these attributes are mutually exclusive - if a rejection message is sent out then the message will not be forwarded to the next processing stage.

Storing event-dependent temporal details enables real-time tracking of message handling while also providing a means of selecting a message to send to the customer that informs the customer of where, in the message handling process, a given message has been rejected (or accepted).

The skilled person will also realize that, for descriptive purposes, the software modules 301, 303, 305, 501, 503, 505 are presented as functional units, and that they could alternatively comprise several modules, or could be combined into a single module.

Whilst in the above description the first and second embodiments are described as being operationally distinct from one another, the skilled person will realize that a further embodiment, implementing a combination of message counting and message requesting software 305, 307, is possible.

The above embodiments arc to be understood as illustrative examples of the invention. Further embodiments of the invention are envisaged. For example, whilst in the above embodiments the data receiver S1 and the message processing system S2 are logically and physically separated from one another, it will be appreciated that they can he logically and/or physically combined.

It is to be understood that any feature described in relation to any one embodiment may he used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments.

Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims (1)

1. Claims I. A method of generating a video signal comprising: processing a

   plurality of messages so as to derive content therefrom; generating a video signal comprising said derived content; and broadcasting the generated video signal, characterized by: providing two or more data processing modules, each data processing module being for use in said processing of the messages; identifying processing capacity in respect of said two or more data processing modules; and allocating the messages among the data processing modules, for processing thereby, in accordance with said identified processing capacity.

   2. A method according to claim 1, in which the step of identifying the processing capacity includes monitoring for processing requests from said data processing modules.

   3. A method according to claim 2, in which said messages are allocated among said data processing modules in accordance with a frequency at which said processing requests are received.

   4. A method according to claim 1, in which, for each data processing module, the step of identifying the processing capacity includes receiving data identifying a number of messages currently stored for processing thereby.

   5. A method according to claim I or claim 4, in which said allocating step includes distributing the messages such that the processing of said messages is substantially shared among said data processing modules.

   6. A method according to any one of the preceding claims including identifying, from the message, a sender thereof, and storing data in respect of the sender.

   7. A method according to claim 6, including comparing the data associated with the identified sender with sender data associated with previously received messages, and, if the identified sender is one from whom a message has not previously been received, the method includes associating first format data with the message.

   8. A method according to claim 6 or claim 7, including comparing the data associated with the identified sender with sender data associated with previously received messages, and, if the identified sender is one from whom a message has previously been received, the method includes associating second format data with the message.

   9. A method according to claim 7 or claim 8, in which the allocation step includes sending associated format data with the message, said format data being for use by the processing module in distinguishing senders of the message.

   10. A method according to any one of claims 6 to 9, including sending a billing message to the sender of the message, said billing message having a content dependent on whether the message has been discarded or included in the generated video signal.

   l l. A method according to any one of the preceding claims, including invoking a billing event in response to receipt of the message, said billing event being dependent on whether the message has been discarded or included in the generated video signal.

   12. A method according to any one of the preceding claims, in which the generated video signal is a television signal.

   13. A method according to any one of the preceding claims, in which the generated video signal is a streamed video signal.

   14. A method according to any one of the preceding claims, in which the messages include any one of Short Messaging Service messages, Multimedia Messaging Service messages and/or email messages.

   15. A method of processing messages received from one or more terminals for use in generating a video signal, the method comprising processing the messages so as to derive content therefrom; generating a video signal comprising said derived content; and broadcasting the generated video signal, characterized in that the step of processing the messages includes: assigning one of a plurality of assignable statuses to the message; allocating the message to one of a plurality of processing modules in accordance with a time of receipt thereof; and after a specified time period, reviewing the status of the message, said reviewing including checking for data from the processing module to which the message was allocated in order to ascertain whether the message should be retained for subsequent re-allocation to a processing module.

   16. A method according to claim 15, in which said steps of allocating a message to a processing module and reviewing the status thereof occur independently of one another.

   17. A method according to claim 15 or claim 16, in which a specified plurality of messages is allocated to a processing module In response to a request therefrom.

   518. A method according to claim 17, in which said request includes acceptance data in respect of a previously allocated one or more messages.

   19. A method according to any one of claim 15 to claim 18, in which, in the event that the step of checking for data identifies there to be no data, the 10message is retained for subsequent re-allocation to a processing module.

   20. A method according to any one claim 15 to claim 19, in which the messages are ordered such that messages having a latest time of receipt are allocated first.

   21. A method according to any one of claim 15 to claim 20, in which, of those messages whose status data indicate that they are available for allocation or re-allocation, each processing module is allocated identical one or more messages.

   22. A method according to any one of claim 15 to claim 20, in which, of those messages whose status data indicate that they are available for allocation or re-allocation, each processing module is allocated different one or more messages 23. A method according to any one of claim 15 to claim 22, in which, in the event that it is ascertained that the message is not to be re- allocated, said step of checking for data includes identifying whether the message is to be discarded or retained for use in said step of generating the video signal.

   24. A message allocation system for allocating messages to one of a plurality of data processing modules, each data processing module being arranged to display messages for selection therefrom, selected messages being for use in generating a video signal, the system comprising: a message receiver arranged to receive a plurality of messages; a data receiver arranged to receive data indicative of processing capacities of said plurality of data processing modules; a message allocator software module arranged to allocate the messages among the data processing modules in accordance with the identified processing I O capacity.

   26. A message allocation system according to claim 25, wherein the message allocator software module is arranged to allocate the messages in accordance with a frequency with which the respective data processing modules submit a request for messages.

   27. A message processing system for use in generating a video signal comprlsmg: a message allocation system according to any one of claim 25 or claim 26; a plurality of data processing modules each arranged to receive messages allocated thereto from the message allocation system and to display content associated with said received messages for selection therefrom and to output data indicative of selected messages; and a data converter arranged to convert the selected messages into a video format suitable for transmission over a broadcast network.