METHOD AND SYSTEM FOR TRANSMITTING BROADCAST RELATED DATA TO A MOBILE DATA PROCESSING UNIT

5

1. Technical field

The present invention relates to methods and devices for transmitting data to a mobile data processing unit. 0

2. The prior art

Mobile data processing units such as hand held computers, PDAs, intelligent mobile telephones, etc. become more and more popular. One reason is that the mul- 5 timedia capabilities of these devices are constantly increasing. For examples mobile telephones nowadays include a wide variety of functions which exceed the basic necessities of telecommunication.

One additional use of a mobile phone is related to the reception of television sig- 0 nals. More and more broadcasting stations offer added content to be displayed on a mobile phone, which is in one way or the other related to a TV program presently broadcast from the station. The additional content may for example comprise further information concerning a current sports events or the option to download a song, which is presently performed by an artist in a show of the TV 5 program.

In order to transmit the necessary data for the additional content, it is known in the prior art, for example from the WO 2004/088983, the WO 03/088027 and the WO

03/088655, to provide a set top box or the like for receiving digital data, which 0 comprise a convoluted television /audio signal and additional data for the added

content. The additional data are separated from the television signal and in a wireless manner, following for example the Bluetooth standard, transmitted from the set top box to a PDA or to a mobile telephone to become accessible to a user.

However, in the mentioned prior art systems the reception of the additional content is limited to users, who receive the TV program with a set top box, which is adapted to retrieve the additional data from the data carousel of the digital television / audio program and to forward it to the mobile processing unit. If the added content is to be made accessible for a wider part of the population, other technical solutions are necessary.

Under "www.joca.tv" a method is described, wherein additional content relating among others to current TV programs is transmitted to a mobile phone using a GPRS network. However, no detailed information is presented, how the flow of the additional data is controlled. The control of the flow of data is important, since there are inherently two conflicting objectives. On the one hand, the provider of the additional data, for example a TV channel provider, may want to influence the content to be displayed on the mobile unit of the user. On the other hand, the user of the mobile unit himself wants to keep control, whether and which data are to be displayed on the mobile unit, preferably in a somewhat similar manner as browsing on the internet.

It is therefore the technical problem of the present invention to provide an improved method and devices for transmitting additional data relating to a TV pro- gram or the like to a mobile data processing unit without the use of a set top box, which provides the provider of the additional data and the user of the mobile unit with balanced possibilities to determine, which data are actually transmitted to the mobile unit.

3. Summary of the invention

According to one aspect of the invention, this problem is solved by a method for transmitting data to a mobile data processing unit, comprising the steps of

providing a content repository with data relating to television and / or audio broadcasts of at least one channel provider; and

transmitting data from the content repository to the mobile data processing unit via a TCP server and a wireless network;

wherein the data are transmitted from the TCP server to the mobile data processing unit in response to periodical requests from the mobile data processing unit to the TCP server.

Accordingly, the method of the present invention does not use a single push or pull process to transmit additional data to the mobile processing unit. On the contrary, since the mobile processing unit issues periodical requests to the TCP server, changing responses of the TCP server due to changing data in the content repository will lead to new data being sent to the mobile data processing unit. The data eventually processed and displayed by the mobile processing unit may therefore be both, data requested by the user but also data which a TV channel provider wants to be received, such as an important message, which is accordingly stored in the content repository and forwarded via the TCP server in response to the next request from the mobile station. The invention therefore provides effectively a split of the control of the data sent to the mobile processing unit between the channel provider and the user.

In a preferred embodiment, at least one of the periodical requests of the mobile data processing unit to the TCP server comprises an indication of the at least one channel provider. This is, since the content repository may contain data for the

added content of more than one channel provider. Preferably, the periodical requests from the mobile data processing unit serve to synchronize at least a part of the data in the mobile data processing unit with a set of new data stored by the channel provider in the content repository. To this end, the data stored by the channel provider in the content repository comprises preferably a path indication for the TCP server indicating a path to the data to be synchronized and / or an indication whether synchronization with the mobile data processing unit is to be performed. As a result, the whole process is preferably driven by the data files stored in the content repository for the one or more channel providers.

