WO2008025924A1 - Systeme de synchronisation d'informations avec un flux - Google Patents

Systeme de synchronisation d'informations avec un flux Download PDF

Info

Publication number
WO2008025924A1
WO2008025924A1 PCT/FR2007/051839 FR2007051839W WO2008025924A1 WO 2008025924 A1 WO2008025924 A1 WO 2008025924A1 FR 2007051839 W FR2007051839 W FR 2007051839W WO 2008025924 A1 WO2008025924 A1 WO 2008025924A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
stream
server
message
information data
Prior art date
Application number
PCT/FR2007/051839
Other languages
English (en)
Inventor
Laura Carlier
Vincent Teze
François Toutain
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2008025924A1 publication Critical patent/WO2008025924A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/242—Synchronization processes, e.g. processing of PCR [Program Clock References]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
    • H04N21/8133—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts specifically related to the content, e.g. biography of the actors in a movie, detailed information about an article seen in a video program
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications

Definitions

  • the present invention relates to the general field of the broadcast of an information flow in a telecommunications network, this network can be of any type and in particular of "circuit switching" or "packet switching” type.
  • the invention relates more particularly to the technologies making it possible to propose to a user information related to the content of this stream, as well as a choice of actions associated with this information, without disturbing the original broadcasted stream.
  • the exchanges thus established are set up within the framework of a telecommunications network.
  • the invention relates to a control method comprising:
  • control system comprising:
  • An event may in particular be constituted by a new question in a game show, a particular sporting event or the elimination of a candidate in a reality show, that is to say, be directly linked to the content of the stream broadcast.
  • an event can also be linked to flow control elements, for example for its broadcast (start of stream broadcasting, interruption, pause, etc.).
  • the invention does not presume how events are detected. This detection can be human (action of a technician), especially in the case of a stream broadcast live, or automatic
  • information data designates both information elements on the broadcast stream, such as, for example, information on the actors when this stream is a movie, and choices of actions associated with the stream. , such as the possibility for a user to answer questions posed to the candidate of a game show.
  • the invention does not presume the form that can take this information data (web page, SMS, ).
  • These method and control system are therefore adapted to synchronize an established communication with the terminal of a user, and a stream broadcast at the same time by a broadcast server and likely to be received by the user.
  • This synchronization makes it possible to offer the user information of multiple and relevant types related to the semantic content or control of the broadcast stream.
  • the step of verifying the activity of the stream before sending the data to the user ensures that this information is related to a stream still broadcast.
  • the terminal of the user receiving the information data is distinct from the receiving equipment of the broadcast stream.
  • a computer equipped with a tuner card for receiving the broadcast stream and a network card for receiving the information data may constitute a terminal or an equipment within the meaning of the invention.
  • control method in order to establish a dialogue with the user about the content of the broadcast stream, the control method according to the invention comprises:
  • control system comprises:
  • the dialogue thus established between the control system and the user is synchronized and coherent with the content of the broadcast stream, this being guaranteed by the steps of checking the validity of the message and the activity of the stream before sending the data. complementary.
  • the step of verifying the activity of the stream also makes it possible to inform the terminals of the users in the event of a technical problem, for example at the transmitting station, ie, if the stream is no longer active.
  • control method makes it possible to generate a request to an application server in response to a message from the user.
  • This process comprises:
  • control system according to the invention comprises:
  • the broadcast stream is a point-to-point stream, for example a stream broadcast on
  • the control system according to the invention also has means to verify that the broadcast stream is received by a user equipment. This check ensures that the information data sent to the user is linked to a stream not only broadcast to the user but also received by him.
  • this verification is performed by the control system by querying the broadcast server.
  • the broadcast server can ensure that the data is actually received through the exchange protocol set up with the user equipment, for example the TCP protocol. This check may allow, for example, to diagnose a bad reception of the flow by the user.
  • the control system sends in this case to the user an error message with possible setting tips to improve the reception of the flow.
  • the control system comprises means for detecting the identifier of the stream received by the user.
  • Such detection means can be used upstream to identify the stream received by a user and implement the control method for this stream for the benefit of this user.
  • the invention relates to an information method comprising:
  • a command processing step comprising one or more processing sub-steps, each processing sub-step comprising:
  • a step of generating information data related to at least part of the command a step of checking the flow activity
  • the invention also relates to an information server comprising: means for receiving a command representative of the occurrence of an event linked to a stream broadcast by a broadcast server;
  • command any type of instruction to trigger an action of the device that receives it.
  • a command can in particular be contained in a data packet, a frame or a computer file.
  • the means for sending the information data to a user are able to send the information data in the form of a web page.
  • the generation means generate the information data by using the user's preferences. This allows in particular to select or filter the information to be sent to the user according to his expectations.
  • the information method according to the invention comprises:
  • the information server comprises:
  • the information method according to the invention makes it possible to generate a request to an application server in response to a message from the user.
  • This process comprises:
  • the information server comprises, in a particular embodiment:
  • the broadcast stream is a point-to-point stream, for example a stream broadcast on
  • the information server according to the invention also has means for verifying that the broadcast stream is received by a user equipment.
  • this verification is performed by the information server by querying the broadcast server.
  • the invention relates to an event management method comprising: a step of detecting the occurrence of at least one event linked to a stream broadcast by a broadcast server;
  • the invention also aims at an event management server comprising:
  • the means for generating the command are capable of including this command in a computer file conforming to a standard of tagged language, preferably XML.
  • These method and server are therefore adapted to detect an event associated with the broadcast of the stream, for example the start of the broadcast of the stream or each question asked a candidate during the broadcast of a game show.
  • An order for the information server as mentioned above may thus contain for example an identifier (for example its name) of the order and the time at which it must be processed.
  • this command may consist of an action to be performed in association with each pair (identifier of the command, command processing time).
  • this command may be in the form of a computer file, a frame or a data packet containing several pairs
  • a command can thus for example contain all of the basic commands relating to a stream broadcast offline because perfectly determined at the time of the broadcast of the stream.
  • the event management server is co-located with the broadcast server.
  • control system comprises at least one information server and at least one event management server as briefly described above, synchronized with one another via a server.
  • NTP Network Time Protocol
  • This network synchronization allows the information server to properly interpret the commands sent by the event management server, including the elements concerning the processing times of the commands related to the events of the broadcast stream.
  • the various steps of the event management method and / or the information method are determined by computer program instructions.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a computer, this program comprising instructions adapted to the implementation of a management method. events and / or an information process.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form or in any other form desirable.
  • the invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a floppy disk or a hard disk.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • Appendix 1 is an example of a computer file in XML format that can be generated, when the stream is broadcast offline, by a method or an event management server according to the invention, in a particular embodiment;
  • - Annex 2 is a computer file in XML format that can be generated, when the stream is broadcast live, by a method or an event management server according to the invention, in a particular embodiment;
  • FIG. 1 shows a control system according to the invention in a particular embodiment
  • FIG. 2 represents, in flowchart form, the main steps of an information method according to the invention in a particular embodiment
  • FIG. 3 shows, in flowchart form, the main steps of an event management method according to the invention in a particular embodiment. Detailed description of an embodiment
  • the invention aims to provide a user receiving this stream, information data on the content of this video stream and to enable it to react on this information data.
  • the information data sent to the user is synchronized with the flow of the stream and generated in relation to particular events related to the content or control of the video stream.
  • this information data will be presented in the form of a web page.
  • This computer file conforming to the XML standard in this particular embodiment, can be written directly or filled from a more ergonomic graphical interface, typically web administration pages;
  • this correspondence is contained in a database relating to the transmission. In a variant, it can be included in the XML file generated above;
  • Some information data is generated during the broadcast (for example, in the case of a live broadcast where there is no prior knowledge of these information data), these web pages may be updated during the broadcast of the video stream.
  • This preliminary step can be carried out indifferently by the one who broadcasts the video stream or by a third party. Moreover, in the particular embodiment of the invention described here, the preferences of the user are taken into account so as to offer him information data and exchanges more relevant to his expectations.
  • This personalization data is stored in a client profile of a database.
  • the user uses a medium (for example an Internet browser) on the terminal to receive the information data.
  • a medium for example an Internet browser
  • the user connects to a particular site with a standard security mode (eg username / password or authentication using cryptography) and is offered several actions including:
  • the preceding information is available in a single database.
  • FIG. 1 represents, in its environment, a control system 40 according to the invention.
  • This control system 40 communicates:
  • a broadcast server 10 broadcasting a stream F to a device 60 of a user adapted to receive the stream F, this equipment being in this example a TV in the case of a video stream F;
  • this equipment can be including a PDA personal assistant (Personal Digital Assistant), a computer or a dual mode mobile terminal Universal Mobile Terrestrial System (UMTS) / Wireless Local Area Network (WLAN) type.
  • PDA personal assistant Personal Assistant
  • UMTS Universal Mobile Terrestrial System
  • WLAN Wireless Local Area Network
  • the routing of these two information flows to the equipment 60 and the terminal 70 takes place via a residential gateway 50.
  • the two streams are transported by two different logical channels.
  • the control system 40 comprises an event management server 20 and an information server 30, communicating with each other.
  • the event management server 20 is not co-located with the broadcast server 10.
  • the correspondence between the event management server 20 and the broadcast server 10 must be established upstream of the method implemented by the control system 40 described in the invention and stored in a database 37 relating to the transmission.
  • the event management server 20 and the broadcast server 10 may be co-located.
  • the event management server 20 has the hardware architecture of a computer. It comprises a processor 23, a read-only memory 21, a random access memory 22, communication means 24 with the broadcast server 10 as well as communication means 25 with the information server 30.
  • the ROM 21 of the event management server 20 described here comprises a computer program adapted to perform the main steps of the event management method according to the invention, these main steps being represented in the form of a flowchart on the Figure 3 described later.
  • the event management server 20 also comprises a hard disk 26 in which the computer file L is stored.
  • the information server 30 has the hardware architecture of a computer. It comprises a processor 33, a read-only memory 31, a random access memory 32, communication means 34 with the event management server 20 and communication means 35 with the user's terminal 70 or with an application server (typical a network card) not shown in the figure.
  • the read-only memory 31 of the information server 30 described here comprises a computer program adapted to perform the main steps of the information method according to the invention, these main steps being represented in the form of a flowchart in FIG. 2 described later. .
  • the information server 30 also has an interface enabling it to interrogate the databases 36 and 37, which respectively contain the data relating to the user's profile and the data relating to the transmission, generated as described previously.
  • the information server 30 In order to communicate with the event management server 20, the information server 30 "subscribes" to the event management server 20 to receive the commands relating to the events of the stream F or the broadcast broadcast F. by the broadcast server 10.
  • the user uses a personal assistant (PDA) as a terminal 70 in order to access the information on the broadcast broadcast F.
  • PDA personal assistant
  • step F12 When the user turns on his PDA 70, he launches an application called "interactive TV", through which he sends an access request to connect to the information server 30 via the Internet. Following receipt of this access request to step FlO, the information server 30 retrieves from a database 36 the client profile of the user during a step F12.
  • the user has defined the television channels to which he subscribes.
  • the information server 30 queries a remote server, not shown in Figure 1, for the list of streams broadcast on the channels to which the user is subscribed.
  • F16 it sends the user the list of programs that are then received on his television.
  • the information server 30 is adapted to detect which stream the user receives, by interrogating the broadcast server 10. Such detection means can thus enable the information server 30 to determine the identifier of the stream F and to overcome step F16.
  • the reception of this identifier during a step F18 enables the information server 30 during a step F20 to interrogate a database 37 in which there is the correspondence between the identifier of the transmission F and the identifier of the event management server 20 associated with it.
  • the information server 30 can subscribe to it during a step F22 in order to access the data related to the events of the transmission.
  • the information server 30 then positions itself in a waiting phase F31 of a command C coming from the event management server 20.
  • the main steps leading to the generation of a command C by the management server of Events 20 are now described with reference to FIG.
  • the event management server 20 After receiving the subscription request from the information server 30 during an ElO step, the event management server 20 reads the computer file L located in the hard disk 26 and containing the list of all the events and associated commands relating to the transmission during a step E12.
  • the event management server 20 Following a step E14 for detecting an EV event, which may be the work of a technician, for example, the event management server 20 generates information relating to the event in the form of one or several (N) elementary commands during a step E16.
  • N elementary commands can be contained in the same computer file or the same frame or the same data packet.
  • the sending of several basic commands in the form of a file for example consistent with the XML standard, is appropriate because the entire content of the broadcast stream is known.
  • the basic commands associated with the various events of the broadcast stream can then be compiled into a single file.
  • the event EV triggering the sending of this elementary command file is then, for example, the reception, by the event management server 20, of a signal (not shown in FIG. 1) representative of the beginning of the broadcast. of the show.
  • the start time (respectively end) of diffusion of the stream F is delimited by the ⁇ start> and ⁇ / start> tags (respectively ⁇ stop> and ⁇ / stop>).
  • the transmission start and end times are updated as a function of the actual start time of broadcast.
  • the event EV received by the event management server corresponds to the beginning of the broadcast of the game show.
  • the various elementary commands resulting from this event are associated with the different questions asked of the candidate.
  • the user is thus asked the same questions as the candidate under form of Multiple Choice Questions (MCQs), substantially at the time the question is put to the candidate during the broadcast.
  • MCIs Multiple Choice Questions
  • Each elementary command associated with each question is delimited by the ⁇ order> and ⁇ / order> tags. In each order are found
  • the moment of treatment of the elementary command is given in seconds starting from the time of beginning of diffusion, that is to say in the example described in appendix 1, 312 seconds after 17:50.
  • the synchronization between the event management server 20, the transmitter of the commands, and the information server 30, the receiver of these commands, must therefore be guaranteed so that the commands are well interpreted by the information server 30, in particular by regarding the moments of treatment.
  • the synchronization between these two servers is a network type synchronization (NTP server 80), which ensures that the time defined by one of the servers is well understood by the other.
  • NTP server 80 network type synchronization
  • the action associated with each elementary command can be defined in a database that the information server 30 will interrogate upon receipt of the command.
  • no action is associated with the various elementary commands in the command file.
  • the orders are preferably sent progressively, that is to say one by one, at the appropriate moment (decided by a technician but a priori unpredictable before the start of the broadcast ) on detection of the event associated with the instruction "now" as a time instruction.
  • each command consists of a single elementary command.
  • An example of a command XML file in the case of a live broadcast is presented in Appendix 2. It contains a single basic command and the same information as the file.
  • the start time of the transmission (delimited by the ⁇ start> and ⁇ / start> tags) is updated according to the actual start time of broadcasting of the broadcast by the broadcast server 10.
  • the end time of transmission is not specified because generally not known in the case of a broadcast broadcast.
  • the event management server 20 Before sending the basic command file to the information server 30, the event management server 20 is in charge of verifying that the stream F is always broadcast during a step E18. If this is the case, the command file is sent to the information server 30 during a step E22. Otherwise the information server 30 is notified during a step E20 the lack of diffusion of the stream F.
  • the verification of the activity of the flow F can be done in different ways, one not excluding the other:
  • the event management server 20 communicates with the broadcast server 10 regularly and at close time intervals (for example every second) to know the state of the diffusion of the stream F; - In an ad hoc way: if the time intervals are sufficiently close together, the event management server 20 can store a state variable reflecting the activity or not of the flow F and updated at each period of the verification.
  • the event management server 20 Before sending the command C to the information server 30, the event management server 20 checks the state of this variable.
  • the event management server 20 After sending the data to the information server 30 in the step E22, the event management server 20 returns to standby mode for detecting a new event in step E24.
  • the information method is implemented in the form of a computer program comprising three processes (F24): the management of a command C issued by the event management server 20 during of all the steps grouped together in F30, the management of an elementary control connected to the stream F during the set of steps grouped in F40 and the management of a response of the user 70 during the set steps grouped in F50.
  • a step F31 the information server 30 is waiting for a command C (file, frame or packet) sent by the event management server 20.
  • the command C is included in a computer file compliant with the XML format.
  • the information server 30 After receiving such a file, the information server 30 proceeds to a step F32 of reading this file and updates its list of elementary commands during a step F33. This list lists the various elementary commands contained in the C command.
  • the information server 30 then leaves a waiting state F41 of a command to separately and successively process the various elementary commands of the list in the order of their occurrences during a step F42.
  • the treatment consists of
  • the PW information data thus generated is contained in a web page.
  • This information data represents the question asked to the candidate.
  • it may also be a choice of actions offered to the user (for example, visiting the game's website, participating in a discussion forum with the previous winners of the game show, etc.).
  • the information server Before sending the PW information data thus generated, the information server performs a verification step F43 of the flow activity. This step can take place according to the following two modes, proposed as examples:
  • the information server 30 queries the event management server 20 on the activity of the stream F; the event management server sends the status of the stream ("broadcast” or "non-broadcast”) regularly to the information server 30 at frequent intervals of time. This makes it possible to update a variable representative of this state and stored at the information server 30. During the check F43, the information server accesses this variable and can then decide on the activity of the stream.
  • F44 management of the non activity of the flow It may be for example to send a message to the user to mention that this stream is no longer broadcast. If the result of the F43 test is positive then the information data
  • PW are sent to the terminal 70 of the user during a step
  • the information server 30 is also adapted to manage the messages M originating from the user 70. Thus, when a command has been processed, the information server 30 is able to receive a response to the information data already sent (step F51).
  • this response may be the selection of a response from the choice of answers offered to the user as part of a
  • the message M is valid, it is then processed by the information server 30 during a step F53 and can lead to the generation of additional information data DCI.
  • the processing of this message can also lead to the generation of a request to an application server, not shown in FIG. 1, able to process this request.
  • the information server can generate during step F53 a request for access to a server able to redirect the user to this switchboard.
  • the establishment of the communication can then be done according to the method described in document RFC3725, "Best Current Practices for Third Party Control in the Session Initiation Protocol” (wvvvv.ietf.org/rfc/rfc3725.txt ' ).
  • an error management step F54 is implemented. It may be simply to decide not to treat the message M because not in relation to the information data already sent.
  • step F55 Before sending the additional information data to the user or a request to an application server, a new check is made in step F55 to check that the flow is active. This verification can be done according to the methods described above.
  • the additional information data is sent to the user during a step F56 or the request to the application server during a step F57.
  • the information server then switches back to a standby mode of a command (F31), an event (F41) or a message from the user 70 (F51).

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Le problème est que l'interaction humaine est nécessaire pour assurer la synchronisation de l'envoie de données vers un utilisateur en relation d'un événement, comme la transmission d'un jeu télévisé. Sa résolution est basée sur un système de contrôle (40), qui comporte des moyens de détection (20) de l'occurence d'un événement (EV) lié à un flux (F) diffusé par un serveur de diffusion (10), des moyens de générations (30) de données d'information (PW) liées audit événement, des moyens de vérification de l'activité dudit flux et des moyens d'envoi desdites données d'information vers un terminal (70) d'un utilisateur.

Description

Procédé et système de synchronisation d'informations avec un flux.
Arrière-plan de l'invention
La présente invention se rapporte au domaine général de la diffusion d'un flux d'information dans un réseau de télécommunications, ce réseau pouvant être de tout type et notamment de type "commutation de circuits" ou "commutation de paquets".
L'invention concerne plus particulièrement les technologies permettant de proposer à un utilisateur des informations liées au contenu de ce flux, ainsi qu'un choix d'actions associées à ces informations, sans perturber le flux original diffusé. Les échanges ainsi établis sont mis en place dans le cadre d'un réseau de télécommunications.
Dans l'état actuel de la technique, il existe des systèmes permettant à l'utilisateur d'accéder, par exemple sur un site web, à des informations sur le contenu d'un flux diffusé, en l'occurrence une émission de télévision. En particulier, lors de la diffusion d'émissions dites de « téléréalité », le site web de l'émission offre aux spectateurs l'identité du candidat éliminé en même temps ou quasiment que celle-ci est annoncée au cours de l'émission. Les spectateurs peuvent alors se connecter sur le site web et réagir en participant à un forum de discussion, de façon synchrone ou asynchrone.
Cependant, si le serveur web est effectivement mis à jour lors du déroulement de l'émission de télé-réalité, il n'est pas garanti que les informations contenues dans cette page web soient visualisées par le spectateur durant la diffusion de l'émission. Il se peut ainsi, et il est même fortement probable, que lorsque le spectateur accède à ces données d'information sur l'émission et désire réagir par l'intermédiaire d'une session de discussion (session de « chat ») ou un SMS, l'émission ne soit plus diffusée et éventuellement les informations plus d'actualité.
Objet et résumé de l'invention
Selon un premier aspect, l'invention concerne un procédé de contrôle comportant :
- une étape de détection de l'occurrence d'au moins un événement lié à un flux diffusé par un serveur de diffusion ; - une étape de génération de données d'information liées à l'événement ;
- une étape de vérification de l'activité du flux ;
- et, si le flux est actif, une étape d'envoi des données d'information vers un terminal d'un utilisateur.
Corrélativement, l'invention concerne un système de contrôle comportant :
- des moyens de détection de l'occurrence d'au moins un événement lié à un flux diffusé par un serveur de diffusion ; - des moyens de génération de données d'information liées à l'événement ;
- des moyens de vérification de l'activité du flux ; et
- des moyens d'envoi des données d'information vers un terminal d'un utilisateur. Au sens de l'invention les « événements » sont de différents types.
Un événement peut en particulier être constitué par une nouvelle question dans un jeu télévisé, un événement sportif particulier ou l'élimination d'un candidat dans une émission de télé-réalité, c'est-à-dire être directement lié au contenu du flux diffusé. Au sens de l'invention un événement peut aussi être lié à des éléments de contrôle du flux, par exemple pour sa diffusion (démarrage de la diffusion du flux, interruption, pause,...).
L'invention ne présume pas de la façon dont on détecte les événements. Cette détection peut être humaine (action d'un technicien), notamment dans le cas d'un flux diffusé en direct, ou automatique
(reconnaissance d'un contenu dans le flux,...).
Dans ce document l'expression « données d'information » désigne aussi bien des éléments à caractère informatif sur le flux diffusé, tels que par exemple des renseignements sur les acteurs lorsque ce flux est un film, que des choix d'actions associées au flux, tels que la possibilité pour un utilisateur de répondre aux questions posées au candidat d'un jeu télévisé.
L'invention ne présume pas de la forme que peuvent prendre ces données d'information (page Web, SMS,...). Ces procédé et système de contrôle sont donc adaptés à synchroniser une communication établie avec le terminal d'un utilisateur, et un flux diffusé dans le même temps par un serveur de diffusion et susceptible d'être reçu par l'utilisateur.
Cette synchronisation permet de proposer à l'utilisateur des informations de types multiples et pertinentes en rapport avec le contenu sémantique ou le contrôle du flux diffusé.
L'étape de vérification de l'activité du flux avant envoi des données vers l'utilisateur permet de garantir que ces informations sont bien en rapport avec un flux encore diffusé.
Dans un mode particulier de réalisation de l'invention, le terminal de l'utilisateur qui reçoit les données d'information est distinct de l'équipement récepteur du flux diffusé.
Il peut aussi s'agir du même terminal ou équipement, mais dans ce cas les données d'information sont reçues dans un canal logique distinct de celui utilisé pour la réception du flux. En particulier, un ordinateur équipé d'une carte tuner pour la réception du flux diffusé et d'une carte réseau pour la réception des données d'information peut constituer un terminal ou un équipement au sens de l'invention.
Dans un mode particulier de réalisation de l'invention, afin d'établir un dialogue avec l'utilisateur à propos du contenu du flux diffusé, le procédé de contrôle selon l'invention comporte :
- une étape de réception d'un message de l'utilisateur ;
- une étape de vérification que le message reçu de l'utilisateur est en relation avec les données d'information déjà envoyées ; - si tel est le cas, une étape de génération de données complémentaires d'information liées au message de l'utilisateur ;
- une étape de vérification que le flux diffusé est actif ;
- et, si le flux est actif, une étape d'envoi des données complémentaires d'information vers un terminal de l'utilisateur. Dans un mode particulier de réalisation, le système de contrôle selon l'invention comporte :
- des moyens de réception d'un message de l'utilisateur ;
- des moyens de vérification que le message reçu de l'utilisateur est en relation avec les données d'information déjà envoyées ; et - des moyens de génération de données d'information complémentaires liées au message de l'utilisateur. Le dialogue ainsi établi entre le système de contrôle et l'utilisateur est synchronisé et cohérent avec le contenu du flux diffusé, ceci étant garanti par les étapes de vérification de la validité du message et de l'activité du flux avant l'envoi des données complémentaires. L'étape de vérification de l'activité du flux permet par ailleurs d'informer les terminaux des utilisateurs en cas de problème technique par exemple à la station d'émission, i.e., si le flux n'est plus actif.
Dans un mode particulier de réalisation, le procédé de contrôle selon l'invention permet de générer une requête vers un serveur applicatif en réponse à un message émanant de l'utilisateur. Ce procédé comporte :
- une étape de réception d'un message de l'utilisateur ;
- une étape de vérification que le message reçu de l'utilisateur est en relation avec les données d'information déjà envoyées ;
- si tel est le cas, une étape de génération d'une requête liée au message de l'utilisateur ;
- une étape de vérification que le flux diffusé est actif ;
- et, si le flux est actif, une étape d'envoi de la requête vers un serveur applicatif.
Dans un mode particulier de réalisation, le système de contrôle selon l'invention comporte :
- des moyens de réception d'un message de l'utilisateur ;
- des moyens de vérification que le message reçu de l'utilisateur est en relation avec les données d'information déjà envoyées ;
- des moyens de génération d'une requête liée au message de l'utilisateur ; et
- des moyens d'envoi de la requête vers un serveur applicatif, apte à traiter la requête.
Ces procédé et système de contrôle permettent notamment la mise en relation de l'utilisateur avec un serveur apte à rediriger cet utilisateur vers un standard téléphonique par exemple.
Dans un mode particulier de réalisation de l'invention, dans lequel le flux diffusé est un flux point à point, par exemple un flux diffusé sur
ADSL, le système de contrôle selon l'invention dispose également de moyens de vérifier que le flux diffusé est reçu par un équipement de l'utilisateur. Cette vérification permet de s'assurer que les données d'information envoyées à l'utilisateur sont bien liées à un flux non seulement diffusé vers l'utilisateur mais également reçu par lui.
Dans un mode de réalisation particulier cette vérification est réalisée par le système de contrôle en interrogeant le serveur de diffusion. Dans le cas d'un flux point à point, le serveur de diffusion peut s'assurer que les données sont effectivement reçues grâce au protocole d'échange mis en place avec l'équipement de l'utilisateur, par exemple le protocole TCP. Cette vérification peut permettre, par exemple, de diagnostiquer une mauvaise réception du flux par l'utilisateur. Dans un mode de réalisation particulier, le système de contrôle envoie dans ce cas à l'utilisateur un message d'erreur avec éventuellement des conseils de paramétrage pour améliorer la réception du flux. Dans un mode particulier de réalisation, le système de contrôle comporte des moyens de détection de l'identifiant du flux reçu par l'utilisateur.
De tels moyens de détection peuvent être utilisés en amont pour identifier le flux reçu par un utilisateur et mettre en œuvre le procédé de contrôle pour ce flux au bénéfice de cet utilisateur.
Selon un deuxième aspect, l'invention concerne un procédé d'information comportant :
- une étape de réception d'une commande représentative de l'occurrence d'un événement lié à un flux diffusé par un serveur de diffusion ;
- une étape de traitement de la commande comportant une ou plusieurs sous-étapes de traitement, chaque sous-étape de traitement comportant :
- une étape de génération de données d'information liées à une partie au moins de la commande ; - une étape de vérification de l'activité du flux ;
- et, si le flux est actif, une étape d'envoi des données d'information vers un terminal de l'utilisateur.
Corrélativement, l'invention vise également un serveur d'information comportant : - des moyens de réception d'une commande représentative de l'occurrence d'un événement lié à un flux diffusé par un serveur de diffusion ;
- des moyens de génération de données d'information liées à la commande reçue ;
- des moyens de vérification de l'activité du flux ; et
- des moyens d'envoi des données d'information générées vers un terminal d'un utilisateur.
Dans ce document on entend par « commande » tout type d'instruction permettant de déclencher une action du dispositif qui la reçoit. Ainsi une commande peut notamment être contenue dans un paquet de données, une trame ou un fichier informatique.
Préférentiellement, les moyens d'envoi des données d'information vers un utilisateur sont aptes à envoyer les données d'information sous la forme d'une page Web.
Selon un mode particulier de réalisation de l'invention, les moyens de génération génèrent les données d'information en utilisant des préférences de l'utilisateur. Ceci permet notamment de sélectionner ou de filtrer les informations à envoyer à destination de l'utilisateur en fonction de ses attentes.
Dans un mode particulier de réalisation, le procédé d'information selon l'invention comporte :
- une étape de réception d'un message de l'utilisateur ;
- une étape de vérification que le message reçu de l'utilisateur est en relation avec les données d'information déjà envoyées ;
- si tel est le cas, une étape de génération de données complémentaires d'information liées au message de l'utilisateur ;
- une étape de vérification que le flux diffusé est actif ;
- et, si le flux est actif, une étape d'envoi des données complémentaires d'information vers un terminal de l'utilisateur.
Corrélativement, dans un mode particulier de réalisation le serveur d'information comporte :
- des moyens de réception d'un message de l'utilisateur ;
- des moyens de vérification que le message reçu de l'utilisateur est en relation avec les données d'information déjà envoyées ; - des moyens de génération de données complémentaires d'information liées au message de l'utilisateur.
Dans un mode particulier de réalisation de l'invention, le procédé d'information selon l'invention permet de générer une requête vers un serveur applicatif en réponse à un message de l'utilisateur. Ce procédé comporte :
- une étape de réception d'un message de l'utilisateur ;
- une étape de vérification que le message reçu de l'utilisateur est en relation avec les données d'information déjà envoyées ; - si tel est le cas, une étape de génération d'une requête liée au message de l'utilisateur ;
- une étape de vérification que le flux diffusé est actif ;
- et, si le flux est actif, une étape d'envoi de la requête vers un serveur applicatif apte à traiter la requête. Corrélativement, le serveur d'information comporte, dans un mode particulier de réalisation :
- des moyens de réception d'un message de l'utilisateur ;
- des moyens de vérification que le message reçu de l'utilisateur est en relation avec les données d'information déjà envoyées ; - des moyens de génération d'une requête liée au message de l'utilisateur; et
- des moyens d'envoi de la requête vers un serveur applicatif, apte à traiter la requête.
Dans un mode particulier de réalisation de l'invention, dans lequel le flux diffusé est un flux point à point, par exemple un flux diffusé sur
ADSL, le serveur d'information selon l'invention dispose également de moyens de vérifier que le flux diffusé est reçu par un équipement de l'utilisateur.
Dans un mode de réalisation particulier cette vérification est réalisée par le serveur d'information en interrogeant le serveur de diffusion.
Les caractéristiques particulières et les avantages de tels serveur et procédé d'information sont identiques à ceux proposés par les système et procédé de contrôle précédemment décrits. Selon un troisième aspect, l'invention concerne un procédé de gestion d'événements comportant : - une étape de détection de l'occurrence d'au moins un événement lié à un flux diffusé par un serveur de diffusion ;
- une étape de génération d'une commande liée à cet événement ;
- une étape de vérification de l'activité du flux ; - et, si le flux est actif une étape d'envoi de la commande vers un serveur d'information.
Corrélativement, l'invention vise également un serveur de gestion d'événements comportant :
- des moyens de détection de l'occurrence d'au moins un événement lié à un flux diffusé par un serveur de diffusion ;
- des moyens de génération d'une commande liée à l'événement ;
- des moyens de vérification de l'activité du flux ; et
- des moyens d'envoi de la commande vers un serveur d'information.
Préférentiel lement, les moyens de génération de la commande sont aptes à inclure cette commande dans un fichier informatique conforme à un standard de langage à balises, préférentiel lement XML.
Ces procédé et serveur sont donc adaptés à détecter un événement associé à la diffusion du flux, par exemple le démarrage de la diffusion du flux ou chaque question posée à un candidat lors de la diffusion d'un jeu télévisé.
Une commande à destination du serveur d'information telle que mentionnée ci-dessus pourra ainsi contenir par exemple un identifiant (par exemple son nom) de la commande ainsi que le moment auquel elle doit être traitée. Dans un mode particulier de réalisation de l'invention, cette commande peut être constituée d'une action à réaliser en association avec chaque couple (identifiant de la commande, moment de traitement de la commande).
Dans un autre mode particulier de réalisation de l'invention, cette commande peut se présenter sous la forme d'un fichier informatique, d'une trame ou d'un paquet de données contenant plusieurs couples
(identifiant de la commande, moment de traitement de la commande), découlant de l'événement détecté par le serveur de gestion d'événements.
Chaque couple de cette commande sera désigné par le terme de « commande élémentaire » dans ce document. Ainsi une commande désignera indifféremment une commande élémentaire ou un ensemble de commandes élémentaires.
Une commande peut ainsi par exemple contenir l'ensemble de toutes les commandes élémentaires relatives à un flux diffusé en différé, car parfaitement déterminées au moment de la diffusion du flux.
Dans un mode particulier de réalisation de l'invention, le serveur de gestion d'événements est co-localisé avec le serveur de diffusion.
Selon un mode particulier de réalisation de l'invention, le système de contrôle comporte au moins un serveur d'information et au moins un serveur de gestion d'événements tels que décrits brièvement précédemment, synchronisés entre eux par l'intermédiaire d'un serveur
NTP (Network Time Protocol).
Cette synchronisation réseau permet au serveur d'information d'interpréter convenablement les commandes envoyées par le serveur de gestion d'événements, notamment les éléments concernant les moments de traitement des commandes liées aux événements du flux diffusé.
Selon une implémentation particulière de l'invention, les différentes étapes du procédé de gestion des événements et/ou du procédé d'information sont déterminées par des instructions de programmes d'ordinateur.
En conséquence l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre d'un procédé de gestion des événements et/ou d'un procédé d'information.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux annexes et aux dessins qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif, et dans lesquels :
- l'annexe 1 est un exemple de fichier informatique au format XML pouvant être généré, lorsque le flux est diffusé en différé, par un procédé ou un serveur de gestion d'événements conformes à l'invention, dans un mode particulier de réalisation ;
- l'annexe 2 est un de fichier informatique au format XML pouvant être généré, lorsque le flux est diffusé en direct, par un procédé ou un serveur de gestion d'événements conformes à l'invention, dans un mode particulier de réalisation ;
- la figure 1 représente un système de contrôle conforme à l'invention dans un mode particulier de réalisation ;
- la figure 2 représente, sous forme d'organigramme, les principales étapes d'un procédé d'information conforme à l'invention dans un mode particulier de réalisation ; et
- la figure 3 représente, sous forme d'organigramme, les principales étapes d'un procédé de gestion d'événements conforme à l'invention dans un mode particulier de réalisation. Description détaillée d'un mode de réalisation
La description qui va suivre est faite dans le contexte de la diffusion d'un flux vidéo, à savoir la diffusion d'un jeu télévisé pendant lequel un candidat se voit poser une liste de questions. Dans ce mode particulier de réalisation, l'invention vise à proposer à un utilisateur récepteur de ce flux, des données d'information sur le contenu de ce flux vidéo et à lui permettre de réagir sur ces données d'information.
Les données d'information envoyées vers l'utilisateur sont synchronisées avec le déroulement du flux et générées en relation avec des événements particuliers liés au contenu ou au contrôle du flux vidéo.
Dans l'exemple décrit ici, ces données d'information seront présentées sous la forme d'une page Web.
Afin de proposer ce service à l'utilisateur, il est nécessaire en amont de collecter certaines données préliminaires afin de permettre ces échanges. Cela consiste notamment, pour chaque flux, à
- identifier le serveur de diffusion du flux ;
- identifier les événements et les commandes associées (identifiant et moment de traitement de chaque commande élémentaire) contenus dans le flux susceptibles de générer un échange avec l'utilisateur et enregistrer ces événements et les commandes associées dans un fichier informatique L associé au flux. Ce fichier informatique, conforme au standard XML dans ce mode particulier de réalisation, peut être écrit directement ou rempli à partir d'une interface graphique plus ergonomique, classiquement des pages d'administration web ;
- associer à chaque commande élémentaire une action appropriée qui permettra d'identifier les données d'information à envoyer vers l'utilisateur en relation avec cette commande élémentaire. Dans l'exemple décrit ici, cette correspondance est contenue dans une base de données relative à l'émission. Dans une variante, elle peut être incluse dans le fichier XML généré ci-dessus ; et
- générer les pages ou les morceaux de pages Web qui seront affichées sur le terminal de l'utilisateur. Certaines données d'information étant générées au fil de l'émission (par exemple, dans le cas d'une émission diffusée en direct où il n'existe aucune connaissance a priori de ces données d'information), ces pages Web pourront être mises à jour au cours de la diffusion du flux vidéo.
Cette étape préliminaire peut être effectuée indifféremment par celui qui diffuse le flux vidéo ou par un tiers. Par ailleurs, dans le mode particulier de réalisation de l'invention décrit ici, les préférences de l'utilisateur sont prises en compte de manière à lui proposer des données d'information et des échanges plus pertinents par rapport à ses attentes.
Ces données de personnalisation sont stockées dans un profil client d'une base de données.
Pour rentrer ses données de personnalisation dans le système, l'utilisateur utilise un support (par exemple un navigateur Internet) se trouvant sur le terminal lui permettant de recevoir les données d'information. Dans le cas d'un navigateur Web, l'utilisateur se connecte sur un site particulier avec un mode classique de sécurité (par exemple nom d'utilisateur / mot de passe ou authentification utilisant la cryptographie) et se voit proposer plusieurs actions dont :
- choisir les chaînes de télévision sur lesquelles il souhaiterait recevoir les données d'information, par exemple les chaînes auxquelles il est abonné ;
- sélectionner un ou plusieurs types de données d'information et d'actions (par exemple, l'utilisateur peut enregistrer dans son profil qu'il ne souhaite pas participer aux tirages au sort) ; et - donner des informations sur ses préférences générales, de manière à filtrer les données d'informations qui lui seront envoyées.
Cette liste d'actions n'est en aucun cas exhaustive. Par ailleurs, l'utilisateur peut modifier son profil client en cours d'utilisation du service.
Ainsi, avant même la diffusion du flux, les informations suivantes sont disponibles dans différentes bases de données :
- correspondance entre l'identifiant d'un flux donné et l'identifiant du serveur de diffusion du flux ;
- correspondance entre une commande et les actions requises pour générer les données d'information ; et - profil client. Dans une variante de réalisation, les informations précédentes sont disponibles dans une unique base de données.
Ces informations sont destinées à être utilisées au cours des différentes étapes des procédés constituant l'invention. La figure 1 représente, dans son environnement, un système de contrôle 40 conforme à l'invention.
Ce système de contrôle 40 communique :
- d'une part, avec un serveur de diffusion 10, diffusant un flux F vers un équipement 60 d'un utilisateur adapté à recevoir le flux F, cet équipement étant dans cet exemple un téléviseur dans le cas d'un flux vidéo F ;
- d'autre part, avec un autre terminal 70 de ce même utilisateur, adapté à recevoir des flux de données d'information, cet équipement pouvant être notamment un assistant personnel PDA (Personal Digital Assistant), un ordinateur ou un terminal mobile bi mode de type UMTS (Universal Mobile Terrestrial System) / WLAN (Wireless Local Area Network).
Dans l'exemple décrit ici, l'acheminement de ces deux flux d'information vers l'équipement 60 et le terminal 70 s'effectue par l'intermédiaire d'une passerelle résidentielle 50. Les deux flux sont transportés par deux canaux logiques différents. Dans l'exemple décrit ici, le système de contrôle 40 comporte un serveur de gestion d'événements 20 et un serveur d'information 30, communiquant entre eux.
Dans le mode particulier de réalisation décrit ici, le serveur de gestion d'événements 20 n'est pas co-localisé avec le serveur de diffusion 10. La correspondance entre le serveur de gestion d'événements 20 et le serveur de diffusion 10 doit être établie en amont du procédé mis en œuvre par le système de contrôle 40 décrit dans l'invention et stockée dans une base de données 37 relative à l'émission.
En variante, le serveur de gestion d'événements 20 et le serveur de diffusion 10 peuvent être co-localisés.
Le serveur de gestion d'événements 20 a l'architecture matérielle d'un ordinateur. Il comporte un processeur 23, une mémoire morte 21, une mémoire vive 22, des moyens de communication 24 avec le serveur de diffusion 10 ainsi que des moyens de communication 25 avec le serveur d'information 30. La mémoire morte 21 du serveur de gestion d'événements 20 décrit ici comporte un programme informatique adapté à exécuter les principales étapes du procédé de gestion d'événements selon l'invention, ces principales étapes étant représentées sous la forme d'un organigramme sur la figure 3 décrite ultérieurement.
Le serveur de gestion d'événements 20 comporte également un disque dur 26 dans lequel est stocké le fichier informatique L.
Le serveur d'information 30 a l'architecture matérielle d'un ordinateur. Il comporte un processeur 33, une mémoire morte 31, une mémoire vive 32, des moyens de communication 34 avec le serveur de gestion d'événements 20 et des moyens de communication 35 avec le terminal de l'utilisateur 70 ou avec un serveur applicatif (typiquement une carte réseau) non représenté sur la figure.
La mémoire morte 31 du serveur d'information 30 décrit ici comporte un programme informatique adapté à exécuter les principales étapes du procédé d'information selon l'invention, ces principales étapes étant représentées sous la forme d'un organigramme sur la figure 2 décrite ultérieurement.
Le serveur d'information 30 dispose également d'une interface lui permettant d'interroger les bases de données 36 et 37, qui contiennent respectivement, les données relatives au profil de l'utilisateur et les données relatives à l'émission, générées comme décrit précédemment.
Afin de communiquer avec le serveur de gestion d'événements 20, le serveur d'information 30 « s'abonne » auprès du serveur de gestion d'événements 20 pour recevoir les commandes relatives aux événements du flux F ou de l'émission F diffusée par le serveur de diffusion 10.
Les principales étapes menant à ce processus d'abonnement sont décrites maintenant en référence à la figure 2 (étapes FlO à F24).
Dans l'exemple décrit, l'utilisateur utilise un assistant personnel (PDA) comme terminal 70 afin d'accéder aux informations sur l'émission diffusée F.
Lorsque l'utilisateur allume son PDA 70, il lance une application nommée « TV interactive », par le biais de laquelle il envoie une requête d'accès pour se connecter au serveur d'information 30 via Internet. Suite à la réception de cette requête d'accès à l'étape FlO, le serveur d'information 30 récupère dans une base de données 36 le profil client de l'utilisateur au cours d'une étape F12.
Dans ce profil client, comme décrit précédemment, l'utilisateur a défini les chaînes de télévision auxquelles il est abonné.
Au cours d'une étape F14, le serveur d'information 30 interroge un serveur distant, non représenté sur la figure 1, pour connaître la liste des flux diffusés sur les chaînes auxquelles l'utilisateur est abonné. A l'étape
F16, il envoie à l'utilisateur la liste des émissions qui sont reçues alors sur sa télévision.
L'utilisateur sélectionne une émission, associée à un identifiant unique, cet identifiant étant alors envoyé vers le serveur d'information 30. Dans un mode particulier de réalisation, dans lequel le flux diffusé est un flux point à point, par exemple un flux diffusé sur ADSL, le serveur d'information 30 est adapté à détecter quel flux l'utilisateur reçoit, en interrogeant le serveur de diffusion 10. De tels moyens de détection peuvent ainsi permettre au serveur d'information 30 de déterminer l'identifiant du flux F et de s'affranchir de l'étape F16.
La réception de cet identifiant au cours d'une étape F18 permet au serveur d'information 30 durant une étape F20 d'interroger une base de données 37 dans laquelle se trouve la correspondance entre l'identifiant de l'émission F et l'identifiant du serveur de gestion d'événements 20 qui lui est associé.
Une fois le serveur de gestion d'événements 20 identifié, le serveur d'information 30 peut s'abonner auprès de celui-ci au cours d'une étape F22 afin d'accéder aux données liées aux événements de l'émission.
Le serveur d'information 30 se positionne alors dans une phase d'attente F31 d'une commande C provenant du serveur de gestion d'événements 20. Les principales étapes menant à la génération d'une commande C par le serveur de gestion d'événements 20 sont maintenant décrites en référence à la figure 3.
Après avoir reçu la demande d'abonnement du serveur d'information 30 lors d'une étape ElO, le serveur de gestion d'événements 20 lit le fichier informatique L localisé dans le disque dur 26 et contenant la liste de l'ensemble des événements et commandes associées relatifs à l'émission au cours d'une étape E12.
Suite à une étape E14 de détection d'un événement EV, qui peut être l'œuvre d'un technicien par exemple, le serveur de gestion d'événements 20 génère des informations relatives à l'événement sous la forme d'une ou de plusieurs (N) commandes élémentaires au cours d'une étape E16. Ces N commandes élémentaires peuvent être contenues dans un même fichier informatique ou une même trame ou un même paquet de données. Pour une émission diffusée en différé, l'envoi de plusieurs commandes élémentaires sous la forme d'un fichier, par exemple conforme au standard XML, est approprié car la totalité du contenu du flux diffusé est connue. Les commandes élémentaires associées aux différents événements du flux diffusé peuvent alors être compilées dans un unique fichier.
L'événement EV déclencheur de l'envoi de ce fichier de commandes élémentaires est alors par exemple la réception, par le serveur de gestion d'événements 20, d'un signal (non représenté sur la figure 1) représentatif du début de la diffusion de l'émission. L'annexe 1 donne un exemple de fichier informatique conforme au standard XML contenant la liste des N=2 commandes élémentaires associées à un jeu télévisé « Qui veut gagner des sous ? » diffusé en différé sur la chaîne « francetv ». Ces commandes élémentaires sont classées par ordre d'occurrence. Pour cette diffusion en différé, l'heure de début (respectivement de fin) de diffusion du flux F est délimitée par les balises <start> et </start> (respectivement <stop> et </stop>).
Dans un mode particulier de réalisation de l'invention, les heures de début et de fin d'émission sont mises à jour en fonction de l'heure réelle de début de diffusion. Dans le mode particulier de réalisation de l'invention décrit ici, l'événement EV reçu par le serveur de gestion d'événements correspond au début de la diffusion du jeu télévisé.
Les différentes commandes élémentaires résultant de cet événement sont associées aux différentes questions posées au candidat. L'utilisateur se voit ainsi poser les mêmes questions que le candidat sous forme de QCM (Questions à Choix Multiples), sensiblement au moment où la question est posée au candidat pendant l'émission.
Chaque commande élémentaire associée à chaque question est délimitée par les balises <order> et </order>. Dans chaque commande se trouvent
- l'identifiant de la commande (délimité par les balises <name> et </name>), ici « Question_xx » où xx est le numéro de la question en cours ;
- le moment de traitement de la commande (délimité par les balises <trigger> <fromstart> et </fromstartx/trigger>) ;
- ainsi qu'éventuellement d'une action associée à cet événement (par exemple téléchargement d'une page Web,...)-
Le moment de traitement de la commande élémentaire est donnée en secondes à partir de l'heure de début de diffusion, c'est-à-dire dans l'exemple décrit en annexe 1, 312 secondes après 17h50.
La synchronisation entre le serveur de gestion d'événements 20, émetteur des commandes, et le serveur d'information 30, récepteur de ces commandes, doit donc être garantie afin que les commandes soient bien interprétées par le serveur d'information 30, notamment en ce qui concerne les moments de traitement.
Dans le mode particulier de réalisation de l'invention décrit ici, la synchronisation entre ces deux serveurs est une synchronisation de type réseau (serveur NTP 80), qui garantit que le temps défini par un des serveurs est bien compris par l'autre. Alternativement l'action associée à chaque commande élémentaire peut être définie dans une base de données que le serveur d'information 30 ira interroger sur réception de la commande. Ainsi dans l'exemple décrit dans l'annexe 1, aucune action n'est associée aux différentes commandes élémentaires dans le fichier de commandes. Dans le cas d'une émission diffusée en direct, les commandes sont préférentiel lement envoyées progressivement, c'est-à-dire une par une, au moment opportun (décidé par un technicien mais a priori non prévisible avant le début de l'émission) sur détection de l'événement associé avec comme instruction de temps l'instruction « now ». Dans ce cas chaque commande est constituée d'une seule commande élémentaire. Un exemple de fichier XML de commandes dans le cas d'une émission diffusée en direct est présenté en annexe 2. Il contient une seule commande élémentaire et les mêmes informations que le fichier
XML donné en exemple en annexe 1 pour une émission diffusée en différé, à l'exception des données de temps.
L'heure de démarrage de l'émission (délimitée par les balises <start> et </start>) est mise à jour en fonction de l'heure réelle de début de diffusion de l'émission par le serveur de diffusion 10.
L'heure de fin d'émission n'est pas précisée car généralement non connue dans le cas d'une émission diffusée en direct.
Avant d'envoyer le fichier de commandes élémentaires vers le serveur d'information 30, le serveur de gestion d'événements 20 est en charge de vérifier que le flux F est toujours diffusé au cours d'une étape E18. Si tel est le cas, le fichier de commandes est envoyé à destination du serveur d'information 30 lors d'une étape E22. Sinon le serveur d'information 30 se voit notifier au cours d'une étape E20 l'absence de diffusion du flux F.
La vérification de l'activité du flux F peut se faire de différentes manières, l'une n'excluant pas l'autre :
- de manière périodique : le serveur de gestion d'événements 20 communique avec le serveur de diffusion 10 régulièrement et à des intervalles de temps rapprochés (par exemple toutes les secondes) pour connaître l'état de la diffusion du flux F ; - de manière ponctuelle : si les intervalles de temps sont suffisamment rapprochés, le serveur de gestion d'événements 20 peut stocker une variable d'état traduisant l'activité ou non du flux F et mise à jour à chaque période de la vérification.
Avant l'envoi de la commande C vers le serveur d'information 30, le serveur de gestion d'événements 20 contrôle l'état de cette variable.
Après envoi des données vers le serveur d'information 30 au cours de l'étape E22, le serveur de gestion d'événements 20 repasse en mode d'attente de détection d'un nouvel événement à l'étape E24.
Le procédé d'information est implémenté sous la forme d'un programme informatique comportant trois processus (F24) : la gestion d'une commande C issue du serveur de gestion d'événements 20 au cours de l'ensemble des étapes regroupées dans F30, la gestion d'une commande élémentaire reliée au flux F au cours de l'ensemble des étapes regroupées dans F40 et la gestion d'une réponse de l'utilisateur 70 au cours de l'ensemble des étapes regroupées dans F50. Dans une étape F31, le serveur d'information 30 est en attente d'une commande C (fichier, trame ou paquet) envoyé par le serveur de gestion d'événements 20.
Dans l'exemple décrit ici, la commande C est incluse dans un fichier informatique conforme au format XML. Après réception d'un tel fichier, le serveur d'information 30 procède à une étape F32 de lecture de ce fichier et met à jour sa liste de commandes élémentaires lors d'une étape F33. Cette liste énumère les différentes commandes élémentaires contenues dans la commande C.
Le serveur d'information 30 quitte alors un état d'attente F41 d'une commande pour traiter séparément et successivement les différentes commandes élémentaires de la liste dans l'ordre de leurs occurrences au cours d'une étape F42.
Le traitement effectué consiste à
- interpréter la commande élémentaire ; - aller chercher dans les bases de données 36 (respectivement 37) les informations relatives au profil de l'utilisateur (respectivement relatives à l'émission, c'est-à-dire les actions associées à chaque événement) ;
- aller chercher éventuellement sur d'autres serveurs, non représentés sur la figure 1, des informations supplémentaires (par exemple des statistiques sur les réponses des candidats,...) ;
- faire le croisement des informations récoltées pour générer les données d'information PW qui seront envoyées à l'utilisateur.
Dans l'exemple décrit ici, les données d'information PW ainsi générées sont contenues dans une page Web. Ces données d'information représentent la question posée au candidat.
En variante, il peut également s'agir d'un choix d'actions offert à l'utilisateur (par exemple, visite du site web du jeu, participation à un forum de discussion avec les gagnants précédents du jeu télévisé...).
Avant d'envoyer les données d'information PW ainsi générées, le serveur d'information effectue une étape de vérification F43 de l'activité du flux. Cette étape peut se dérouler selon les deux modes suivants, proposés à titre d'exemples :
- le serveur d'information 30 interroge le serveur de gestion d'événements 20 sur l'activité du flux F ; - le serveur de gestion d'événements 20 envoie régulièrement et à des intervalles de temps rapprochés l'état du flux (« diffusé » ou « non diffusé ») au serveur d'information 30. Ceci permet la mise à jour d'une variable représentative de cet état et stockée au niveau du serveur d'information 30. Lors de la vérification F43, le serveur d'information accède à cette variable et peut alors se prononcer sur l'activité du flux.
Si le résultat du test F43 n'est pas positif, alors il s'ensuit une étape
F44 de gestion de la non activité du flux. Il peut s'agir par exemple d'envoyer un message à l'utilisateur pour lui mentionner que ce flux n'est plus diffusé. Si le résultat du test F43 est positif alors les données d'information
PW sont envoyées vers le terminal 70 de l'utilisateur au cours d'une étape
F45.
Dans l'exemple décrit ici, les étapes F43 de vérification du flux et
F45 d'envoi des données d'information PW vers le terminal 70 sont réalisées pour chaque commande élémentaire séparément, suite au traitement de la commande élémentaire correspondante effectué à l'étape
F42.
Le serveur d'information 30 est adapté également à gérer les messages M provenant de l'utilisateur 70. Ainsi lorsqu'une commande a été traitée, le serveur d'information 30 est apte à recevoir une réponse aux données d'information déjà envoyées (étape F51).
Dans l'exemple décrit ici, cette réponse peut être la sélection d'une réponse parmi le choix de réponses offert à l'utilisateur dans le cadre d'un
QCM. Lorsqu'un message M parvient au serveur d'information 30 en provenance de l'utilisateur 70, il est nécessaire d'identifier si ce message est valide au cours d'une étape F52, c'est-à-dire, si il est bien en relation avec les données d'information déjà envoyées à l'utilisateur et cohérent avec ces données. Pour cela il est nécessaire que le message M comporte un identifiant de la commande ou des données d'informations auxquelles il se rapporte.
Si le message M est valide, il est alors traité par le serveur d'information 30 lors d'une étape F53 et peut conduire à la génération de données complémentaires d'information DCI.
Le traitement de ce message peut également conduire à la génération d'une requête vers un serveur applicatif, non représenté sur la figure 1, apte à traiter cette requête. Ainsi si le message M de l'utilisateur contient une demande de mise en relation avec un standard téléphonique, le serveur d'information peut générer au cours de l'étape F53 une requête d'accès à un serveur apte à rediriger l'utilisateur vers ce standard téléphonique.
L'établissement de la communication peut alors se faire selon le procédé décrit dans le document RFC3725, « Best Current Practices for Third Party CaII Control in the Session Initiation Protocol » (wvvvv.ietf.org/rfc/rfc3725.txt').
Si le message M n'est pas considéré comme valide, alors une étape F54 de gestion de l'erreur est mise en œuvre. Il peut s'agir tout simplement de décider de ne pas traiter le message M car pas en relation avec les données d'information déjà envoyées.
Avant d'envoyer les données d'information complémentaires vers l'utilisateur ou une requête vers un serveur applicatif, une nouvelle vérification est effectuée à l'étape F55 afin de contrôler que le flux est actif. Cette vérification peut se faire selon les procédés décrits précédemment.
Si le flux est actif, alors les données complémentaires d'information sont envoyées à l'utilisateur lors d'une étape F56 ou la requête au serveur applicatif lors d'une étape F57. Le serveur d'information passe alors de nouveau dans un mode d'attente d'une commande (F31), d'un événement (F41) ou d'un message de l'utilisateur 70 (F51). ANNEXE 1
<interactive data> <id>mlkjqkfj 89875689794</id> <associated-broadcast>
<broadcasting-server>francetv . emissions</broadcasting- server>
<broadcast-file-stream>Qui veut gagner des sous?</broadcast-file-stream>
<target-server>interactive-server . domain . com</target- server>
<type-broadcast>recorded</type-broadcast> <start>Feb 3 2006, GMT+1 17h50 : 00</start> <stop>Feb 3 2006, GMT+1 18h20 : 00</stop>
<interactive-orders>
<order> <name> Question_l </name> <trigger>
<fromstart>312</fromstart> </trigger> </order> <order>
<name> Question_2 </name> <trigger>
<fromstart>1036</fromstart> </trigger> </order>
</interactive-orders> </associated-broadcast> </interactive data>
ANNEXE 2
<interactive data> <id>mlkjqkfj 89875689794</id> <associated-broadcast>
<broadcasting-server>francetv. emissions</broadcasting- server>
<broadcast-file-stream>Qui veut gagner des sous ?</broadcast-file-stream> <target-server>interactive-server . domain . com</target- server>
<type-broadcast>direct</type-broadcast> <start>Feb 3 2006, GMT+1 17h52 : 00</start>
<interactive-orders> <order> <name> Question_l </name>
<trigger> now </trigger> </order>
</interactive-orders> </associated-broadcast> </interactive data>

