WO2010004138A1 - Procede de declenchement d'une operation dans un terminal mobile - Google Patents

Procede de declenchement d'une operation dans un terminal mobile Download PDF

Info

Publication number
WO2010004138A1
WO2010004138A1 PCT/FR2009/000840 FR2009000840W WO2010004138A1 WO 2010004138 A1 WO2010004138 A1 WO 2010004138A1 FR 2009000840 W FR2009000840 W FR 2009000840W WO 2010004138 A1 WO2010004138 A1 WO 2010004138A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
message
server
mobile terminal
triggering
Prior art date
Application number
PCT/FR2009/000840
Other languages
English (en)
Inventor
Christophe Gargallo
Cédric Thienot
Jinshan Liu
Original Assignee
Expway
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 Expway filed Critical Expway
Publication of WO2010004138A1 publication Critical patent/WO2010004138A1/fr

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/162Authorising the user terminal, e.g. by paying; Registering the use of a subscription channel, e.g. billing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/305Authentication, i.e. establishing the identity or authorisation of security principals by remotely controlling device operation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866Management of end-user data
    • H04N21/25891Management of end-user data being end-user preferences
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/414Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41407Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/433Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/442Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44204Monitoring of content usage, e.g. the number of times a movie has been viewed, copied or the amount which has been watched
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/466Learning process for intelligent management, e.g. learning user preferences for recommending movies
    • H04N21/4667Processing of monitored end-user data, e.g. trend analysis based on the log file of viewer selections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65Transmission of management data between client and server
    • H04N21/654Transmission by server directed to the client
    • H04N21/6543Transmission by server directed to the client for forcing some client operations, e.g. recording
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server
    • H04N21/6583Acknowledgement
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81Monomedia components thereof
    • H04N21/8166Monomedia components thereof involving executable data, e.g. software
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/166Implementing security features at a particular protocol layer at the transport layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/168Implementing security features at a particular protocol layer above the transport layer