In a presently preferred embodiment, the method comprises the further step of transmitting one or more content files from the content repository to the mobile data processing unit via an HTTP server in response to a content request from the mobile data processing unit. The address of the HTTP server for content requests is preferably sent from the TCP server to the mobile data processing unit in response to a request from the mobile data processing unit initiating a connection to the TCP server. As a result, the TCP server defines preferably the context of the additional data to be transmitted to the mobile processing unit, such as configuration data relating to a specific channel provider, whereas the HTTP server delivers content for the respective context.

According to a further aspect, the present invention relates to a mobile data processing unit comprising a transceiver unit for communication with a wireless, preferably packet oriented network, control means with instructions for the transceiver unit to periodically transmit a request to a TCP server for synchronizing data in the mobile data processing unit via the TCP server with data stored by at least one channel provider of television and / or audio broadcasts in a content repository.

The control means, preferably a kind of browser software running on the mobile processing unit, allow a user to process the additional content provided by a chan-

nel provider, without any changes to his television equipment. A set top box, in particular a set top box adapted to process additional data, is not required.

In a particular preferred embodiment, the control means further comprise instruc- tions for transmitting a LOCK request from the mobile data processing unit to the TCP server indicating that the mobile data processing unit is not prepared to be synchronized with new data. Using the LOCK request is a further way how the user can control the flow of data to his mobile processing unit, for example to finish a certain application, before new content is displayed.

Finally, the present invention relates to a system for transmitting data to a mobile data processing unit, in particular for performing any of the above described methods, comprising a content repository with data relating to television and / or audio broadcasts of at least one channel provider, a TCP server transmitting data from the content repository to the mobile data processing unit via a wireless network, wherein the TCP server is adapted to transmit the data to the mobile data processing unit in response to receiving periodical requests from the mobile data processing unit.

Further preferred embodiments of the method, the mobile processing unit and the system are the subject matter of further dependent claims.

4. Short description of the drawing

In the following detailed description presently preferred embodiments of the invention are described with reference to the drawing which shows:

Fig. 1 : A schematic overview of a system in accordance with a presently preferred embodiment of the invention.

5. Detailed description of preferred embodiments

Fig. 1 presents a schematic overview of a system in accordance with a presently preferred embodiment. As can be seen, there are three TV channel providers 1, 2, 3, which are compiling programs to be broadcast. As indicated by the dashed line in Fig. 1, the programs are forwarded to a common playout center or head end 10, which broadcasts the received programs via a satellite (not shown). The various TV channel providers 1, 2 and 3 may use more than one playout center for the broadcast of their programs. Further, alternatively to broadcasting via a satellite, the TV channel providers may use a cable network (not shown) or a terrestrial broadcasting system (not shown), all of which may broadcast TV programs either in a digital or analog manner. A user in his home 20 can receive the programs with a suitable television set 21, which may or may not include a set top box (not shown).

In addition to compiling the TV programs, the TV channel providers 1, 2, 3 are preparing data files for additional content to be displayed on a mobile processing unit 60 together with broadcasting a certain TV program. The data files are for example in XML or HTML format and are sent to a content repository 30, which preferably comprises one or more file servers. As indicated in Fig. 1, the data files may be transferred to the content repository 30 using a conventional data link, for example over the Internet using the FTP protocol. The data files of the various TV channel providers 1, 2, 3 are preferably stored in separate sections 31, 32, 33 of the content repository 30, as schematically indicated in Fig. 1.

Preferably, each channel provider 1, 2, 3 can only access its own section 31, 32, 33 of the content repository 30 for updating the stored data files. Fig. 1 shows an exemplary tree structure for arranging the data files in HTML format in the content repository 30. However, alternative ways of arranging the data files, for ex- ample without a common root, are also conceivable. Further, there may be a plurality of content repositories, for example one for each TV channel provider.

In the preferred embodiment schematically shown in Fig. 1 two servers are provided, namely the TCP server 40 and the HTTP server 50, which are used to transmit the data files from the content repository 30 to a mobile processing unit 60 of a user. In the following the TCP server 40 and its service will at first be described before the function of the HTTP server 50 is further discussed.