Claims

REVENDICATIONS
1. Système de contrôle (40) comportant, - des moyens de détection (20) de l'occurrence d'au moins un événement (EV) lié à un flux (F) diffusé par un serveur de diffusion (10);
- des moyens de génération (30) de données d'information (PW) liées audit événement (EV) ;
- des moyens de vérification (20,30) de l'activité dudit flux ; et - des moyens d'envoi (30) desdites données d'information (PW) vers un terminal (70) d'un utilisateur.
2. Système selon la revendication 1 comportant,
- des moyens de réception (30) d'un message (M) dudit utilisateur ; - des moyens de vérification (30) que ledit message (M) reçu dudit utilisateur est en relation avec les données d'information (PW) déjà envoyées ; et
- des moyens de génération (30) de données complémentaires d'information (DCI) liées audit message (M) dudit utilisateur.
3. Système selon la revendication 1 comportant,
- des moyens de réception (30) d'un message (M) dudit utilisateur ;
- des moyens de vérification (30) que ledit message (M) reçu dudit utilisateur est en relation avec les données d'information (PW) déjà envoyées ;
- des moyens de génération (30) d'une requête liée audit message (M) dudit utilisateur ; et
- des moyens d'envoi (30) de ladite requête vers un serveur applicatif apte à traiter ladite requête.
4. Système selon l'une quelconque des revendications 1 à 3 dans lequel ledit flux (F) est un flux point à point, comportant en outre des moyens de vérification (40,50) que ledit flux est reçu par un équipement (60) dudit utilisateur.
5. Procédé de contrôle comportant, - une étape (E14) de détection de l'occurrence d'au moins un événement (EV) lié à un flux diffusé (F) par un serveur de diffusion (10);
- une étape (F42) de génération de données d'information (PW) liées audit événement (EV) ; - une étape de vérification (F43, E18) de l'activité dudit flux (F) ;
- et, si ledit flux (F) est actif, une étape (F45) d'envoi desdites données d'information (PW) vers un terminal (70) d'un utilisateur.
6. Procédé de contrôle selon la revendication 5 comportant, - une étape (F51) de réception d'un message (M) dudit utilisateur ;
- une étape (F52) de vérification que ledit message (M) reçu dudit utilisateur est en relation avec les données d'information (PW) déjà envoyées ;
- si tel est le cas, une étape (F53) de génération de données complémentaires d'information (DCI) liées audit message (M) dudit utilisateur ;
- une étape de vérification (F55) que ledit flux (F) est actif ;
- et, si le flux est actif, une étape (F56) d'envoi desdites données complémentaires d'information (DCI) vers un terminal (70) dudit utilisateur.
7. Procédé de contrôle selon la revendication 5 comportant,
- une étape (F51) de réception d'un message (M) dudit utilisateur ;
- une étape (F52) de vérification que ledit message (M) reçu dudit utilisateur est en relation avec les données d'information (PW) déjà envoyées ;
- si tel est le cas, une étape (F53) de génération d'une requête liée audit message (M) dudit utilisateur ;
- une étape de vérification (F55) que ledit flux (F) est actif ; et - une étape (F57) d'envoi de ladite requête vers un serveur applicatif.
8. Serveur d'information (30) comportant,
- des moyens de réception (34) d'une commande (C) représentative de l'occurrence d'un événement (EV) lié à un flux (F) diffusé par un serveur de diffusion (10) ; - des moyens de génération (33) de données d'information (PW) liées à ladite commande (C) ;
- des moyens de vérification (33) de l'activité dudit flux ; et
- des moyens d'envoi (35) desdites données d'information (PW) vers un terminal (70) d'un utilisateur.
9. Serveur d'information (30) selon la revendication 8 comportant,
- des moyens de réception (35) d'un message (M) dudit utilisateur ; - des moyens de vérification (33) que ledit message (M) reçu dudit utilisateur est en relation avec les données d'information (PW) déjà envoyées ; et
- des moyens de génération (33) de données complémentaires d'information (DCI) liées audit message (M) dudit utilisateur.
10. Serveur d'information (30) selon la revendication 8 comportant,
- des moyens de réception (35) d'un message (M) dudit utilisateur ;
- des moyens de vérification (33) que ledit message (M) reçu dudit utilisateur est en relation avec les données d'information (PW) déjà envoyées ;
- des moyens de génération (33) d'une requête liée audit message (M) dudit utilisateur ; et
- des moyens d'envoi (35) de ladite requête vers un serveur applicatif apte à traiter ladite requête.
11. Serveur d'information (30) selon l'une quelconque des revendications 8 à 10, caractérisé en ce que lesdits moyens de génération (33) génèrent lesdites données d'information (PW) en utilisant des préférences dudit utilisateur.
12. Serveur d'information (30) selon l'une quelconque des revendications 8 à 11, caractérisé en ce que lesdits moyens d'envoi (35) desdites données d'information (PW) sont aptes à envoyer lesdites données d'information (PW) sous la forme d'une page Web vers ledit terminal (70) dudit utilisateur.
13. Serveur selon l'une quelconque des revendications 8 à 12, dans lequel ledit flux (F) est un flux point à point, comportant en outre des moyens de vérification (33) que ledit flux est reçu par un équipement (60) dudit utilisateur.
14. Procédé d'information comportant,
- une étape (F31,F41) de réception d'une commande (C) représentative de l'occurrence d'un événement (EV) lié à un flux (F) diffusé par un serveur de diffusion (10) ;
- une étape (F40) de traitement de la commande comportant une ou plusieurs sous-étapes de traitement (F42), chaque sous-étape de traitement comportant :
- une étape (F42) de génération de données d'information (PW) liées à une partie au moins de ladite commande (C) ;
- une étape (F43) de vérification de l'activité dudit flux ;
- et, si ledit flux est actif, une étape (F45) d'envoi desdites données d'information (PW) vers un terminal dudit utilisateur.
15. Procédé d'information selon la revendication 14 comportant,
- une étape (F51) de réception d'un message (M) dudit utilisateur ;
- une étape (F52) de vérification que ledit message (M) reçu dudit utilisateur est en relation avec les données d'information (PW) déjà envoyées ;
- si tel est le cas, une étape (F53) de génération de données complémentaires d'information (DCI) liées audit message (M) dudit utilisateur ;
- une étape de vérification (F55) que ledit flux (F) est actif ; - et, si le flux (F) est actif, une étape (F56) d'envoi desdites données complémentaires d'information (DCI) vers un terminal (70) dudit utilisateur.
16. Procédé d'information selon la revendication 14 comportant, - une étape (F51) de réception d'un message (M) dudit utilisateur ;
- une étape (F52) de vérification que ledit message (M) reçu dudit utilisateur est en relation avec les données d'information (PW) déjà envoyées ; - si tel est le cas, une étape (F53) de génération d'une requête liée audit message (M) dudit utilisateur ;
- une étape de vérification (F55) que ledit flux (F) est actif ;
- et, si le flux (F) est actif, une étape (F57) d'envoi de ladite requête vers un serveur applicatif apte à traiter ladite requête.
17. Programme d'ordinateur sur un support d'information, ledit programme étant susceptible d'être mis en œuvre par un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre d'un procédé d'information selon l'une quelconque des revendications 14 à 16.
18. Support d'enregistrement lisible par un ordinateur (30) sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé d'information selon l'une quelconque des revendications 14 à 16.
19. Serveur de gestion d'événements (20) comportant,
- des moyens (24) de détection de l'occurrence d'au moins un événement (EV) lié à un flux (F) diffusé par un serveur de diffusion (10) ;
- des moyens (23) de génération d'une commande (C) liée audit événement (EV) ;
- des moyens (23,24) de vérification de l'activité dudit flux (F) ; et
- des moyens (25) d'envoi de la commande (C) vers un serveur d'information (30).
20. Serveur selon la revendication 19 caractérisé en ce que lesdits moyens (23) de génération de ladite commande (C) sont aptes à inclure ladite commande (C) dans un fichier informatique conforme au standard XML.
21. Procédé de gestion d'événements comportant, - une étape (E14) de détection de l'occurrence d'au moins un événement (EV) lié à un flux diffusé (F) par un serveur de diffusion (10) ;
- une étape (E16) de génération d'une commande (C) liée audit événement (EV) ; - une étape (E18) de vérification de l'activité dudit flux (F) ;
- et, si ledit flux (F) est actif, une étape (E22) d'envoi de la commande (C) vers un serveur d'information (30).
22. Programme d'ordinateur sur un support d'information, ledit programme étant susceptible d'être mis en œuvre par un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre d'un procédé de gestion d'événements selon la revendication 21.
23. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de gestion d'événements selon la revendication 21.
24. Système de contrôle (40), comportant au moins un serveur d'information (30) selon l'une quelconque des revendications 8 à 13 et au moins un serveur de gestion d'événements (20) selon l'une quelconque des revendications 19 à 20, synchronisés entre eux par l'intermédiaire d'un serveur NTP (Network Time Protocol).
PCT/FR2007/051839 2006-08-31 2007-08-27 Systeme de synchronisation d'informations avec un flux WO2008025924A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0653526 2006-08-31
FR0653526A FR2905546A1 (fr) 2006-08-31 2006-08-31 Procede et systeme de synchronisation d'informations avec un flux