Definitions

  • the present invention relates to communication terminals and more particularly to mobile terminals, and in particular those designed to receive and reproduce audio and / or video programs.
  • Audio and / or video programs can be broadcast to mobile devices using DVB-H (Digital Video Broadcast - Handheld), DVB-SH (Digital Video Broadcast - S-Band Handheld) or 3G (third-party mobile phone standards). generation), the DAB (Digital Audio Broadcasting) standard being suitable for broadcasting audio programs.
  • DVB-H Digital Video Broadcast - Handheld
  • DVB-SH Digital Video Broadcast - S-Band Handheld
  • 3G third-party mobile phone standards
  • generation the DAB (Digital Audio Broadcasting) standard being suitable for broadcasting audio programs.
  • DAB Digital Audio Broadcasting
  • mobile terminals now offer many other services, such as multimedia file reproduction services (audio or video files stored in the terminal's memory), video games also stored in the terminal memory. , satellite tracking services, etc.
  • a mobile operator or mobile phone manufacturer may wish to obtain information on
  • the service usage information requiring a point-to-point connection to a network can be easily collected by the operator giving the terminal access to the network.
  • a network such as telecommunications and Internet access services
  • the use of services provided only by the terminal or via terminal receiving modules such as Global Positioning System (GPS), DVB or DAB, can not be monitored remotely. to collect usage information. It is also desirable that the use of a terminal can be placed under surveillance only if the user of the terminal has agreed.
  • the program guide service includes an application installed in the mobile terminal for receiving and processing all requests for access to a video service issued by the user, and for providing information relating to a program.
  • the program guide application can therefore be modified to record the requests made by the user to access the video programs, the recording of these requests making it possible to establish program audience measurement statistics.
  • a method for triggering an operation in a mobile terminal comprising a step of reception by the mobile terminal via a communication network, of a triggering message of an operation.
  • the method comprises the steps of, following the reception of the triggering message, transmitting by the mobile terminal to a server an identifier relating to an operation to be triggered on the terminal received with the trip message, if the identifier corresponds to an authorized identifier, transmit by the server to the mobile terminal a positive response message allowing the triggering of the operation, and trigger the operation by the mobile terminal only if the mobile terminal receives the positive response message.
  • the identifier identifies an entity that has transmitted the trigger message to the mobile terminal.
  • the method comprises a step of transmission by the mobile terminal of a notification message to an entity issuing the trigger message, indicating that the operation has been triggered.
  • the operation to be triggered is the activation of an application in the terminal, the method comprising a step of deactivating the application if an identifier of the terminal contained in the notification message designates a non-mobile terminal. ability to activate the application.
  • the triggering message contains information relating to the operation to be triggered in encrypted form, which are transmitted by the mobile terminal to the server, which are decrypted by the server and transmitted in decrypted form by the server to the terminal. in the positive response message.
  • the server sends a positive response message if the operation to be triggered is authorized for the entity issuing the triggering message.
  • the response message includes additional information relating to the operation to be triggered.
  • the method comprises the establishment of a secure communication link between the mobile terminal and the server.
  • the operation to be triggered is the activation of a usage information collection application of an application to be monitored installed in the mobile terminal, the operation triggering message comprising information relating to a collection campaign and an address of a collection server to which the usage information collected by the terminal is to be transmitted, the method comprising steps of collection and storage by the information terminal usage of the application to be monitored, and transmission by the terminal of the usage information collected to the collection server.
  • the application to be monitored is an application for receiving and rendering audio and / or video programs.
  • the collection server upon receipt of the usage information transmitted by the terminal, determines using an identifier received from the terminal, if the collection application is to be activated on the terminal, and transmits to the terminal a message triggering a deactivation operation if the collection application should not be activated on the terminal.
  • the operation triggering message is transmitted to the terminal in the form of an SMS-type message, or compliant with the OMA PUSH OTA over WSP protocol or the OMA Push OTA over HTTP protocol, or else transmitted collectively. to several recipient terminals in association with a list of identifiers of the destination terminals, in structured data streams or binary tables.
  • a mobile terminal configured to receive a message triggering an operation by the mobile terminal via a communication network.
  • the terminal is configured to send an identifier to a server in response to the reception of the activation message, and to activate the operation only if it receives from the server a positive response message allowing the triggering of the activation message. 'surgery.
  • the identifier identifies an entity that has transmitted the trigger message to the mobile terminal.
  • the terminal is configured to transmit a notification message to an entity issuing the trigger message, indicating that the operation has been triggered.
  • the terminal is configured to transmit to the server information relating to the operation to be triggered received in encrypted form in the trigger message, and to receive from the server in the response message the information relating to the operation to be performed. trigger in decrypted form.
  • the response message received includes additional information relating to the operation to be triggered.
  • the terminal is configured to establish with the server a secure communication link.
  • the operation to be triggered is the activation of a usage information collection application of an application to be monitored installed in the mobile terminal, the operation triggering message comprising information relating to a collection campaign and an address of a collection server to which the usage information collected by the terminal is to be transmitted, the execution of the collection application by the terminal comprising steps of collection and storage of data. usage information relating to the application to be monitored, and transmission of usage information collected to the collection server.
  • the application to be monitored is an application for receiving and rendering audio and / or video programs.
  • the operation triggering message is transmitted to the terminal in the form of an SMS-type message, or compliant with the OMA PUSH OTA over WSP protocol or the OMA Push OTA over HTTP protocol, or else transmitted collectively. to several recipient terminals in association with a list of identifiers of the destination terminals, in structured data streams or binary tables.
  • FIG. 1 represents in the form of blocks a system for triggering operations in mobile terminals, according to one embodiment
  • FIG. 2 represents steps of a method of triggering an operation in a mobile terminal, according to one embodiment
  • FIG. 3 represents steps of a method for collecting usage information of an application on a mobile terminal, according to one embodiment.
  • Figure 1 shows MT mobile terminals configured to connect to a MNT mobile network, one or more CSRV activation servers and a VSRV authentication server.
  • the CSRV and VSRV servers are configured to communicate with the mobile terminals MT, for example via the MNT network and, where appropriate, other networks such as the Internet or terrestrial telephone networks.
  • MT terminals are also configured to run various applications including applications for access to audio and / or video programs.
  • FIG. 2 represents steps of a method of triggering an operation in a mobile terminal MT.
  • the triggering process involves one of the CSRV activation servers and the VSRV authentication server.
  • the method comprises steps S1 to S7.
  • the activation server CSRV transmits to the terminal MT a triggering message of a DOP operation comprising a server identifier CID and CPAR parameters defining the operation to be triggered in the terminal MT.
  • the CSRV server has a TID identifier of the terminal MT, such as the telephone number of the latter.
  • the CPAR parameters include identification information of the operation to be triggered and, if necessary, parameters relating to this operation.
  • the TID identifiers of the terminals to be triggered and the CPAR parameters are for example stored in an operations database to be triggered TDB.
  • the CID of the CSRV server may be a telephone number for access to a telephone network.
  • the telephone number of the CSRV server can thus be either allocated to a terrestrial telephone line or stored in a secure access module to a mobile telephone network, such as a SIM (Subscriber Identity Module) card. In this way, the CSRV server can be identified in a manner that is difficult to falsify.
  • the terminal MT connects to the authentication server VSRV and retransmits the DOP trigger message received from the CSRV server. For this purpose, the terminal stores an access address to the server VSRV, such as an address L) RL (Uniform Resource Locator).
  • the server VSRV verifies that the identifier CID and possibly the information CPAR contained in the message DOP received correspond to information that it has previously stored, for example in a database of operations to trigger CBD.
  • the VSRV server stores all the identifiers of the CSRV servers authorized to trigger an operation on an MT terminal, each authorized server identifier possibly being memorized in association with identifiers of operations that the server is authorized to trigger.
  • step S4 the VSRV server transmits to the MT terminal a response message REP indicating whether or not the terminal can trigger the operation depending on whether the CID information, CPAR or not information previously stored by the VSRV server.
  • steps S2 to S4 enable the terminal to authenticate the CSRV server that has sent the triggering message, and to verify that the triggering of the operation is authorized for the authenticated CSRV server.
  • the terminal MT transmits a notification message NOT containing its TID identifier to the server CSRV, to indicate whether the order of triggering the operation has been authorized or not.
  • the terminal MT triggers the operation OP, if the message REP indicates that the triggering order can be executed. Of course, it can be expected to send the NOT message only if the operation has been authorized.
  • the triggered operation can be the activation or deactivation of an application such as an application for collecting service usage information offered by applications installed in the MT terminal.
  • the services can be purely local, that is to say offered by the terminal alone, as services for restitution of audio or video files, or video games previously stored by the terminal.
  • the services offered by the terminal may also be offered via the terminal acting as a receiver for, for example, receiving geographical location signals or audio or video programs, or downloading files.
  • the DOP operation trip message can be transmitted to the MT terminal in the form of a message of the SMS (Short Message Service) type, or compliant with the OMA protocol (Open Mobile Alliance) PUSH OTA (Over The Air) over WSP ( Wireless Session Protocol) or the OMA Push OTA over HTTP protocol. More information about these protocols can be obtained from OMA-TS-PushOTA-V2_2- 20071002-C.
  • the operation triggering message then contains an identifier of the application installed in the terminal, for which the message is intended, and the terminal is configured to route each received message to the application identified in the message.
  • the DOP message can also be transmitted collectively, that is to say by broadcast, to several MT terminals, for example with the program guide data, in structured data streams called "sessions", which may be in accordance with FIG. FLUTE protocol.
  • Such bitstreams are transmitted in a loop and accessible to specific IP addresses.
  • the DOP message is then associated with a list of destination terminal identifiers of the message.
  • the DOP message and the destination terminal identifiers may also be broadcast in PSI / SI (Program Specify Information / Service Information) binary tables inserted in a transport frame conforming to the DVB or DVB-H protocol.
  • PSI / SI Program Specify Information / Service Information
  • the FLUTE data streams are multiplexed with video streams in multiplexed transport streams with the PSI / SI bit tables. Further information on these broadcast transmission modes can be found in particular in ETSI 102 471, V1.1.1 (2006-04), "Digital Video Broadcasting (DVB), and IP Datacast over DVB-H: Electronic Service Guide
  • the CID, CPAR information contained in the DOP message transmitted by the CSRV server may be encrypted, and retransmitted as such by the MT terminal to the VSRV server.
  • the VSRV server decrypts the CID and CPAR information received from the MT terminal and returns them in decrypted form to the terminal, so that the latter can exploit them and trigger the required operation.
  • the communication established between the mobile terminal and the validation server VSRV is secure, for example of the type HTTPS (HyperText Transport Protocol Secure), SSL (Secure Sockets Layers) or TLS (Transport Layer Security).
  • HTTPS HyperText Transport Protocol Secure
  • SSL Secure Sockets Layers
  • TLS Transport Layer Security
  • step S10 the terminal MT collects EVTS information and writes it to a file stored in its memory.
  • step S11 if the time has come to transmit the collected EVTS information, the MT terminal transmits it in step S12 to a designated server in the CPAR trigger parameters, for example the CSRV server.
  • the transmission of the collected information can be carried out at a determined frequency, for example daily or weekly, or when the memory occupied by the terminal MT exceeds a certain threshold. Following transmission to the CSRV server, collected EVTS information is erased from the terminal's memory.
  • the collection application can be activated in an MT terminal by several CSRV servers.
  • several instances of the collection application are activated in the terminal, each instance storing the collected information in a respective file.
  • Each collected information file is then transmitted to the CSRV server which activated the instance corresponding to the file.
  • the server CSRV checks with the help of the identifier TID received from the terminal, that the information received comes from an authorized terminal. If the received information comes from a terminal authorized to transmit service usage information, the CSRV server then performs step S15 where it stores the received information in an EVTS usage event database. On the other hand, if the MT terminal having sent collected information is not an authorized terminal, the CSRV server does not store the collected information received and transmits in step S14 to the terminal a message for triggering a deactivation operation of collection of usage information.
  • the trigger message includes the CID of the CSRV server and possible deactivation parameters, in particular to designate the application to be deactivated.
  • the terminal performs steps S2 through S4 to authenticate the CSRV server that requested deactivation. If the server
  • the terminal MT deactivates the collection application, otherwise it continues the collection operation in step S10.
  • the terminal may also transmit to the CSRV server a response message to the deactivation of the collection application, to inform it whether or not the collection application has been deactivated.
  • the terminal MT erases from its memory the information collected for the deactivated collection application.
  • the DOP triggering message includes connection information enabling the MT terminal to access the server
  • connection information may be a URL address and / or a server access telephone number.
  • the server having issued the activation command is not necessarily the same as the one designated to receive the collected information.
  • the method described above makes it possible to ensure that the usage information collected is transmitted exclusively to the server referenced in the triggering message and authenticated by the authentication server VSRV.
  • a DOP trigger message of a usage information collection operation may include the fields specified in the following Table 1:
  • the contents of the trigger message can be sent in encrypted form, the telephone numbers of the collection server and the terminal can also be transmitted in unencrypted form.
  • the trigger message can then be retransmitted without being decrypted by the terminal MT to the authentication server VSRV in step S2.
  • the VSRV server can thus check using the fields containing the server telephone number and the campaign identifier of the DOP message that the server identified in the message is authorized to activate and receive the information collected for the campaign identified in the message. the message.
  • the REP response message transmitted by the VSRV server in step S3 may include the fields specified in the following Table 2:
  • the terminal therefore does not need to implement a decryption operation of the content of the DOP or REP message.
  • the information transmitted in the DOP trigger message is the only strictly necessary for the authentication of the CSRV server. If the CSRV server and the collection campaign are authenticated, this information is supplemented by the VSRV server with other collection campaign activation parameters, such as parameters specifying to the MT terminal where and when to send the collected information and what events are to watch. This provision is of course applicable to other types of applications to activate.
  • the usage event types to monitor and collect can be specified using one or more bytes.
  • the types of events to be monitored and collected may be those summarized in the following table:
  • the "event types" field specifies on less than one byte the types of events to be collected.
  • the MT terminal is configured to detect each of the events specified by this field and to store in a collected usage information file an identifier of each of the detected events in association with a date and time of occurrence of the event. .
  • the EVTS collected usage information may be transmitted (step S12) using the HTTP or FTP (File Transfer Protocol) protocol using the CSRV server URL.
  • the MT terminal comprises an HTTP stack and issues HTTP POST requests to the URL of the CSRV collection server received. If the transmission fails with the CSRV server, one or more other attempts can be made. If all attempts have failed, a new sequence of multiple attempts may be executed, for example the next day. If the transmission of the collected information has been successful, the CSRV server transmits a positive acknowledgment in response. The terminal then erases the transmitted information from its memory.
  • a software version number may be transmitted in the collection message to indicate to the CSRV server the format of the message containing the collected usage information.
  • the present invention is susceptible to various embodiments and applications.
  • the invention is not limited to an authentication server having access to an identification list of all authorized collection servers.
  • the list accessible to the validation server can specify only all unauthorized collection servers, or only authorized operations if in the context concerned, the operation can be triggered by any server.
  • the invention does not apply solely to the collection of usage information of a service implemented by a mobile terminal, but to any other operation implementing an information transmission by the terminal to a server.