The TCP server 40 is responsible to keep the mobile processing unit 60 synchronized with data in the content repository 30. To this end, it is connected to the Internet and thereby via a gateway 70 to a wireless communication network 80 following for example the GPRS or the UMTS standard. The service provided by the TCP server 40 is driven by the content updates triggered by the respective TV channel provider 1, 2, 3 on the one hand and the current request of each connected mobile processing unit 60 on the other hand. Since there might be a very large number of mobile processing units 60 simultaneously connected as clients, the TCP server 40 is preferably able to handle a great amount of parallel connections using well-known IP techniques such as multicast. This is particular important in case of a so-called hot synchronization, i.e. an update of a certain page, which is to be transmitted to all connected mobile processing units (for example 100000) in a short time.

In general, the communication between the TCP server 40 and each connected mobile processing unit 60 is similar to the communication between a set top box and a mobile processing unit as described in the co-pending PCT-application PCT/EP2005/010961 of applicant of the present application.

The Interface Protocol between the TCP server 40 and the connected mobile processing unit 60 is preferably based on the XML file format. In order to keep the amount of protocol data as small as possible, it is recommended to use the XML short-form for building the XML protocol. To set up a connection between the connected mobile processing unit 60 and the TCP server 40, the mobile process-

ing unit 60 needs to be connected to the Internet. This can be achieved by using the gateway 70 of a preferably packet-oriented wireless communication network 80, like the GPRS or UMTS network mentioned above. At first, a communication software of the connected mobile processing unit 60, the "browser", is started. After launching the browser, it verifies whether the network connection 80 of the mobile processing unit 60 is enabled and ready. If not, the browser will advice the user how to get connected to the network 80 and thereby to the gateway 70. Further, if the mobile processing unit has already another TCP connection running, this connection is preferably terminated before connecting to the TCP server 40.

In one embodiment, the browser has a built-in URL, which identifies how the communication is initialized. This link may differ from browser to browser. The link codes access to the HTTP-server 50 (or another server) which delivers an initial HTM-file "portal.htm", as schematically shown in Fig. 1. This data file of the content repository is outside of any specific context, i.e. it is not related to any specific TV channel providers. The initial Portal Page comprises one or more links that allow the user the selection and the synchronization with different contexts, i.e. one of the TV-channel providers 1, 2 or 3.

In a next step, the browser tries to set up a connection to the TCP server 40. Depending on its configuration, it might be necessary to enter an authentication id (PIN) to get connected. After successfully connecting to the TCP server 40, the browser preferably sends an initial request to the TCP server 40, which preferably includes and identification of the context, i.e. the specific TV channel provider, the additional content of which the user wants to receive. Additionally, there might be an authentication step, wherein a copyright string sent from the mobile processing unit 60 is compared with a stored counterpart on the side of the TCP server 40. The copyright string is a static text string that can be defined by the system provider.

After successful connection, the TCP server 40 sends one or more configuration parameters to the mobile processing unit 60, including the address of the HTTP server 50 for future content requests from the mobile processing unit 60, which are discussed further below. Each TCP service provided by the TCP server 40 knows its HTTP content server 50 by configuration.

Once a connection between the mobile processing unit 60 and the TCP server 40 has been established, the operation of the TCP service provided by the server 40 is triggered by two sides: On the one side, there is the browser that sends a REFRESH, SYNC or LOCK command as described below. On the other side, there are the data files in the content repository that are updated at any time by the TV channel provider. The overall process is preferably as follows:

Besides the content files, the TV channel provider supplies preferably a control file that carries two control parameters for the TCP-Service: the SyncPagePath and an indicator whether a synchronization is forced (for a so called Hot-Page) or not. The TV channel provider may initiate the update of the content and / or any control file, by sending an additional (empty) trigger file to the content repository

30. The TCP-Service of the server 40 tracks the presence of this trigger file. As soon as the trigger file appears, the service evaluates updates of the content for every connected browser based on the following requests previously received from the respective mobile processing station 60:

LOCK If a browser has sent a LOCK-Request, it is not interested in any update so no response has to be generated by the TCP-Service.

SYNC

With the SYNC-Request, the browser informs the TCP-Service about his last known page for synchronization, which may be different from the page currently displayed. If a content update is triggered, the TCP service of the server 40 checks

whether the synchronization page is still correct by evaluating the SyncPagePath which is indicated within the control file. If the SyncPagePath is different from the one of the synchronization page previously requested by the browser, the service generates a so-called SyncResponse and informs the browser about the cor- rect synchronization page indicated in the recently updated control file. If the SyncPagePath is equal, the service evaluates if the synchronization page was updated from the TV channel provider by comparing the page version known by the browser with the version present in the content repository. If the two version numbers are different, the service informs the browser that the synchronization page was updated.