Publications (1)

Publication Number Publication Date
WO2008025924A1 true WO2008025924A1 (fr) 2008-03-06

Family

ID=37909735

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2007/051839 WO2008025924A1 (fr) 2006-08-31 2007-08-27 Systeme de synchronisation d'informations avec un flux

Country Status (2)

Country Link
FR (1) FR2905546A1 (fr)
WO (1) WO2008025924A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0630156A1 (fr) * 1993-06-16 1994-12-21 Nwt Datawave B.V. Système interactif de télévision
EP0852443A2 (fr) * 1997-01-03 1998-07-08 Texas Instruments Inc. Appareil de production de programmes de télévision interactifs
US20050239551A1 (en) * 2004-04-26 2005-10-27 Scott Griswold System and method for providing interactive games

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0630156A1 (fr) * 1993-06-16 1994-12-21 Nwt Datawave B.V. Système interactif de télévision
EP0852443A2 (fr) * 1997-01-03 1998-07-08 Texas Instruments Inc. Appareil de production de programmes de télévision interactifs
US20050239551A1 (en) * 2004-04-26 2005-10-27 Scott Griswold System and method for providing interactive games

Also Published As

Publication number Publication date
FR2905546A1 (fr) 2008-03-07

Similar Documents

Publication Publication Date Title
US10367880B2 (en) Method and system for presenting media content
WO2007051761A1 (fr) Reception de contenus audiovisuels a destination de plusieurs appareils
EP3694146A1 (fr) Procédé de traitement de flux audiovidéo en conférence multipartite, dispositifs, système et programme correspondants
WO2006067351A1 (fr) Procede et systeme de mise en relation de personnes dans un reseau de telecommunication de type internet
EP1617591A1 (fr) Procédé et serveur de référencement de diffusion poste à poste de fichiers demandés par téléchargement à ce serveur
WO2017158274A1 (fr) Acquisition d&#39;extraits d&#39;un flux multimédia sur un terminal
EP1793605A1 (fr) Procédé de fourniture sur demande de menus interactifs à des terminaux couplés à un réseau de communication
FR3068852A1 (fr) Procede de gestion du droit d&#39;acces a un contenu numerique
WO2008025924A1 (fr) Systeme de synchronisation d&#39;informations avec un flux
FR3054765B1 (fr) Procede pour la lecture sur un equipement d&#39;un contenu multimedia avec un retard cible par rapport au direct inferieur a un retard maximal donne
FR3086478A1 (fr) Gestion du fonctionnement d&#39;une telecommande lors de la reception d&#39;un appel telephonique.
WO2023180274A1 (fr) Gestion perfectionnée d&#39;un code visuel en cours d&#39;affichage dans un contenu multimédia
EP4016937B1 (fr) Procede de synchronisation et systeme mettant en uvre ledit procede
EP4016938B1 (fr) Procédé de synchronisation et système mettant en oeuvre ledit procédé
EP2206347A1 (fr) Procede et systeme de telecommunications interactif entre au moins deux dispositifs de communication via leurs moyens de connexion reseau respectifs
EP4184922A1 (fr) Procédé de gestion de l&#39; accès à un contenu multimédia
FR2992511A1 (fr) Lecture synchrone d&#39;un contenu par une pluralite de terminaux
EP2100430B1 (fr) Procédé et système de télécommunication permettant à au moins deux utilisateurs distincts d&#39;accéder à un meme ensemble d&#39;informations
WO2024013463A1 (fr) Streaming vidéo adaptatif hybride amélioré
FR3000357A1 (fr) Procede de transfert de communication audio et/ou video depuis un premier terminal vers un deuxieme terminal
EP2854415B1 (fr) Procédé de transmission dynamique de données d&#39;information relatives à un programme audio et/ou vidéo
FR3147677A1 (fr) procédé de gestion de l’accès à un contenu multimédia et de la lecture de ce contenu.
CN114584838A (zh) 多媒体数据进度控制方法、装置以及可读存储介质
FR3118220A1 (fr) Procede de vote et dispositif mettant en œuvre ledit procede
FR3079705A1 (fr) Communication par video conference

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07823739

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 07823739

Country of ref document: EP

Kind code of ref document: A1