Abstract

L'invention concerne un procédé de déclenchement d'une opération (OP) dans un terminal mobile (MT), comprenant des étapes de réception par le terminal mobile par l'intermédiaire d'un réseau de communication (MNT), d'un message de déclenchement d'une opération (DOP), de transmission, à la suite de la réception du message de déclenchement (DOP), par le terminal mobile (MT) à un serveur (VSRV) d'un identifiant (CID) relatif à une opération à déclencher sur le termina, reçu avec le message de déclenchement, de transmission, si l'identifiant correspond à un identifiant autorisé, par le serveur au terminal mobile d'un message de réponse positif (REP) autorisant le déclenchement de l'opération (OP), et de déclenchement de l'opération par le terminal mobile seulement si le terminal mobile reçoit le message de réponse positif.

Description

PROCEDE DE DECLENCHEMENT D'UNE OPERATION DANS UN
TERMINAL MOBILE
La présente invention concerne les terminaux de communication et plus particulièrement les terminaux mobiles, et notamment ceux conçus pour recevoir et restituer des programmes audio et/ou vidéo.
Des programmes audio et/ou vidéo peuvent être diffusés à des terminaux mobiles grâce aux standards DVB-H (Digital Video Broadcast - Handheld), DVB-SH (Digital Video Broadcast - S-Band Handheld) ou 3G (normes de téléphonie mobile de troisième génération), le standard DAB (Digital Audio Broadcasting) étant adapté à la diffusion de programmes audio. Dans un système de diffusion de programmes audio et/ou vidéo, il est souhaitable d'effectuer des mesures d'audience pour déterminer quels services sont accèdes par les utilisateurs et à quels moments. Ces mesures permettent aux fournisseurs de service d'adapter leurs programmes et leurs horaires aux attentes des utilisateurs. D'une manière plus générale, les terminaux mobiles offrent aujourd'hui de nombreux autres services, comme des services de restitution de fichiers multimédia (fichiers audio ou vidéo stockés dans la mémoire du terminal), des jeux vidéo également stockés dans la mémoire du terminal, des services de localisation par satellite, etc. Dans ce contexte, un opérateur de téléphonie mobile ou un fabricant de téléphones mobiles, par exemple, peut souhaiter obtenir des informations sur l'usage des téléphones mobiles pour déterminer notamment à quelle fréquence chaque service peut être utilisé.
Les informations d'usage de services nécessitant une connexion point à point à un réseau, comme les services de télécommunication et d'accès au réseau Internet, peuvent être facilement recueillies par l'opérateur donnant au terminal l'accès au réseau. Par contre, l'usage de services fournis uniquement par le terminal ou par l'intermédiaire de modules de réception du terminal, comme les modules de réception de signaux GPS (Global Positioning System), DVB ou DAB, ne peut pas être surveillé à distance pour collecter des informations d'usage. II est également souhaitable que l'usage d'un terminal puisse être placé sous surveillance que si l'utilisateur du terminal a donné son accord.
En outre, il est souhaitable que le destinataire des informations collectées puisse choisir quand activer et désactiver la collecte d'informations d'usage et choisir quels terminaux doivent réaliser ces opérations.
D'une manière générale, il est souhaitable de pouvoir activer ou désactiver à distance une opération sur un terminal mobile distant. Il est également souhaitable qu'une telle activation ou désactivation puisse être effectuée d'une manière sécurisée, tant du côté du terminal que du côté de l'émetteur des commandes d'activation et de désactivation. Il convient en effet de s'assurer qu'une opération sur un terminal ne puisse pas être activée par une entité non habilitée, et que seul un terminal habilité puisse être sollicité pour activer ou désactiver une opération.
Dans le cadre d'une collecte d'informations d'usage de services, il est souhaitable de pouvoir assurer que les informations collectées proviennent bien de terminaux habilités, et ne puissent pas être interceptées ou transmises à un autre destinataire que celui désigné.
Dans le cadre du standard DVB-H, il existe un service de guide de programme défini par la norme ESG (Electronic Service Guide) qui a été prévu pour fournir des fonctions nécessaires pour rechercher, découvrir et accéder à des services de programme vidéo. Le service de guide de programmes comprend une application installée dans le terminal mobile pour recevoir et traiter toutes les requêtes d'accès à un service vidéo émise par l'utilisateur, et pour fournir des informations relatives à un programme. L'application de guide de programme peut donc être modifiée pour assurer l'enregistrement des requêtes émises par l'utilisateur pour accéder aux programmes vidéo, l'enregistrement de ces requêtes permettant d'établir des statistiques de mesure d'audience de programmes.
Dans un mode de réalisation, il est prévu un procédé de déclenchement d'une opération dans un terminal mobile, comprenant une étape de réception par le terminal mobile par l'intermédiaire d'un réseau de communication, d'un message de déclenchement d'une opération. Selon un mode de réalisation, le procédé comprend des étapes consistant à, à la suite de la réception du message de déclenchement, transmettre par le terminal mobile à un serveur un identifiant relatif à une opération à déclencher sur le terminal reçu avec le message de déclenchement, si l'identifiant correspond à un identifiant autorisé, transmettre par le serveur au terminal mobile un message de réponse positif autorisant le déclenchement de l'opération, et déclencher l'opération par le terminal mobile seulement si le terminal mobile reçoit le message de réponse positif.
Selon un mode de réalisation, l'identifiant identifie une entité ayant transmis le message de déclenchement au terminal mobile.
Selon un mode de réalisation, le procédé comprend une étape de transmission par le terminal mobile d'un message de notification à une entité émettrice du message de déclenchement, indiquant que l'opération a été déclenchée.
Selon un mode de réalisation, l'opération à déclencher est l'activation d'une application dans le terminal, le procédé comprenant une étape de désactivation de l'application si un identifiant du terminal contenu dans le message de notification désigne un terminal mobile non habilité à activer l'application.
Selon un mode de réalisation, le message de déclenchement contient des informations relatives à l'opération à déclencher sous forme chiffrée, qui sont transmises par le terminal mobile au serveur, qui sont déchiffrées par le serveur et transmises sous forme déchiffrée par le serveur au terminal dans le message de réponse positif.
Selon un mode de réalisation, le serveur émet un message de réponse positif si l'opération à déclencher est autorisée pour l'entité émettrice du message de déclenchement. Selon un mode de réalisation, le message de réponse comprend des informations complémentaires relatives à l'opération à déclencher.
Selon un mode de réalisation, le procédé comprend l'établissement d'un lien de communication sécurisé entre le terminal mobile et le serveur.
Selon un mode de réalisation, l'opération à déclencher est l'activation d'une application de collecte d'informations d'usage d'une application à surveiller installée dans le terminal mobile, le message de déclenchement d'opération comprenant des informations relatives à une campagne de collecte et une adresse d'un serveur de collecte à qui des informations d'usage collectées par le terminal sont à transmettre, le procédé comprenant des étapes collecte et de mémorisation par le terminal d'informations d'usage relatives à l'application à surveiller, et de transmission par le terminal des informations d'usage collectées au serveur de collecte.
Selon un mode de réalisation, l'application à surveiller est une application de réception et de restitution de programmes audio et/ou vidéo. Selon un mode de réalisation, à la réception des informations d'usage transmises par le terminal, le serveur de collecte détermine à l'aide d'un identifiant reçu du terminal, si l'application de collecte doit être activée sur le terminal, et transmet au terminal un message déclenchement d'une opération de désactivation si l'application de collecte ne doit pas être activée sur le terminal.
Selon un mode de réalisation, le message de déclenchement d'opération est transmis au terminal sous la forme d'un message de type SMS, ou conforme au protocole OMA PUSH OTA over WSP ou au protocole OMA Push OTA over HTTP, ou encore transmis collectivement à plusieurs terminaux destinataires en association avec une liste d'identifiants des terminaux destinataires, dans des flux de données structurées ou des tables binaires.
Dans un mode de réalisation, il est également prévu un terminal mobile configuré pour recevoir un message de déclenchement d'une opération par le terminal mobile par l'intermédiaire d'un réseau de communication. Selon un mode de réalisation, le terminal est configuré pour envoyer un identifiant à un serveur en réponse à la réception du message d'activation, et activer l'opération seulement s'il reçoit du serveur un message de réponse positif autorisant le déclenchement de l'opération. Selon un mode de réalisation, l'identifiant identifie une entité ayant transmis le message de déclenchement au terminal mobile.
Selon un mode de réalisation, le terminal est configuré pour transmettre un message de notification à une entité émettrice du message de déclenchement, indiquant que l'opération a été déclenchée. Selon un mode de réalisation, le terminal est configuré pour transmettre au serveur des informations relatives à l'opération à déclencher reçues sous forme chiffrée dans le message de déclenchement, et recevoir du serveur dans le message de réponse les informations relatives à l'opération à déclencher sous forme déchiffrée. Selon un mode de réalisation, le message de réponse reçu comprend des informations complémentaires relatives à l'opération à déclencher.
Selon un mode de réalisation, le terminal est configuré pour établir avec le serveur un lien de communication sécurisé. Selon un mode de réalisation, l'opération à déclencher est l'activation d'une application de collecte d'informations d'usage d'une application à surveiller installée dans le terminal mobile, le message de déclenchement d'opération comprenant des informations relatives à une campagne de collecte et une adresse d'un serveur de collecte à qui des informations d'usage collectées par le terminal sont à transmettre, l'exécution de l'application de collecte par le terminal comprenant des étapes de collecte et de mémorisation d'informations d'usage relatives à l'application à surveiller, et de transmission des informations d'usage collectées au serveur de collecte. Selon un mode de réalisation, l'application à surveiller est une application de réception et de restitution de programmes audio et/ou vidéo.
Selon un mode de réalisation, le message de déclenchement d'opération est transmis au terminal sous la forme d'un message de type SMS, ou conforme au protocole OMA PUSH OTA over WSP ou au protocole OMA Push OTA over HTTP, ou encore transmis collectivement à plusieurs terminaux destinataires en association avec une liste d'identifiants des terminaux destinataires, dans des flux de données structurées ou des tables binaires.
Des exemples de réalisation de l'invention seront décrits dans ce qui suit, à titre non limitatif en relation avec les figures jointes parmi lesquelles :
- la figure 1 représente sous la forme de blocs un système permettant de déclencher des opérations dans des terminaux mobiles, selon un mode de réalisation, - la figure 2 représente des étapes d'un procédé de déclenchement d'une opération dans un terminal mobile, selon un mode de réalisation,
- la figure 3 représente des étapes d'un procédé de collecte d'informations d'usage d'une application sur un terminal mobile, selon un mode de réalisation. La figure 1 représente des terminaux mobiles MT configurés pour se connecter à un réseau de téléphonie mobile MNT, un ou plusieurs serveurs de d'activation CSRV et un serveur d'authentification VSRV. Les serveurs CSRV et VSRV sont configurés pour communiquer avec les terminaux mobiles MT, par exemple par l'intermédiaire du réseau MNT et le cas échéant, d'autres réseaux tels que le réseau Internet ou des réseaux de téléphonie terrestre. Les terminaux MT sont également configurés pour exécuter diverses applications et notamment des applications d'accès à des programmes audio et/ou vidéo. La figure 2 représente des étapes d'un procédé de déclenchement d'une opération dans un terminal mobile MT. Le procédé de déclenchement fait intervenir l'un des serveurs d'activation CSRV et le serveur d'authentification VSRV. Le procédé comprend des étapes S1 à S7. A la première étape S1 , le serveur d'activation CSRV transmet au terminal MT un message de déclenchement d'une opération DOP comportant un identifiant CID du serveur et des paramètres CPAR définissant l'opération à déclencher dans le terminal MT. Pour transmettre le message DOP au terminal, le serveur CSRV possède un identifiant TID du terminal MT, tel que le numéro de téléphone de ce dernier. Les paramètres CPAR comprennent des informations d'identification de l'opération à déclencher et, le cas échéant, des paramètres relatifs à cette opération. Les identifiants TID des terminaux à déclencher et les paramètres CPAR sont par exemple mémorisés dans une base de données d'opérations à déclencher TDB. L'identifiant CID du serveur CSRV peut être un numéro de téléphone d'accès à un réseau téléphonique. Le numéro de téléphone du serveur CSRV peut ainsi être soit attribué à une ligne téléphonique terrestre, soit mémorisé dans un module sécurisé d'accès à un réseau téléphonique mobile, telle qu'une carte SIM (Subscriber Identity Module). De cette manière, le serveur CSRV peut être identifié d'une manière difficilement falsifiable. A l'étape suivante S2, le terminal MT se connecte au serveur d'authentification VSRV et lui retransmet le message de déclenchement DOP reçu du serveur CSRV. A cet effet, le terminal mémorise une adresse d'accès au serveur VSRV, telle qu'une adresse L)RL (Uniform Ressource Locator). A l'étape suivante S3, le serveur VSRV vérifie que l'identifiant CID et éventuellement les informations CPAR contenus dans le message DOP reçu correspondent à des informations qu'il a préalablement mémorisées, par exemple dans une base de données d'opérations à déclencher CDB. A cet effet, le serveur VSRV mémorise tous les identifiants des serveurs CSRV autorisés à déclencher une opération sur un terminal MT, chaque identifiant de serveur autorisé étant éventuellement mémorisé en association avec des identifiants d'opérations que le serveur est autorisé à déclencher.
A l'étape S4, le serveur VSRV transmet au terminal MT un message de réponse REP indiquant si oui ou non le terminal peut déclencher l'opération selon que les informations CID, CPAR correspondent ou non à des informations préalablement mémorisées par le serveur VSRV.
Ainsi, les étapes S2 à S4 permettent au terminal d'authentifier le serveur CSRV ayant émis le message de déclenchement, et de vérifier que le déclenchement de l'opération est bien autorisé pour le serveur CSRV authentifié. A l'étape S5, le terminal MT transmet un message de notification NOT contenant son identifiant TID au serveur CSRV, pour lui indiquer si l'ordre de déclenchement de l'opération a été autorisé ou non. Aux étapes S6 et S7, le terminal MT déclenche l'opération OP, si le message REP indique que l'ordre de déclenchement peut être exécuté. Bien entendu, il peut être prévu d'envoyer le message NOT seulement si l'opération a été autorisée.
L'opération déclenchée peut être l'activation ou la désactivation d'une application telle qu'une application de collecte d'informations d'usage de services offerts par des applications installées dans le terminal MT. Les services peuvent être purement locaux, c'est-à-dire offerts par le terminal seul, comme des services de restitution de fichiers audio ou vidéo, ou encore des jeux vidéo, préalablement stockés par le terminal. Les services offerts par le terminal peuvent également être offerts par l'intermédiaire du terminal agissant en tant que récepteur pour, par exemple, recevoir des signaux de localisation géographique ou des programmes audio ou vidéo, ou télécharger des fichiers.
Le message de déclenchement d'opération DOP peut être transmis au terminal MT sous la forme d'un message de type SMS (Short Message Service), ou conforme au protocole OMA (Open Mobile Alliance) PUSH OTA (Over The Air) over WSP (Wireless Session Protocol) ou au protocole OMA Push OTA over HTTP. De plus amples informations sur ces protocoles peuvent être obtenues dans le document OMA-TS-PushOTA-V2_2- 20071002-C. Le message de déclenchement d'opération contient alors un identifiant de l'application installée dans le terminal, à qui est destiné le message, et le terminal est configuré pour acheminer chaque message reçu vers l'application identifiée dans le message.
Le message DOP peut être également transmis collectivement, c'est- à-dire par diffusion, à plusieurs terminaux MT, par exemple avec les données de guide de programme, dans des flux de données structurées appelés "sessions", qui peuvent être conformes au protocole FLUTE. De tels flux binaires sont transmis en boucle et accessibles à des adresses IP déterminées. Le message DOP est alors associé à une liste d'identifiants de terminaux destinataires du message. Le message DOP et les identifiants de terminaux destinataires peuvent également être diffusés dans des tables binaires PSI/SI (Program Spécifie information/Service Information) insérées dans une trame de transport conforme au protocole DVB ou DVB-H. Dans cette trame, les flux de données FLUTE sont multiplexes avec des flux vidéo dans des flux de transport multiplexes avec les tables binaires PSI/SI. De plus amples informations sur ces modes de transmission par diffusion peuvent être trouvées notamment dans le document ETSI 102 471 , V1.1.1 (2006-04), "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic Service Guide (ESG)".
Les informations CID, CPAR figurant dans le message DOP transmis par le serveur CSRV peuvent être chiffrées, et retransmises telles quelles par le terminal MT au serveur VSRV. Dans ce cas, le serveur VSRV déchiffre les informations CID et CPAR reçues du terminal MT et les renvoie sous forme déchiffrée au terminal, afin que ce dernier puisse les exploiter et déclencher l'opération requise.
La communication établie entre le terminal mobile et le serveur de validation VSRV est sécurisée, par exemple du type HTTPS (HyperText Transport Protocol Secure), SSL (Secure Sockets Layers) ou TLS (Transport Layer Security). Ainsi, le procédé décrit précédemment permet d'assurer que les informations de déclenchement restent confidentielles et ne peuvent pas être modifiées, et qu'une opération ne peut pas être déclenchée dans un terminal par un serveur CSRV non authentifié. Dans le cas où l'opération à déclencher requiert l'émission vers un serveur d'informations collectées par le terminal, le procédé décrit précédemment permet également d'assurer que les informations collectées sont bien transmises au serveur désigné dans les paramètres de déclenchement CPAR pour recevoir ces informations. La figure 3 représente des étapes S10 à S15 exécutées par le terminal MT lors de l'exécution d'une application de collecte d'informations d'usage, déclenchée à la suite de l'exécution des étapes S1 à S5. A l'étape S10, le terminal MT collecte des informations EVTS et les inscrit dans un fichier stocké dans sa mémoire. A l'étape S11 , si le moment est venu de transmettre les informations collectées EVTS, le terminal MT les transmet à l'étape S12 vers un serveur désigné dans les paramètres de déclenchement CPAR, par exemple le serveur CSRV. La transmission des informations collectées peut être effectuée à une fréquence déterminée, par exemple journalière ou hebdomadaire, ou bien lorsque la mémoire occupée du terminal MT excède un certain seuil. A la suite de leur transmission au serveur CSRV, les informations EVTS collectées sont effacées de la mémoire du terminal.
Il est à noter que l'application de collecte peut être activée dans un terminal MT par plusieurs serveurs CSRV. Dans ce cas, plusieurs instances de l'application de collecte sont activées dans le terminal, chaque instance mémorisant les informations collectées dans un fichier respectif. Chaque fichier d'informations collectées est ensuite transmis au serveur CSRV qui a activé l'instance correspondant au fichier.
A l'étape suivante S13, le serveur CSRV vérifie à l'aide de l'identifiant TID reçu du terminal, que les informations reçues proviennent bien d'un terminal autorisé. Si les informations reçues proviennent d'un terminal autorisé à transmettre des informations d'usage de services, le serveur CSRV exécute alors l'étape S15 où il mémorise les informations reçues dans une base de données d'événements d'usage EVTS. Au contraire, si le terminal MT ayant émis des informations collectées n'est pas un terminal autorisé, le serveur CSRV ne mémorise pas les informations collectées reçues et transmet à l'étape S14 au terminal un message de déclenchement d'une opération de désactivation de la collecte d'informations d'usage. Le message de déclenchement comprend l'identifiant CID du serveur CSRV et des paramètres éventuels de désactivation notamment pour désigner l'application à désactiver.
Pour désactiver l'application désignée dans le message de déclenchement, le terminal exécute les étapes S2 à S4 permettant d'authentifier le serveur CSRV ayant requis la désactivation. Si le serveur
CSRV est authentifié par le serveur d'authentification VSRV, le terminal MT désactive l'application de collecte, sinon il poursuit l'opération de collecte à l'étape S10. Le terminal peut également transmettre au serveur CSRV un message de réponse à la désactivation de l'application de collecte, pour l'informer si l'application de collecte a été ou non désactivée. A la suite de la désactivation de l'opération de collecte, le terminal MT efface de sa mémoire les informations collectées pour l'application de collecte désactivée.
Si l'opération à déclencher concerne une application de collecte d'informations d'usage, le message de déclenchement DOP comprend une information de connexion permettant au terminal MT d'accéder au serveur
CSRV. L'information de connexion peut être une adresse URL et/ou un numéro de téléphone d'accès au serveur.
Il est à noter que si le destinataire des informations collectées est spécifié dans le message DOP, le serveur ayant émis l'ordre d'activation, n'est pas nécessairement le même que celui désigné pour recevoir les informations collectées.
Le procédé décrit précédemment permet d'assurer que les informations d'usage collectées sont transmises exclusivement au serveur référencé dans le message de déclenchement et authentifié par le serveur d'authentification VSRV.
Par exemple, un message de déclenchement DOP d'une opération de collecte d'information d'usage peut comprendre les champs spécifiés dans le tableau 1 suivant :
Tableau 1
Figure imgf000012_0001
Figure imgf000013_0001
Le contenu du message de déclenchement peut être émis sous forme chiffrée, les numéros de téléphone du serveur de collecte et du terminal pouvant être transmis également sous forme non chiffrée. Le message de déclenchement peut alors être retransmis sans être déchiffré par le terminal MT au serveur d'authentification VSRV à l'étape S2.
Le serveur VSRV peut ainsi vérifier à l'aide des champs contenant le numéro de téléphone du serveur et l'identifiant de campagne du message DOP que le serveur identifié dans le message est bien habilité à activer et recevoir les informations collectées pour la campagne identifiée dans le message.
Le message de réponse REP transmis par le serveur VSRV à l'étape S3 peut comprendre les champs spécifiés dans le tableau 2 suivant :
Tableau 2
Figure imgf000013_0002
Toutes les informations fournies dans le message REP sont non chiffrées, la sécurisation de la transmission du message étant assurée par le protocole utilisé (HTTPS) pour transmettre le message. Le terminal n'a donc pas besoin de mettre en œuvre une opération de déchiffrement du contenu du message DOP ou REP.
En cas d'échec de l'authentification du serveur CSRV (champ réponse du message de réponse à "Echec"), le message de réponse REP ne comporte qu'un champ d'erreur, mais pas de champs "URL du serveur de collecte", "Période", "Date d'envoi", "Intervalle" et "Evénements".
Il est à noter que dans l'exemple du tableau 2, les informations transmises dans le message de déclenchement DOP sont les seules strictement nécessaires à l'authentification du serveur CSRV. Si le serveur CSRV et la campagne de collecte sont authentifiés, ces informations sont complétées par le serveur VSRV avec d'autres paramètres d'activation de la campagne de collecte, tels que des paramètres spécifiant au terminal MT où et quand envoyer les informations collectées et quels événements sont à surveiller. Cette disposition est bien entendu applicable à d'autres types d'applications à activer.
Les types d'événement d'usage à surveiller et collecter (champ événements) peuvent être spécifiés à l'aide d'un ou plusieurs octets. Dans le cas de l'usage d'un service de réception de programmes audio ou vidéo, les types d'événement à surveiller et collecter peuvent être ceux résumés dans le tableau suivant :
Tableau 3
Figure imgf000014_0001
Figure imgf000015_0001
Le champ "types d'événement" spécifie sur moins d'un octet les types d'événements à collecter. Le terminal MT est configuré pour détecter chacun des événements spécifiés par ce champ et pour mémoriser dans un fichier d'informations d'usage collectées, un identifiant de chacun des événements détectés en association avec une date et une heure d'apparition de l'événement.
Les informations d'usage collectées EVTS peuvent être transmises (étape S12) à l'aide du protocole HTTP ou FTP (File Transfer Protocol) en utilisant l'adresse URL du serveur CSRV. A cet effet, le terminal MT comprend une pile HTTP et émet des requêtes HTTP POST vers l'URL du serveur de collecte CSRV reçu. En cas d'échec de la transmission avec le serveur CSRV, une ou plusieurs autres tentatives peuvent être effectuées. Si toutes les tentatives ont échouées, une nouvelle séquence de plusieurs tentatives peut être exécutée, par exemple le jour suivant. Si la transmission des informations collectées a réussi, le serveur CSRV transmet en réponse un accusé de réception positif. Le terminal efface alors de sa mémoire les informations transmises.
Un numéro de version logicielle peut être transmis dans le message de collecte pour indiquer au serveur CSRV le format du message contenant les informations d'usage collectées.
Il apparaîtra clairement à l'homme de l'art que la présente invention est susceptible de diverses variantes de réalisation et d'applications. En particulier, l'invention n'est pas limitée à un serveur d'authentification ayant accès à une liste d'identification de tous les serveurs de collecte autorisés. La liste accessible au serveur de validation peut spécifier uniquement tous les serveurs de collecte non autorisés, ou uniquement les opérations autorisées si dans le contexte visé, l'opération peut être déclenchée par n'importe quel serveur. L'invention ne s'applique pas uniquement à la collecte d'informations d'usage d'un service mis en œuvre par un terminal mobile, mais à toute autre opération mettant en œuvre une transmission d'informations par le terminal vers un serveur.