REFRESH

With the REFRESH-Request, the browser informs the TCP-server about its last known synchronization page and the actually displayed page, which may differ. If a content update is triggered, the service of the TCP server 40 checks whether the synchronization page is still correct by evaluating the SyncPagePath within the control file. If the SyncPagePath is different and a so-called force parameter in the control file is set, the service generates a RefreshResponse and informs the browser about the (Hot) synchronization page that needs to be displayed. If the Sync- PagePath is equal or the force parameter is not set, the service compares the page version of the currently displayed page indicated by the browser with one present in the content repository. If different, the service informs the browser that the page was updated.

In general, if a content update was triggered but no condition was met that generated a response, the service of the TCP server 40 waits for the next content update in the content repository 30. If a response was generated, the service of the TCP server 40 waits for the next browser request. As soon as all browser connections have been served, the trigger file is deleted by the TCP-server. If several TCP- servers look at the same content repository, e.g. for load balancing reasons, the deletion of the trigger-file needs be a synchronized action.

In the following the content retrieval of the browser using the HTTP server 50 is further described:

The HTTP-server 50 is responsible to deliver content from the content repository 30 if requested by a mobile processing unit 60. The HTTP-server 50 is connected to the Internet and listens to HTTP -Requests, which are in the correct protocol. A single HTTP-server 50 can have access to and deliver content from several content repositories 30. Further, similar to the TCP server, the HTTP-server is able to deliver content to all clients (e.g. 100000) in a given context in short time. Again, this can be achieved by techniques such as load balancing on a hard- or software basis and IP techniques such as multicast.

Content is requested via a GetCommand from an HTTP-server, which is similar to the GetCommand described in the above mentioned co-pending PCT application of applicant. However, the command is extended, wherein the extension allows the delivery of multiple files. The HTTP-server 50 that delivers the content is either identified by an initial, built-in URL in the browser or - if the user already decided to enter a specific context - the URL delivered during setup of the TCP- connection.

With every GetRequest, the browser of the mobile processing unit 60 preferably also sends the context, i.e. the TV provider channel, the additional content of which is requested. The HTTP-server 50 determines the requested file(s) by re- solving the paths based on the context information and its configuration, so that the files are picked from the correct section of the content repository 30. For files, which are not connected to a specific context (for example an initial HTML-page), the HTTP-server supports also a "no context" specific path.

The service of the HTTP server 50 only delivers files that are triggered as updated by the provider to ensure consistency of the content repository and the TCP Ser-

vice Logic. In one embodiment this is achieved as follows: As soon as the TCP- Service detects the presence of an update trigger file, it writes/updates an empty content trigger file. For every requested file, the HTTP-server 50 compares the timestamp of the file (this is the file version...) with the one of the content trigger file. If the requested file is younger than the content trigger, the file is not delivered because the provider has not yet triggered the update. The HTTP-service answers the browser's request with a result code "data not yet available" instead of delivering the file.

The data sent from the HTTP 50 server to the mobile processing unit 60 are preferably in encrypted form in order to avoid the reception by non-intended third parties.

Finally, each mobile processing unit 60 has preferably a built-in timeout for active connections which is normally a few minutes. To keep a TCP-connection alive, the TCP-server 40 sends a few bytes conforming to the specific protocol every minute to each connected browser. If the TCP-server 40 is too busy to send these bytes, the browser may close the connection.

The method and system described in the present application might be combined with the method and system for transmitting data to a mobile data processing unit described in the above mentioned PCT-application PCT/EP2005/010961 of applicant of the present application. As can be seen in Fig. 1 , there is preferably a connection between the head end 10 and the content repository 30. Accordingly, the head end 10 can obtain the additional content in the content repository 30 to create a convoluted signal comprising digital television and / or audio signals combined with the additional content, which can then be retrieved by a set top box (not shown) and forwarded to a mobile processing unit 60 using the techniques described in the above mentioned co-pending application of applicant. As a result, two transport mechanisms can alternatively or simultaneously be used to transmit the additional content to the mobile processing unit 60 of a user, who may receive

the additional data either from a suitably adapted set top box or directly over the air, i.e. using the servers 40 and 50, the Internet and the wireless network 80.