Claims

REVENDICATIONS
1. Procédé de déclenchement d'une opération (OP) dans un terminal mobile (MT), comprenant une étape de réception par le terminal mobile par l'intermédiaire d'un réseau de communication (MNT), d'un message de déclenchement d'une opération (DOP), caractérisé en ce qu'il comprend des étapes consistant à : à la suite de la réception du message de déclenchement (DOP), transmettre par le terminal mobile (MT) à un serveur (VSRV) un identifiant
(CID) relatif à une opération à déclencher sur le terminal reçu avec le message de déclenchement, si l'identifiant correspond à un identifiant autorisé, transmettre par le serveur au terminal mobile un message de réponse positif (REP) autorisant le déclenchement de l'opération (OP), et déclencher l'opération par le terminal mobile seulement si le terminal mobile reçoit le message de réponse positif.
2. Procédé selon la revendication 1 , dans lequel l'identifiant (CID) identifie une entité (CSRV) ayant transmis le message de déclenchement (DOP) au terminal mobile (MT).
3. Procédé selon la revendication 1 ou 2, comprenant une étape de transmission par le terminal mobile (MT) d'un message de notification (NOT) à une entité émettrice (CSRV) du message de déclenchement (DOP), indiquant que l'opération a été déclenchée.
4. Procédé selon la revendication 3, dans lequel l'opération à déclencher (OP) est l'activation d'une application dans le terminal (MT), le procédé comprenant une étape de désactivation de l'application si un identifiant (TID) du terminal contenu dans le message de notification (NOT) désigne un terminal mobile non habilité à activer l'application.
5. Procédé selon l'une des revendications 1 à 4, dans lequel le message de déclenchement (DOP) contient des informations relatives à l'opération à déclencher (OP) sous forme chiffrée, qui sont transmises par le terminal mobile (MT) au serveur (VSRV), qui sont déchiffrées par le serveur et transmises sous forme déchiffrée par le serveur au terminal dans le message de réponse positif (REP).
6. Procédé selon l'une des revendications 1 à 5, dans lequel le serveur (VSRV) émet un message de réponse positif si l'opération à déclencher (OP) est autorisée pour l'entité émettrice (CSRV) du message de déclenchement (DOP).
7. Procédé selon l'une des revendications 1 à 6, dans lequel le message de réponse (REP) comprend des informations complémentaires relatives à l'opération à déclencher (OP).
8. Procédé selon l'une des revendications 1 à 7, comprenant l'établissement d'un lien de communication sécurisé entre le terminal mobile
(MT) et le serveur (VSRV).
9. Procédé selon l'une des revendications 1 à 8, dans lequel l'opération à déclencher (OP) est l'activation d'une application de collecte d'informations d'usage (UC) d'une application à surveiller installée dans le terminal mobile (MT), le message de déclenchement d'opération (DOP) comprenant des informations relatives à une campagne de collecte et une adresse d'un serveur de collecte (CSRV) à qui des informations d'usage (EVTS) collectées par le terminal sont à transmettre, le procédé comprenant des étapes collecte et de mémorisation par le terminal d'informations d'usage relatives à l'application à surveiller, et de transmission par le terminal des informations d'usage collectées au serveur de collecte.
10. Procédé selon la revendication 9, dans lequel l'application à surveiller est une application de réception et de restitution de programmes audio et/ou vidéo.
11. Procédé selon la revendication 9 ou 10, dans lequel, à la réception des informations d'usage (EVTS) transmises par le terminal (MT), le serveur de collecte (CSRV) détermine à l'aide d'un identifiant (TID) reçu du terminal, si l'application de collecte doit être activée sur le terminal, et transmet au terminal un message déclenchement d'une opération de désactivation si l'application de collecte ne doit pas être activée sur le terminal.
12. Procédé selon l'une des revendications 1 à 11 , dans lequel le message de déclenchement d'opération (DOP) est transmis au terminal (MT) sous la forme d'un message de type SMS, ou conforme au protocole OMA PUSH OTA over WSP ou au protocole OMA Push OTA over HTTP, ou encore transmis collectivement à plusieurs terminaux destinataires en association avec une liste d'identifiants des terminaux destinataires, dans des flux de données structurées ou des tables binaires.
13. Terminal mobile (MT) configuré pour recevoir un message de déclenchement (DOP) d'une opération (OP) par le terminal mobile par l'intermédiaire d'un réseau de communication (MNT), caractérisé en ce qu'il est configuré pour envoyer un identifiant à un serveur (VSRV) en réponse à la réception du message d'activation (DOP), et activer l'opération (OP) seulement s'il reçoit du serveur un message de réponse positif (REP) autorisant le déclenchement de l'opération.
14. Terminal selon la revendication 13, dans lequel l'identifiant (CID) identifie une entité (CSRV) ayant transmis le message de déclenchement (DOP) au terminal mobile (MT).
15. Terminal selon la revendication 13 ou 14, configuré pour transmettre un message de notification (NOT) à une entité émettrice (CSRV) du message de déclenchement (DOP), indiquant que l'opération a été déclenchée.
16. Terminal selon l'une des revendications 13 à 15, configuré pour transmettre au serveur (VSRV) des informations relatives à l'opération à déclencher (OP) reçues sous forme chiffrée dans le message de déclenchement (DOP), et recevoir du serveur (VSRV) dans le message de réponse (REP) les informations relatives à l'opération à déclencher (OP) sous forme déchiffrée.
17. Terminal selon l'une des revendications 13 à 16, dans lequel le message de réponse (REP) reçu comprend des informations complémentaires relatives à l'opération à déclencher (OP).
18. Terminal selon l'une des revendications 13 à 17, configuré pour établir avec le serveur (VSRV) un lien de communication sécurisé.
19. Terminal selon l'une des revendications 13 à 18, dans lequel l'opération à déclencher (OP) est l'activation d'une application de collecte d'informations d'usage (UC) d'une application à surveiller installée dans le terminal mobile (MT), le message de déclenchement d'opération (DOP) comprenant des informations relatives à une campagne de collecte et une adresse d'un serveur de collecte (CSRV) à qui des informations d'usage (EVTS) collectées par le terminal sont à transmettre, l'exécution de l'application de collecte par le terminal comprenant des étapes de collecte et de mémorisation d'informations d'usage relatives à l'application à surveiller, et de transmission des informations d'usage collectées au serveur de collecte.
20. Terminal selon la revendication 19, dans lequel l'application à surveiller est une application de réception et de restitution de programmes audio et/ou vidéo.
21. Terminal selon la revendication 20, dans lequel le message de déclenchement d'opération (DOP) est transmis au terminal (MT) sous la forme d'un message de type SMS, ou conforme au protocole OMA PUSH OTA over WSP ou au protocole OMA Push OTA over HTTP, ou encore transmis collectivement à plusieurs terminaux destinataires en association avec une liste d'identifiants des terminaux destinataires, dans des flux de données structurées ou des tables binaires.
PCT/FR2009/000840 2008-07-11 2009-07-08 Procede de declenchement d'une operation dans un terminal mobile WO2010004138A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0803990A FR2933836B1 (fr) 2008-07-11 2008-07-11 Procede de declenchement d'une operation dans un terminal mobile
FR08/03990 2008-07-11

Publications (1)

Publication Number Publication Date
WO2010004138A1 true WO2010004138A1 (fr) 2010-01-14

Family

ID=40547443

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/000840 WO2010004138A1 (fr) 2008-07-11 2009-07-08 Procede de declenchement d'une operation dans un terminal mobile

Country Status (2)

Country Link
FR (1) FR2933836B1 (fr)
WO (1) WO2010004138A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2346716A (en) * 1998-11-25 2000-08-16 Ibm Distribution of applications to intermittently connected clients
WO2004040923A1 (fr) * 2002-11-01 2004-05-13 Nokia Corporation Mini-applications disponibles
WO2005039179A2 (fr) * 2003-10-17 2005-04-28 Nokia Corporation Systeme et terminal associe, procede et programme informatique permettant d'enregistrer des statistiques se rapportant a l'utilisation de contenus
EP1574928A1 (fr) * 2002-12-12 2005-09-14 Fujitsu Limited Appareil de controle d'execution de programme, systeme d'exploitation, terminal client, serveur, systeme de controle d'execution de programme, procede de controle d'execution de programme, et programme de controle d'execution de programme
EP1798999A1 (fr) * 2005-12-14 2007-06-20 Sagem Communication Methode de gestion du comportement d'une application interactive lors de la diffusion d'un programme selon la norme DVB-H

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2346716A (en) * 1998-11-25 2000-08-16 Ibm Distribution of applications to intermittently connected clients
WO2004040923A1 (fr) * 2002-11-01 2004-05-13 Nokia Corporation Mini-applications disponibles
EP1574928A1 (fr) * 2002-12-12 2005-09-14 Fujitsu Limited Appareil de controle d'execution de programme, systeme d'exploitation, terminal client, serveur, systeme de controle d'execution de programme, procede de controle d'execution de programme, et programme de controle d'execution de programme
WO2005039179A2 (fr) * 2003-10-17 2005-04-28 Nokia Corporation Systeme et terminal associe, procede et programme informatique permettant d'enregistrer des statistiques se rapportant a l'utilisation de contenus
EP1798999A1 (fr) * 2005-12-14 2007-06-20 Sagem Communication Methode de gestion du comportement d'une application interactive lors de la diffusion d'un programme selon la norme DVB-H

Also Published As

Publication number Publication date
FR2933836B1 (fr) 2010-09-17
FR2933836A1 (fr) 2010-01-15

Similar Documents

Publication Publication Date Title
US20230360063A1 (en) Systems and methods for advertisement tracking
US10321199B2 (en) Streaming with optional broadcast delivery of data segments
KR101729551B1 (ko) 브로드캐스트 서비스 및 브로드캐스트 콘텐츠 중 하나 이상에 대한 시청률을 단말 내에서 조사하는 방법
US20180373847A1 (en) Broadcast DRM License Support for Receive Only Devices
EP2084604A2 (fr) Méthode de chargement et de gestion d'une application dans un équipement mobile
US20080155112A1 (en) System and method for updating information feeds
US8619993B2 (en) Content protection for OMA broadcast smartcard profiles
US20030120940A1 (en) Location-based content protection
US8279342B2 (en) System for receiving and storing broadcast content, and device for reception and storage
WO2003038674A1 (fr) Systeme et procede permettant d'obtenir une passerelle push entre des dispositifs grand public et des centres de fournisseurs de contenu a distance
EP3087720B1 (fr) Technique de contrôle du routage d'une requête relative a un service
EP1722564A1 (fr) Méthode d'accès conditionnel local pour équipements mobiles
US8266420B2 (en) System and method for providing secure configuration file provisioning
WO2003077550A1 (fr) Systeme et procede de transfert d'un mms entre une unite de communication de messages et une tv numerique
EP1553719B1 (fr) Système de distribution d'un contenu, procédé et serveur associé
KR20070050325A (ko) 휴대 방송 시스템에서 암호화 정보 송수신 방법 및 그에따른 시스템
WO2010004138A1 (fr) Procede de declenchement d'une operation dans un terminal mobile
CN102754471A (zh) 在内容传输系统中用于报告客群分析的方法和装置
US9344480B2 (en) Method of providing wireless data communication service using IP and apparatus thereof
CN116266192A (zh) 影像数据管理方法及系统
JP2005204212A (ja) 表示装置、通信端末及びそれらを用いた情報通信システム
FR2925810A1 (fr) Procede de communicatin entre un terminal et un reseau de communication
FR3116921A1 (fr) Périphérique connecté à un terminal, terminal et serveur configurés pour gérer une preuve de propriété, par le terminal, d’une donnée générée par le périphérique
CN117376824A (zh) 定位服务方法、设备、架构及介质
FR3112265A1 (fr) Procédé de notification d’un équipement de gestion d’évènements de la survenue d’au moins un évènement relatif à un premier terminal de communication, et dispositifs associés

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: 09794010

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: CONSTATATION DE LA PERTE D UN DROIT CONFORMEMENT A LA REGLE 112(1) CBE (OEB FORM 1205A EN DATE DU 24/03/2011)

122 Ep: pct application non-entry in european phase

Ref document number: 09794010

Country of ref document: EP

Kind code of ref document: A1