EP2681899A1 - Distribution d'applications dans un réseau - Google Patents

Distribution d'applications dans un réseau

Info

Publication number
EP2681899A1
EP2681899A1 EP12709948.9A EP12709948A EP2681899A1 EP 2681899 A1 EP2681899 A1 EP 2681899A1 EP 12709948 A EP12709948 A EP 12709948A EP 2681899 A1 EP2681899 A1 EP 2681899A1
Authority
EP
European Patent Office
Prior art keywords
download
server
network
application
download server
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP12709948.9A
Other languages
German (de)
English (en)
Inventor
Nicolas Bihannic
Emile Stephan
Morgan Richomme
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Publication of EP2681899A1 publication Critical patent/EP2681899A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H04W8/245—Transfer of terminal data from a network towards a terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/288—Distributed intermediate devices, i.e. intermediate devices for interaction with other intermediate devices on the same level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles

Definitions

  • the present invention generally relates to the distribution of applications in telecommunication networks.
  • WAC Wholesale Application Community
  • the present invention aims to solve the disadvantages of the prior art by providing a method of distributing applications in a first network to user terminals, including downloading an application to a user terminal via a first download server associated with the first network, the downloaded application being stored in an entity located in a second network interconnected to the first network, the method comprising the preliminary steps of:
  • the same application can be proposed for download in several networks having been presented to only one network by its developer, while allowing a first network, which connects the user terminals, to define the types of applications from a second network, to which the developer presents applications, which are potentially downloadable from his installations.
  • the method further comprises a step of transmitting a message containing information relating to the download of the application from the first download server to the central control server.
  • the central control server is thus aware of the download from the information transmitted by the two download servers involved. This validates this information.
  • the information relating to the downloading of the application comprises at least one identifier of the application, an identifier of the network with which the first server is associated. download and an identifier of the network with which the second download server is associated.
  • This information is useful for properly accounting for the download that has taken place.
  • the method comprises sending, by the second download server, a list of applications that can be downloaded by the first download server and metadata respectively associated with each of the applications, to the server central control.
  • the metadata associated with the application is the description of the application but also data on the popularity of the application. A more exhaustive list of these data is given later.
  • the second network can define the applications from the second network that are potentially downloadable from the first network.
  • the method comprises the selection by the central control server of a subset of applications in the list of applications, according to the rules relating to the applications that may be downloaded by the first download server .
  • the central control server thus performs a filter applications from the second network and downloadable from the first network.
  • the method comprises sending the applications selected by the central control server to the first download server.
  • the method comprises, following the reception by a central transaction server of a publication message sent by the central control server, the sending by the central transaction server of a message indicative of a financial transfer to be made to the first and / or second download server, which informs the end user and / or the distributor of such a financial return.
  • the invention also relates to an application downloading server in a second network intended for user terminals, characterized in that, for an application stored in an entity located in the second network interconnected to a first network, the download server comprises:
  • the invention also relates to an application download server in a first network intended for user terminals, adapted to cooperate with a previously presented server,
  • the download server comprises:
  • the invention also relates to a central control server for downloading applications in a first network, said application being stored in a second network, characterized in that it comprises means for receiving a message containing information relating to the download the application.
  • the invention also relates to a system comprising at least download servers as previously presented and a central control server as previously presented.
  • the invention relates to a system comprising at least one download server in a second network as presented above and a central control server as presented above.
  • the central control server is advantageously physically collocated with the download server in a second network, within the same system which can be a single server, in order to gain speed and reduce costs by storage material.
  • the various steps of the method according to the invention are determined by instructions of computer programs.
  • 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 the steps of a process as described above.
  • 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 shape.
  • the invention also relates to a computer readable information medium, and comprising instructions of the computer programs 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 medium, for example a floppy disk or a disk. hard.
  • the information medium can be a transmissible medium such as an electrical or optical signal, which can be routed via a cable electrical or optical, radio or 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.
  • FIG. 1 schematically represents the different entities of two networks implementing the invention
  • FIG. 2 represents steps prior to an application download, according to the invention
  • FIG. 3 represents a first embodiment of application downloading by a user terminal, according to the invention
  • FIG. 4 represents a second embodiment of application downloading by a user terminal, according to the invention.
  • FIG. 5 represents a third embodiment of application downloading by a user terminal, according to the invention.
  • FIG. 6 represents steps performed after the application download by a user terminal, according to the invention.
  • a first telecommunications network RES1 comprises user terminals, of which only one TU1 is represented.
  • the user terminal TU1 is for example a telephone, or a computer. It conventionally comprises a processor, a read only memory, a random access memory and means of communication, in particular with a download server ST1 also located in the network RES1.
  • the download server ST1 has the conventional structure of a computer, and comprises a processor, a memory dead, a memory and means of communication.
  • the network RES1 also comprises a storage entity, for example a database BD1.
  • the database BD1 has the structure of a computer and comprises a processor, a read only memory, a random access memory and communications means.
  • a second telecommunications network RES2 comprises a TD2 developer terminal, which is a terminal proposing one or more applications to download.
  • the TD2 developer terminal is for example a computer. It conventionally comprises a processor, a read only memory, a random access memory and means of communication, in particular with a download server ST2 also located in the network RES2.
  • the download server ST2 has the conventional structure of a computer, and comprises a processor, a read-only memory, a random access memory and communications means.
  • the network RES2 also comprises a storage entity, for example a database BD2.
  • the database BD2 has the structure of a computer and comprises a processor, a read-only memory, a random access memory and communications means.
  • the networks RES1 and RES2 are interconnected. These include, for example, mobile telephone networks, GPRS or UMTS networks or EPS (Evolved Packet System).
  • the networks RES1 and RES2 are for example the networks of two different operators, whether or not covering the same territory. It should be noted that for at least one of these networks, the download servers and the databases can be implemented according to a CDN (Content Delivery Network) type of technology.
  • CDN type network also uses a function, called Request Routing, to optimize the distribution of applications within the network according to the profiles, contexts and forecasts of the user, the network, the servers and the bases. of data.
  • CDN type networks are intended to interconnect.
  • a central SCC control server and a central transaction server SCT are used in the context of the invention, as explained below. These servers each have the classic structure of a computer. Thus, they each comprise a processor, a read-only memory, a random access memory and communications means.
  • the central control server SCC is the entity called "Data Clearing House” and the central transaction server is the entity called "Data Financial House” of a system allowing the control of financial repayments related to roaming (in English: roaming) of mobile telephone terminals between networks RES1 and RES2.
  • the central control server SCC is physically collocated with the download server ST2 within the second telecommunications network RES2 (for example within a single server), which makes it possible to gain in speed of treatment and reduce storage costs.
  • the number of networks can be greater than two.
  • the download server ST1 produces a periodic edition S1 of the fonts, or rules, that govern the downloading between networks.
  • An edition or update of the fonts includes an identifier of the network RES1 and notification criteria such as:
  • - favorite genres corresponding to the themes of applications, such as games, music, sports for example, - preferred categories, corresponding to a classification of the application according to the nature of its content, for example "all public", or "forbidden to less than 12 years", for example,
  • the storage type preference allows the download server ST1 to specify its preferences as to the storage mode, and therefore the download, of the applications.
  • the download server ST1 exports them (S2) to the central control server SCC. This sending S2 is therefore also periodic.
  • the notification criteria of the network RES1 will allow the central control server SCC to select the applications that will be proposed to the network RES1. In fine, the selected applications will be proposed to the users of the terminals of the network RES1.
  • the metadata of an application includes a developer ID and the following information:
  • the storage preferences of the application allow the developer to specify whether he prefers that the operation of his application is carried out from his own terminal TD2, or in a storage entity RES2 network or in each network likely to propose its application for download to its users.
  • Step S3 is followed by step S4 in which the TD2 developer terminal sends the application and the metadata of the application to the download server ST2.
  • step S5 the download server ST2 updates the list of applications accessible to users of the network RES2, incorporating the application object of step S4.
  • Step S5 is followed by step S6, at which the download server ST2 selects the applications to be exported to the network RES1. This selection is made on the basis of uses in the network RES2. It should be noted that the download server ST2 can also remove an application that it had previously exported to the network RES1.
  • the next step S7 is editing the metadata for each of the applications selected in the previous step.
  • the metadata of an application includes those that were sent to step S4 and received by the download server ST2.
  • the download server ST2 adds a popularity information of the application, based on the number of downloads of this application in the network RES2, that is to say from the download server ST2.
  • the download server ST2 also adds an identifier of the source network RES2. It can still add a developer's payment rule, for example a payback ratio of the purchase price of the application to its developer.
  • step S8 is the publication of the applications and their associated metadata to the central control server SCC. After receiving this data, the central control server SCC stores them in step S9.
  • step S10 is the analysis of the previously received application metadata and the network fonts RES1 sent to step S2.
  • the comparison of these two sets of data makes it possible to determine the applications coming from the network RES2 which can be proposed in the network RES1.
  • the metadata of the applications selected in step S10 are edited by the central control server SCC.
  • the central control server can delete the payback ratio of the purchase price of the application to its developer so that the download server ST1 is not aware. There is therefore a filtering of the information that is provided to the network RES1.
  • the central control server SCC can add information, for example the cumulative number of download of the application through the various networks connected to the central control server SCC.
  • the selected applications and their associated metadata are published by the central control server to the download server ST1.
  • the central control server SCC sends the selected applications and their metadata to the download server ST1 so that the latter can then present them to the users of the terminals of the network RES1.
  • a first embodiment corresponds to the case where the application in question is stored in the terminal of the developer TD2.
  • Step S14 is sending from the terminal TU1 to the download server ST1 a request to obtain the application.
  • the next step S15 is the analysis of this request by the download server ST1.
  • the storage preferences of the application are also analyzed.
  • the next step S16 is the sending by the download server ST1 of a request to obtain the application, to the download server ST2.
  • the request includes a network identifier RES1.
  • the download server ST2 After receiving this request, the download server ST2 sends the terminal TD2 a download request for the application, in step S17.
  • the terminal TD2 responds to this request with an acceptance message in step S18.
  • the download server ST2 sends the download server ST1 a message containing the download address, in the form of a URL (Uniform Resource Locator).
  • a URL Uniform Resource Locator
  • the download server ST1 in turn sends to the user terminal TU1 a message containing the download address in step S20.
  • the next step S21 is the actual download of the application, from the TD2 developer terminal to the user terminal TU1.
  • Step S21 is followed by step S22 at which the user terminal TU1 sends an end of download notification to the download server ST1.
  • the TD2 developer terminal sends an end of download notification to the download server ST2, in step S23.
  • a second embodiment corresponds to the case where the application in question is stored in a database BD2 situated in the network RES2.
  • This embodiment comprises steps S13 to S16 identical to those described with reference to the previous figure.
  • the terminal TU1 selects an application from the network RES2 in step S13.
  • Step S14 is sending from the terminal TU1 to the download server ST1 a request to obtain the application.
  • the next step S15 is the analysis of this request by the download server ST1.
  • the storage preferences of the application are also analyzed.
  • the next step S16 is the sending by the download server ST1 of a request to obtain the application, to the download server ST2.
  • the request includes a network identifier RES1.
  • steps S30 to S33 are performed.
  • step S30 the download server ST2 sends the terminal TD2 a download request for the application.
  • the terminal TD2 responds to this request with an acceptance message in step S31.
  • the terminal TD2 downloads, or "uploads", the application to the database BD2.
  • the database BD2 sends a message to the download server ST2 to indicate the download address of the application.
  • Step S33 is followed by Step S19.
  • step S16 is followed directly from step S19.
  • the download server ST2 sends the download server ST1 a message containing the download address, in the form of a URL (Uniform Resource Locator).
  • a URL Uniform Resource Locator
  • the download server ST1 in turn sends to the user terminal TU1 a message containing the download address in step S20.
  • the next step S34 is the actual download of the application, from the database BD2 to the user terminal TU1.
  • Step S34 is followed by step S22 at which the user terminal TU1 sends an end of download notification to the download server ST1.
  • a third embodiment corresponds to the case where the application in question is stored in a database BD1 located in the network RES1.
  • the case is envisaged where the application is not initially stored in the network RES1, and must therefore be downloaded once from the network RES2 to the network RES1.
  • This embodiment comprises steps S13 to S15 identical to those described with reference to FIG.
  • the terminal TU1 selects an application from the network RES2 in step S13.
  • Step S14 is sending from the terminal TU1 to the download server ST1 a request to obtain the application.
  • the next step S15 is the analysis of this request by the download server ST1.
  • the storage preferences of the application are also analyzed.
  • the next step S40 is the sending by the download server ST1 of a message to signal the request to obtain the application, to the download server ST2.
  • the message includes an identifier of the network RES1.
  • the next step S41 is the sending by the download server ST1 of a request to obtain the application, to the database BD1.
  • steps S42 to S47 are performed. It is assumed here that the application is stored in the database BD2 of the network RES2.
  • step S42 the download server ST1 sends the download server ST2 a download request for the application.
  • the download server ST2 responds to this request by sending to the download server ST1 a message containing the download address of the application, in step S43.
  • the download server ST1 sends the download address of the application to the database BD1.
  • the next step S45 is the actual download of the application, from the database BD2 to the database BD1.
  • Step S45 is followed by step S46 to which the database BD2 sends an end-of-download notification to the download server ST2.
  • Step S47 is followed by step S20.
  • step S41 is followed directly by step S20.
  • step S20 identical to that described with reference to FIG. 3, the download server ST1 sends the user terminal TU1 a message containing the download address.
  • step S49 is the actual download of the application, from the database BD1 to the user terminal TU1.
  • Step S49 is followed by step S50 at which the user terminal TU1 sends an end of download notification to the download server ST1.
  • Step S51 is the generation by the download server ST2 of a message containing information relating to the download of the application.
  • This information comprises at least one identifier of the application, an identifier of the network with which the download server is associated, here the network RES2 and an identifier of the network having benefited from the download, here the network RES1.
  • the message is a TAP message (Transferred
  • Account Procedure record as defined in the GSMA (GSM Association), modified according to the invention to be enriched with information relating to the download of the application.
  • a TAP record includes all the information relating to a transaction, for a user terminal in roaming.
  • a TAP record allows the calculation of payback between operators.
  • the invention therefore proposes to enrich the TAP record and to use it for internetwork application distribution, even when the user terminal is not in a roaming situation.
  • the next step S52 is the sending by the download server ST2 of the message containing information relating to the downloading of the application, to the central control server SCC.
  • the download server ST2 can also send a download notification to the TD2 developer terminal, regardless of the embodiment of the download.
  • the download server ST1 can also generate a message containing information relating to the download of the application to step S54.
  • This information comprises at least one identifier of the application and an identifier of the network with which the download server is associated, here the network RES1.
  • the message has the same structure as the message generated in step S51.
  • the download server ST1 sends the message containing information relating to the download of the application, to the central control server SCC, in the next step S55.
  • the central control server SCC takes into account the message (s) received (s) from the server (s) download, for a given download. It aggregates the received information and sends a publication message to the central transaction server SCT in step S57. This sending can be done periodically and then integrates all downloads made during the past period.
  • the central transaction server SCT defines in step S58 which financial transfer must be made to which network.
  • step S59 it sends a message to the applicable download server (s) to indicate the result of the previous step.
  • Step S59 may be performed periodically, in a period that may be longer than that of step S57.
  • step S60 the download server indicates to the TD2 developer terminal that a financial transfer is attributed to it, following the download of the application by the user terminal TU1 or according to an agreed condition. Indeed, the steps S56 to S60 can be triggered periodically or according to agreed conditions, for example when a predetermined number of download of the application is reached.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un procédé de distribution d'applications dans un premier réseau à destination de terminaux utilisateurs (TU1 ), comprenant le téléchargement d'une application sur un terminal utilisateur via un premier serveur de téléchargement (ST1 ) associé au premier réseau, l'application téléchargée étant mémorisée dans une entité (BD2, TD2) située dans un second réseau interconnecté au premier réseau, le procédé comportant les étapes préalables de : - envoi (S2), depuis le premier serveur de téléchargement, d'un message comportant des règles relatives à des applications susceptibles d'être téléchargées par le premier serveur de téléchargement, vers un serveur central de contrôle (SCC), - réception, par un second serveur de téléchargement (ST1 ) associé au second réseau, d'une requête de téléchargement envoyée depuis le premier serveur de téléchargement (ST1 ), - émission, par le second serveur de téléchargement (ST2), d'un message de réponse à destination du premier serveur de téléchargement(STI ), le message de réponse comportant des données permettant le téléchargement, et - transmission (S52) d'un message contenant des informations relatives au téléchargement de l'application, depuis le second serveur de téléchargement (ST2) vers le serveur central de contrôle (SCC).

Description

Distribution d'applications dans un réseau
La présente invention concerne de manière générale la distribution d'applications dans les réseaux de télécommunications.
On connaît de nos jours les plates-formes en ligne créées par des fabricants de terminaux mobiles ou d'OS (Operating System) pour permettre aux utilisateurs de télécharger des applications. De même, les opérateurs mobiles ont mis en service leurs propres plates-formes de téléchargement d'applications.
Par ailleurs, le consortium WAC (Wholesale Application Community) a pour but de promouvoir des outils de programmation et des interfaces programmatiques qui seront utilisés par les développeurs d'applications. Ainsi, une application développée selon ce protocole sera compatible avec n'importe quelle plate-forme des opérateurs membres de ce consortium.
Cependant, pour qu'une application soit téléchargeable dans les réseaux d'opérateurs différents, il faut que le développeur de l'application la propose individuellement à chaque opérateur et que chaque opérateur l'intègre dans sa plate-forme de téléchargement.
La présente invention a pour but de résoudre les inconvénients de la technique antérieure en fournissant un procédé de distribution d'applications dans un premier réseau à destination de terminaux utilisateurs, comprenant le téléchargement d'une application sur un terminal utilisateur via un premier serveur de téléchargement associé au premier réseau, l'application téléchargée étant mémorisée dans une entité située dans un second réseau interconnecté au premier réseau, le procédé comportant les étapes préalables de :
- envoi, depuis le premier serveur de téléchargement, d'un message comportant des règles relatives à des applications susceptibles d'être téléchargées par le premier serveur de téléchargement, vers un serveur central de contrôle, - réception, par un second serveur de téléchargement associé au second réseau, d'une requête de téléchargement envoyée depuis le premier serveur de téléchargement,
- émission, par le second serveur de téléchargement, d'un message de réponse à destination du premier serveur de téléchargement, le message de réponse comportant des données permettant le téléchargement, et
- transmission d'un message contenant des informations relatives au téléchargement de l'application, depuis le second serveur de téléchargement vers le serveur central de contrôle.
Grâce à l'invention, une même application peut être proposée au téléchargement dans plusieurs réseaux en n'ayant été présentée qu'à un seul réseau par son développeur, tout en permettant à un premier réseau, auquel se connecte les terminaux utilisateurs, de définir les types d'applications issues d'un deuxième réseau, auquel le développeur présente des applications, qui sont potentiellement téléchargeables depuis ses installations.
Les utilisateurs ont par conséquent une offre d'applications téléchargeables plus importantes. Les développeurs d'applications peuvent proposer leurs applications à un plus grand nombre d'utilisateurs. Les opérateurs des réseaux sont susceptibles d'augmenter leurs revenus liés au téléchargement d'applications. Ainsi, chacun des différents acteurs impliqués dans le téléchargement d'applications trouve avantage à la mise en œuvre de l'invention.
Selon une caractéristique préférée, le procédé comporte en outre une étape de transmission d'un message contenant des informations relatives au téléchargement de l'application depuis le premier serveur de téléchargement vers le serveur central de contrôle.
Le serveur central de contrôle a ainsi connaissance du téléchargement à partir des informations transmises par les deux serveurs de téléchargement impliqués. Cela permet de valider ces informations.
Selon une caractéristique préférée, les informations relatives au téléchargement de l'application comportent au moins un identifiant de l'application, un identifiant du réseau avec lequel est associé le premier serveur de téléchargement et un identifiant du réseau avec lequel est associé le second serveur de téléchargement.
Ces informations sont utiles pour bien comptabiliser le téléchargement qui a eu lieu.
Selon une caractéristique préférée, le procédé comporte l'envoi, par le second serveur de téléchargement, d'une liste d'applications susceptibles d'être téléchargée par le premier serveur de téléchargement et de métadonnées respectivement associées à chacune des applications, vers le serveur central de contrôle. Par exemple, les métadonnées associées à l'application sont la description de l'application mais aussi des données relatives à la popularité de l'application. Une liste plus exhaustive de ces données est donnée par la suite.
Ainsi, le second réseau peut définir les applications issues du second réseau et qui sont potentiellement téléchargeables depuis le premier réseau.
Selon une caractéristique préférée, le procédé comporte la sélection par le serveur central de contrôle d'un sous-ensemble d'applications dans la liste d'applications, en fonction des règles relatives aux applications susceptibles d'être téléchargée par le premier serveur de téléchargement.
Le serveur central de contrôle effectue donc un filtrage des applications issues du second réseau et téléchargeable depuis le premier réseau.
Selon une caractéristique préférée, le procédé comporte l'envoi des applications sélectionnées par le serveur central de contrôle vers le premier serveur de téléchargement.
Selon une autre caractéristique préférée, le procédé comporte, suite à la réception par un serveur central de transaction d'un message de publication émis par le serveur central de contrôle, l'envoi par le serveur central de transaction d'un message indicatif d'un reversement financier à effectuer vers le premier et/ou le deuxième serveur de téléchargement, ce qui permet d'informer l'utilisateur final et/ou le distributeur d'un tel reversement financier. L'invention concerne aussi un serveur de téléchargement d'applications dans un second réseau à destination de terminaux utilisateurs, caractérisé en ce que, pour une application mémorisée dans une entité située dans le second réseau interconnecté à un premier réseau, le serveur de téléchargement comporte :
- des moyens de réception d'une requête de téléchargement envoyée depuis un premier serveur de téléchargement associé au premier réseau,
- des moyens d'émission d'un message de réponse à destination du premier serveur de téléchargement, le message de réponse comportant des données permettant le téléchargement, et
- des moyens de transmission d'un message contenant des informations relatives au téléchargement de l'application vers un serveur central de contrôle.
L'invention concerne aussi un serveur de téléchargement d'applications dans un premier réseau à destination de terminaux utilisateurs, adapté à coopérer avec un serveur précédemment présenté,
caractérisé en ce que, pour une application mémorisée dans une entité située dans le second réseau interconnecté à un premier réseau, le serveur de téléchargement comporte :
- des moyens d'émission d'une requête de téléchargement à destination du serveur de téléchargement associé au second réseau,
- des moyens de réception d'un message de réponse depuis le serveur de téléchargement associé au second réseau, le message de réponse comportant des données permettant le téléchargement.
L'invention concerne encore un serveur central de contrôle pour le téléchargement d'application dans un premier réseau, ladite application étant mémorisée dans un second réseau, caractérisé en ce qu'il comporte des moyens de réception d'un message contenant des informations relatives au téléchargement de l'application. L'invention concerne aussi un système comportant au moins des serveurs de téléchargement tels que précédemment présentés et un serveur central de contrôle tel que précédemment présenté. En particulier, l'invention concerne un système comportant au moins un serveur de téléchargement dans un second réseau tel que présenté précédemment et un serveur central de contrôle tel que présenté précédemment. En d'autres termes, le serveur central de contrôle est avantageusement colocalisé physiquement avec le serveur de téléchargement dans un second réseau, au sein d'un même système qui peut être un unique serveur, afin de gagner en rapidité et de réduire les coûts en matière de stockage.
Ces différents dispositifs présentent des avantages analogues à ceux du procédé précédemment présenté.
Dans un mode particulier de réalisation, les différentes étapes du procédé selon l'invention sont déterminées par des instructions de programmes d'ordinateurs.
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 des étapes d'un procédé tel que décrit ci-dessus.
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 des programmes d'ordinateur tels que mentionnés 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.
D'autres caractéristiques et avantages apparaîtront à la lecture de modes de réalisation préférés décrits en référence aux figures dans lesquelles :
- la figure 1 représente de façon schématique les différentes entités de deux réseaux mettant en œuvre l'invention,
- la figure 2 représente des étapes préalables à un téléchargement d'application, selon l'invention,
- la figure 3 représente un premier mode de réalisation de téléchargement d'application par un terminal utilisateur, selon l'invention,
- la figure 4 représente un deuxième mode de réalisation de téléchargement d'application par un terminal utilisateur, selon l'invention,
- la figure 5 représente un troisième mode de réalisation de téléchargement d'application par un terminal utilisateur, selon l'invention, et
- la figure 6 représente des étapes effectuées après le téléchargement d'application par un terminal utilisateur, selon l'invention.
On s'intéresse ici au téléchargement d'application sur des terminaux utilisateurs. On ne décrit donc que les entités impliquées dans ce téléchargement.
Selon un mode de réalisation de l'invention représenté à la figure 1 , un premier réseau de télécommunications RES1 comporte des terminaux utilisateurs, dont un seul TU1 est représenté. Le terminal utilisateur TU1 est par exemple un téléphone, ou un ordinateur. Il comporte classiquement un processeur, une mémoire morte, une mémoire vive et des moyens de communications, notamment avec un serveur de téléchargement ST1 également situé dans le réseau RES1 . Le serveur de téléchargement ST1 a la structure classique d'un ordinateur, et comporte un processeur, une mémoire morte, une mémoire vive et des moyens de communications. Le réseau RES1 comporte également une entité de mémorisation, par exemple une base de données BD1 . La base de données BD1 a la structure d'un ordinateur et comporte un processeur, une mémoire morte, une mémoire vive et des moyens de communications.
Un second réseau de télécommunications RES2 comporte un terminal dit développeur TD2, qui est un terminal proposant une ou des applications à télécharger. Le terminal développeur TD2 est par exemple un ordinateur. Il comporte classiquement un processeur, une mémoire morte, une mémoire vive et des moyens de communications, notamment avec un serveur de téléchargement ST2 également situé dans le réseau RES2. Le serveur de téléchargement ST2 a la structure classique d'un ordinateur, et comporte un processeur, une mémoire morte, une mémoire vive et des moyens de communications. Le réseau RES2 comporte également une entité de mémorisation, par exemple une base de données BD2. La base de données BD2 a la structure d'un ordinateur et comporte un processeur, une mémoire morte, une mémoire vive et des moyens de communications.
Les réseaux RES1 et RES2 sont interconnectés. Il s'agit par exemple de réseaux de téléphonie mobile, de type GPRS ou UMTS ou encore EPS (Evolved Packet System). Les réseaux RES1 et RES2 sont par exemple les réseaux de deux opérateurs différents, couvrant ou non le même territoire. Il est à noter que pour un des ces réseaux au moins, les serveurs de téléchargement et les bases de données peuvent être mis en œuvre selon une technologie de type CDN (Content Delivery Network). Un réseau de type CDN utilise en plus une fonction, nommée Request Routing, d'optimisation de la distribution des applications au sein du réseau en fonction des profils, des contextes et des prévisions de l'utilisateur, du réseau, des serveurs et des bases de données. Les réseaux de type CDN ont vocation à s'interconnecter. Dans ce cas, ils exploitent les données échangées avec le serveur central SCC pour sélectionner les applications à recommander aux utilisateurs et le réseau le plus à même de distribuer l'application choisie, selon un critère de proximité ou de coût ou d'optimisation de bande passante, par exemple. Un serveur central de contrôle SCC et un serveur central de transaction SCT sont utilisés dans le cadre de l'invention, comme expliqué dans la suite. Ces serveurs ont chacun la structure classique d'un ordinateur. Ainsi, ils comportent chacun un processeur, une mémoire morte, une mémoire vive et des moyens de communications.
Par exemple, le serveur central de contrôle SCC est l'entité appelée « Data Clearing House » et le serveur central de transaction est l'entité appelée « Data Financial House » d'un système permettant le contrôle des reversements financiers liés à l'itinérance (en Anglais : roaming) de terminaux de téléphonie mobile entre les réseaux RES1 et RES2. Dans un mode de réalisation particulier, le serveur central de contrôle SCC est colocalisé physiquement avec le serveur de téléchargement ST2 au sein du second réseau de télécommunications RES2 (par exemple au sein d'un unique serveur), ce qui permet de gagner en rapidité de traitement et de réduire les coûts en matière de stockage.
Bien entendu, le nombre de réseaux peut être supérieur à deux.
Les interactions entre les différentes entités impliquées pour le téléchargement d'une application par le terminal utilisateur TU1 vont maintenant être détaillées à l'aide des organigrammes des figures 2 à 6.
Dans ce qui suit, on suppose que le réseau RES2 est le réseau source de l'application et que le terminal consommateur de cette application est dans le réseau RES1 . Bien entendu, chacun des réseaux peut être source et consommateur vis-à-vis de l'autre. Selon un mode de réalisation de l'invention représenté à la figure 2, le serveur de téléchargement ST1 réalise une édition périodique S1 des polices, ou règles, qui régissent le téléchargement inter-réseaux. Une édition, ou mise à jour, des polices comporte un identifiant du réseau RES1 et des critères de notifications tels que :
- des genres préférés, correspondant aux thèmes des applications, tels que jeu, musique, sport par exemple, - des catégories préférées, correspondant à une classification de l'application selon la nature de son contenu, par exemple « tout public », ou « interdit aux moins de 12 ans », par exemple,
- le prix,
- la langue,
- la popularité souhaitée,
- la compatibilité avec la gamme de terminaux du réseau,
- les réseaux partenaires privilégiés,
- la préférence de type de stockage.
La préférence de type de stockage permet au serveur de téléchargement ST1 de préciser ses préférences quant au mode de stockage, et par conséquent de téléchargement, des applications.
Une fois les polices éditées, le serveur de téléchargement ST1 les exporte (S2) vers le serveur central de contrôle SCC. Cet envoi S2 est donc également périodique.
Les critères de notification du réseau RES1 vont permettre au serveur central de contrôle SCC de sélectionner les applications qui seront proposées au réseau RES1 . In fine, les applications sélectionnées seront proposées aux utilisateurs des terminaux du réseau RES1 .
On suppose que le terminal développeur TD2 a développé une nouvelle application. Au cours d'une étape S3, il édite les métadonnées associées à cette application. Les métadonnées d'une application comportent un identifiant de développeur et les informations suivantes :
- un identifiant de l'application,
- le genre de l'application,
- la catégorie de l'application,
- le prix de l'application,
- la langue de l'application,
- la version de l'application,
- l'espace mémoire requis par l'application,
- la compatibilité de l'application avec les différents types de terminaux,
- les préférences de stockage de l'application. Les préférences de stockage de l'application permettent au développeur de préciser s'il préfère que l'exploitation de son application soit effectuée à partir de son propre terminal TD2, ou dans une entité de stockage du réseau RES2 ou encore dans chaque réseau susceptible de proposer son application en téléchargement à ses utilisateurs.
L'étape S3 est suivie de l'étape S4 au cours de laquelle le terminal développeur TD2 envoie l'application et les métadonnées de l'application au serveur de téléchargement ST2.
A l'étape suivante S5, le serveur de téléchargement ST2 met à jour la liste des applications accessibles aux utilisateurs du réseau RES2, en y intégrant l'application objet de l'étape S4.
L'étape S5 est suivie de l'étape S6, à laquelle le serveur de téléchargement ST2 sélectionne les applications à exporter vers le réseau RES1 . Cette sélection est effectuée sur la base des usages dans le réseau RES2. Il est à noter que le serveur de téléchargement ST2 peut également retirer une application qu'il avait préalablement exportée vers le réseau RES1 .
L'étape suivante S7 est l'édition des métadonnées relatives à chacune des applications sélectionnées à l'étape précédente. Les métadonnées d'une application comportent celles qui ont été envoyées à l'étape S4 et reçues par le serveur de téléchargement ST2. En outre, le serveur de téléchargement ST2 y ajoute une information de popularité de l'application, basée sur le nombre de téléchargements de cette application dans le réseau RES2, c'est-à-dire depuis le serveur de téléchargement ST2.
Le serveur de téléchargement ST2 ajoute également un identifiant du réseau source RES2. Il peut encore ajouter une règle de paiement du développeur, par exemple un ratio de reversement du prix d'achat de l'application vers son développeur.
L'étape suivante S8 est la publication des applications et de leurs métadonnées associées vers le serveur central de contrôle SCC. Après réception de ces données, le serveur central de contrôle SCC les mémorise à l'étape S9.
L'étape suivante S10 est l'analyse des métadonnées d'application précédemment reçues et des polices du réseau RES1 qui ont été envoyées à l'étape S2. La comparaison de ces deux ensembles de données permet de déterminer les applications issues du réseau RES2 qui peuvent être proposées dans le réseau RES1 .
A l'étape suivante S1 1 , les métadonnées des applications sélectionnées à l'étape S10 sont éditées par le serveur central de contrôle SCC. Par exemple, le serveur central de contrôle peut supprimer le ratio de reversement du prix d'achat de l'application vers son développeur pour que le serveur de téléchargement ST1 n'en ait pas connaissance. Il y a donc un filtrage des informations qui sont fournies au réseau RES1 . En outre, le serveur central de contrôle SCC peut ajouter des informations, par exemple le nombre cumulé de téléchargement de l'application à travers les différents réseaux connectés au serveur central de contrôle SCC.
A l'étape suivante S12, les applications sélectionnées et leurs métadonnées associées sont publiées par le serveur central de contrôle vers le serveur de téléchargement ST1 . En d'autres termes, le serveur central de contrôle SCC envoie les applications sélectionnées et leurs métadonnées vers le serveur de téléchargement ST1 afin que celui-ci puisse ensuite les présenter aux utilisateurs des terminaux du réseau RES1 .
On suppose maintenant que l'utilisateur du terminal TU1 sélectionne une application issue du réseau RES2 à l'étape S13.
En référence à la figure 3, un premier mode de réalisation correspond au cas où l'application en question est mémorisée dans le terminal du développeur TD2.
L'étape S14 est l'envoi depuis le terminal TU1 vers le serveur de téléchargement ST1 d'une requête d'obtention de l'application. L'étape suivante S15 est l'analyse de cette requête par le serveur de téléchargement ST1 . Les préférences de stockage de l'application sont également analysées.
On suppose dans ce premier mode de réalisation que l'application est mémorisée dans le terminal du développeur TD2.
L'étape suivante S16 est l'envoi par le serveur de téléchargement ST1 d'une requête pour obtenir l'application, vers le serveur de téléchargement ST2. La requête inclut un identifiant du réseau RES1 .
Après avoir reçu cette requête, le serveur de téléchargement ST2 envoie au terminal TD2 une requête de téléchargement pour l'application, à l'étape S17.
Le terminal TD2 répond à cette requête par un message d'acceptation à l'étape S18.
A l'étape suivante S19, le serveur de téléchargement ST2 envoie au serveur de téléchargement ST1 un message contenant l'adresse de téléchargement, sous forme d'une adresse URL (Uniform Resource Locator).
Le serveur de téléchargement ST1 envoie à son tour au terminal utilisateur TU1 un message contenant l'adresse de téléchargement, à l'étape S20.
L'étape suivante S21 est le téléchargement proprement dit de l'application, depuis le terminal développeur TD2 vers le terminal utilisateur TU1 .
L'étape S21 est suivie de l'étape S22 à laquelle le terminal utilisateur TU1 envoie une notification de fin de téléchargement au serveur de téléchargement ST1 .
De même, le terminal développeur TD2 envoie une notification de fin de téléchargement au serveur de téléchargement ST2, à l'étape S23.
En référence à la figure 4, un deuxième mode de réalisation correspond au cas où l'application en question est mémorisée dans une base de données BD2 située dans le réseau RES2. Ce mode de réalisation comporte des étapes S13 à S16 identiques à celles décrites en référence à la figure précédente.
Le terminal TU1 sélectionne une application issue du réseau RES2 à l'étape S13.
L'étape S14 est l'envoi depuis le terminal TU1 vers le serveur de téléchargement ST1 d'une requête d'obtention de l'application.
L'étape suivante S15 est l'analyse de cette requête par le serveur de téléchargement ST1 . Les préférences de stockage de l'application sont également analysées.
On suppose dans ce deuxième mode de réalisation que l'application est mémorisée dans la base de données BD2.
L'étape suivante S16 est l'envoi par le serveur de téléchargement ST1 d'une requête pour obtenir l'application, vers le serveur de téléchargement ST2. La requête inclut un identifiant du réseau RES1 .
Si l'application n'a pas été préalablement mémorisée dans la base de données BD2, alors les étapes S30 à S33 sont effectuées.
A l'étape S30, le serveur de téléchargement ST2 envoie au terminal TD2 une requête de téléchargement pour l'application.
Le terminal TD2 répond à cette requête par un message d'acceptation à l'étape S31 .
A l'étape suivante S32, le terminal TD2 télécharge, ou « téléverse », l'application sur la base de données BD2.
A l'étape suivante S33, la base de données BD2 envoie un message au serveur de téléchargement ST2 pour lui indiquer l'adresse de téléchargement de l'application.
L'étape S33 est suivie de l'étape S19.
Si l'application a été préalablement mémorisée dans la base de données BD2, c'est-à-dire si les étapes S30 à S33 ont déjà été effectuées pour un téléchargement précédent, alors elles ne sont pas réitérées et l'étape S16 est suivie directement de l'étape S19.
Les étapes suivantes S19 et S20 sont identiques à celles précédemment décrites en référence à la figure 3. A l'étape suivante S19, le serveur de téléchargement ST2 envoie au serveur de téléchargement ST1 un message contenant l'adresse de téléchargement, sous forme d'une adresse URL (Uniform Resource Locator).
Le serveur de téléchargement ST1 envoie à son tour au terminal utilisateur TU1 un message contenant l'adresse de téléchargement, à l'étape S20.
L'étape suivante S34 est le téléchargement proprement dit de l'application, depuis la base de données BD2 vers le terminal utilisateur TU1 .
L'étape S34 est suivie de l'étape S22 à laquelle le terminal utilisateur TU1 envoie une notification de fin de téléchargement au serveur de téléchargement ST1 .
De même, la base de données BD2 envoie une notification de fin de téléchargement au serveur de téléchargement ST2, à l'étape S35. En référence à la figure 5, un troisième mode de réalisation correspond au cas où l'application en question est mémorisée dans une base de données BD1 située dans le réseau RES1 . On prévoit le cas où l'application n'est pas initialement mémorisée dans le réseau RES1 , et doit donc être téléchargée une fois depuis le réseau RES2 vers le réseau RES1 .
Ce mode de réalisation comporte des étapes S13 à S15 identiques à celles décrites en référence à la figure 3.
Le terminal TU1 sélectionne une application issue du réseau RES2 à l'étape S13.
L'étape S14 est l'envoi depuis le terminal TU1 vers le serveur de téléchargement ST1 d'une requête d'obtention de l'application.
L'étape suivante S15 est l'analyse de cette requête par le serveur de téléchargement ST1 . Les préférences de stockage de l'application sont également analysées.
On suppose dans ce troisième mode de réalisation que l'application est mémorisée dans la base de données BD1 , tout en envisageant la possibilité que lors du premier téléchargement, il faille télécharger l'application depuis le réseau RES2 vers le réseau RES1 . L'étape suivante S40 est l'envoi par le serveur de téléchargement ST1 d'un message pour signaler la demande pour obtenir l'application, vers le serveur de téléchargement ST2. Le message inclut un identifiant du réseau RES1 .
L'étape suivante S41 est l'envoi par le serveur de téléchargement ST1 d'une requête pour obtenir l'application, vers la base de données BD1 .
Si l'application n'a pas été préalablement mémorisée dans la base de données BD1 , alors les étapes S42 à S47 sont effectuées. On suppose ici que l'application est mémorisée dans la base de données BD2 du réseau RES2.
A l'étape S42, le serveur de téléchargement ST1 envoie au serveur de téléchargement ST2 une requête de téléchargement pour l'application.
Le serveur de téléchargement ST2 répond à cette requête en envoyant au serveur de téléchargement ST1 un message contenant l'adresse de téléchargement de l'application, à l'étape S43.
A l'étape suivante S44, le serveur de téléchargement ST1 envoie l'adresse de téléchargement de l'application à la base de données BD1 .
L'étape suivante S45 est le téléchargement proprement dit de l'application, depuis la base de données BD2 vers la base de données BD1 .
L'étape S45 est suivie de l'étape S46 à laquelle la base de données BD2 envoie une notification de fin de téléchargement au serveur de téléchargement ST2.
De même, la base de données BD1 envoie une notification de fin de téléchargement au serveur de téléchargement ST1 , à l'étape S47. L'étape S47 est suivie de l'étape S20.
Si l'application a été préalablement mémorisée dans la base de données
BD1 , c'est-à-dire si les étapes S42 à S47 ont déjà été effectuées pour un téléchargement précédent, alors elles ne sont pas réitérées et l'étape S41 est suivie directement de l'étape S20.
A l'étape S20, identique à celle décrite en référence à la figure 3, le serveur de téléchargement ST1 envoie au terminal utilisateur TU1 un message contenant l'adresse de téléchargement. L'étape suivante S49 est le téléchargement proprement dit de l'application, depuis la base de données BD1 vers le terminal utilisateur TU1 .
L'étape S49 est suivie de l'étape S50 à laquelle le terminal utilisateur TU1 envoie une notification de fin de téléchargement au serveur de téléchargement ST1 .
En référence à la figure 6, on décrit maintenant les échanges entre les serveurs de téléchargement ST1 et ST2 et le serveur central de contrôle SCC.
L'étape S51 est la génération par le serveur de téléchargement ST2 d'un message comportant des informations relatives au téléchargement de l'application. Ces informations comportent au moins un identifiant de l'application, un identifiant du réseau avec lequel est associé le serveur de téléchargement, ici le réseau RES2 et un identifiant du réseau ayant bénéficié du téléchargement, ici le réseau RES1 .
De préférence, le message est un message de type TAP (Transferred
Account Procédure record), tel que défini à la GSMA (GSM Association), modifié selon l'invention pour être enrichi des informations relatives au téléchargement de l'application.
De manière classique, un enregistrement TAP comporte l'ensemble des informations relatives à une transaction, pour un terminal utilisateur en situation d'itinérance (en Anglais : roaming). Un enregistrement TAP permet le calcul de reversement entre opérateurs. L'invention propose donc d'enrichir l'enregistrement TAP et de l'utiliser pour la distribution d'application interréseaux, même lorsque le terminal utilisateur n'est pas en situation d'itinérance.
L'étape suivante S52 est l'envoi par le serveur de téléchargement ST2 du message comportant des informations relatives au téléchargement de l'application, au serveur central de contrôle SCC.
Le serveur de téléchargement ST2 peut également envoyer une notification de téléchargement au terminal développeur TD2, quel que soit le mode de réalisation du téléchargement.
Le serveur de téléchargement ST1 peut lui aussi générer un message comportant des informations relatives au téléchargement de l'application à l'étape S54. Ces informations comportent au moins un identifiant de l'application et un identifiant du réseau avec lequel est associé le serveur de téléchargement, ici le réseau RES1 .
Le message a la même structure que le message générée à l'étape S51 . Le serveur de téléchargement ST1 envoie le message comportant des informations relatives au téléchargement de l'application, au serveur central de contrôle SCC, à l'étape suivante S55.
A l'étape suivante S56, le serveur central de contrôle SCC prend en compte les message(s) reçu(s) depuis le ou les serveur(s) de téléchargement, pour un téléchargement donné. Il agrège les informations reçues et envoie un message de publication vers le serveur central de transaction SCT à l'étape S57. Cet envoi peut être fait périodiquement et intègre alors l'ensemble des téléchargements faits pendant la période écoulée.
Le serveur central de transaction SCT définit à l'étape S58 quel reversement financier doit être effectué vers quel réseau. A l'étape S59, il envoie un message vers le ou les serveurs de téléchargement concerné(s) pour indiquer le résultat de l'étape précédente. L'étape S59 peut être effectuée périodiquement, selon une période qui peut être plus longue que celle de l'étape S57.
A l'étape S60, le serveur de téléchargement indique au terminal développeur TD2 qu'un reversement financier lui est attribué, suite au téléchargement de l'application par le terminal utilisateur TU1 ou suivant une condition convenue. En effet, les étapes S56 à S60 peuvent être déclenchée périodiquement ou suivant des conditions convenues, par exemple lorsqu'un nombre prédéterminé de téléchargement de l'application est atteint.

Claims

REVENDICATIONS
1 . Procédé de distribution d'applications dans un premier réseau à destination de terminaux utilisateurs(TUI ), comprenant le téléchargement d'une application sur un terminal utilisateur via un premier serveur de téléchargement (ST1 ) associé au premier réseau, l'application téléchargée étant mémorisée dans une entité (BD2, TD2) située dans un second réseau interconnecté au premier réseau, le procédé comportant les étapes préalables de :
- envoi (S2), depuis le premier serveur de téléchargement, d'un message comportant des règles relatives à des applications susceptibles d'être téléchargées par le premier serveur de téléchargement, vers un serveur central de contrôle (SCC),
- réception, par un second serveur de téléchargement (ST2) associé au second réseau, d'une requête de téléchargement envoyée (S16, S40) depuis le premier serveur de téléchargement,
- émission (S19, S43), par le second serveur de téléchargement, d'un message de réponse à destination du premier serveur de téléchargement, le message de réponse comportant des données permettant le téléchargement, et
- transmission (S52) d'un message contenant des informations relatives au téléchargement de l'application, depuis le second serveur de téléchargement vers le serveur central de contrôle.
2. Procédé selon la revendication 1 , caractérisé en ce qu'il comporte en outre une étape de transmission (S55) d'un message contenant des informations relatives au téléchargement de l'application depuis le premier serveur de téléchargement vers le serveur central de contrôle.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que les informations relatives au téléchargement de l'application comportent au moins un identifiant de l'application, un identifiant du réseau avec lequel est associé le premier serveur de téléchargement et un identifiant du réseau avec lequel est associé le second serveur de téléchargement.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte l'envoi (S8), par le second serveur de téléchargement (ST2), d'une liste d'applications susceptibles d'être téléchargées par le premier serveur de téléchargement et de métadonnées respectivement associées à chacune des applications, vers le serveur central de contrôle.
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comporte la sélection (S10) par le serveur central de contrôle d'un sous-ensemble d'applications dans la liste d'applications, en fonction des règles relatives aux applications susceptibles d'être téléchargées par le premier serveur de téléchargement.
6. Procédé selon la revendication 5, caractérisé en ce qu'il comporte l'envoi (S12) des applications sélectionnées par le serveur central de contrôle vers le premier serveur de téléchargement (ST1 ).
7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce qu'il comporte, suite à la réception (S57) par un serveur central de transaction (SCT) d'un message de publication émis par le serveur central de contrôle (SCC), l'envoi (S59) par le serveur central de transaction d'un message indicatif d'un reversement financier à effectuer vers le premier et/ou le deuxième serveur de téléchargement (ST1 ,ST2).
8. Serveur (ST2) de téléchargement d'applications dans un second réseau à destination de terminaux utilisateurs,
caractérisé en ce que, pour une application mémorisée dans une entité située dans le second réseau interconnecté à un premier réseau, le serveur de téléchargement comporte : - des moyens de réception d'une requête de téléchargement envoyée depuis un premier serveur de téléchargement associé au premier réseau,
- des moyens d'émission d'un message de réponse à destination du premier serveur de téléchargement, le message de réponse comportant des données permettant le téléchargement, et
- des moyens de transmission d'un message contenant des informations relatives au téléchargement de l'application vers un serveur central de contrôle.
9. Serveur (ST1 ) de téléchargement d'applications dans un premier réseau à destination de terminaux utilisateurs, adapté à coopérer avec un serveur selon la revendication 8,
caractérisé en ce que, pour une application mémorisée dans une entité située dans le second réseau interconnecté à un premier réseau, le serveur de téléchargement comporte :
- des moyens d'émission d'une requête de téléchargement à destination du serveur de téléchargement associé au second réseau,
- des moyens de réception d'un message de réponse depuis le serveur de téléchargement associé au second réseau, le message de réponse comportant des données permettant le téléchargement.
10. Serveur central de contrôle (SCC) pour le téléchargement d'application dans un premier réseau, ladite application étant mémorisée dans un second réseau, caractérisé en ce qu'il comporte des moyens de réception d'un message contenant des informations relatives au téléchargement de l'application.
1 1 . Système comprenant au moins un serveur de téléchargement (ST2) selon la revendication 8 et un serveur central de contrôle (SCC) selon la revendication 10.
1 2. Système selon la revendication 1 1 , caractérisé en ce qu'il comporte en outre au moins un serveur de téléchargement (ST1 ) selon la revendication 9.
1 3. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 7 lorsque ledit programme est exécuté par un ordinateur.
14. 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é selon l'une quelconque des revendications 1 à 7.
EP12709948.9A 2011-02-28 2012-02-21 Distribution d'applications dans un réseau Withdrawn EP2681899A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1151614A FR2972098A1 (fr) 2011-02-28 2011-02-28 Distribution d'applications dans un reseau
PCT/FR2012/050369 WO2012117185A1 (fr) 2011-02-28 2012-02-21 Distribution d'applications dans un réseau

Publications (1)

Publication Number Publication Date
EP2681899A1 true EP2681899A1 (fr) 2014-01-08

Family

ID=45873180

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12709948.9A Withdrawn EP2681899A1 (fr) 2011-02-28 2012-02-21 Distribution d'applications dans un réseau

Country Status (4)

Country Link
US (1) US20140059181A1 (fr)
EP (1) EP2681899A1 (fr)
FR (1) FR2972098A1 (fr)
WO (1) WO2012117185A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105511788B (zh) * 2015-12-08 2019-04-30 惠州Tcl移动通信有限公司 一种移动终端的图片放大显示方法及系统
FR3052953A1 (fr) * 2016-06-20 2017-12-22 Orange Procede de controle de l'enregistrement d'un terminal
CN118524093A (zh) * 2024-05-22 2024-08-20 中国电信股份有限公司技术创新中心 应用程序下载方法、装置、通信设备和可读存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006089390A1 (fr) * 2005-02-22 2006-08-31 Nextair Corporation Procede facilitant la connaissance du dispositif mobile de la disponibilite d'applications nouvelles ou mises a jour cote serveur
US20070088852A1 (en) * 2005-10-17 2007-04-19 Zohar Levkovitz Device, system and method of presentation of advertisements on a wireless device
US7877461B1 (en) * 2008-06-30 2011-01-25 Google Inc. System and method for adding dynamic information to digitally signed mobile applications
US20100087184A1 (en) * 2008-10-08 2010-04-08 Research In Motion Limited System and methods for configuring an updating frequency for mobile wireless communications device application updates and related methods
US8453194B2 (en) * 2008-12-17 2013-05-28 Motorola Mobility Llc Method and apparatus for downloading software images to a mobile device and to a home networked device to implement compatible services
US9461996B2 (en) * 2010-05-07 2016-10-04 Citrix Systems, Inc. Systems and methods for providing a single click access to enterprise, SAAS and cloud hosted application
US9244709B2 (en) * 2011-06-13 2016-01-26 Microsoft Technology Licensing, Llc Automatic recognition of web application

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2012117185A1 *

Also Published As

Publication number Publication date
WO2012117185A1 (fr) 2012-09-07
FR2972098A1 (fr) 2012-08-31
US20140059181A1 (en) 2014-02-27

Similar Documents

Publication Publication Date Title
KR101378111B1 (ko) 정액 요금제 가입에 의해 음악 컨텐츠의 디지털 저작권 관리를 제공하는 방법
US20170331885A1 (en) Offline content distribution networks
US20060288112A1 (en) System and methods for storing music selections in network storage and for streaming the selections to a wireless device for playback on the wireless device
US20070078714A1 (en) Automatically matching advertisements to media files
US20090286560A1 (en) System and method for mobile content generation
US20060095339A1 (en) Reservation of digital media items
EP1204044A1 (fr) Procédé et système d'optimisation de consultations d'ensembles de données par une pluralité de clients
FR2870022A1 (fr) Procede et dispositif de distribution de donnees numeriques notamment pour reseau pair-a-pair
WO2019243700A1 (fr) Procédé d'installation d'une fonction réseau virtualisée
EP2230612A1 (fr) Génération de recommandations pour un serveur de contenus
EP1933244B1 (fr) Baladodiffusion sur téléphone mobile
EP2681899A1 (fr) Distribution d'applications dans un réseau
EP2513788A1 (fr) Pre-chargement de contenu entre un serveur de contenu et au moins un terminal
US20070233816A1 (en) Digital media management system and method
EP2984786B1 (fr) Architecture centralisée pour l'établissement de fédérations de distributeurs de contenus
EP1625723A1 (fr) Systeme de gestion de contexte pour un reseau comportant un essemble heterogene de terminaux
EP2656589A1 (fr) Procede et dispositif de communication de donnees numeriques
WO2008050042A2 (fr) Procede et systeme de gestion des capacites informatiques d'un terminal
EP4173254B1 (fr) Procede de mise a jour d'un etat de presence d'un utilisateur d'un terminal de communication pour un ensemble d'applications de communication
WO2021198611A1 (fr) Procede et dispositif de personnalisation de contenu multimedia generique
FR2929480A1 (fr) Procede de determination de donnees complementaires relatives a au moins un contenu, procede pour transmettre ces donnees complementaires, dispositif de traitement et serveur d'applications associes
WO2006136759A2 (fr) Dispositif et procede pour gerer des credits de communication associes a l'utilisation de services par un terminal
Houssos et al. A flexible management architecture for the support of advanced business models in 3G mobile service provision
JP2003122789A (ja) 情報処理システム、情報提供装置および方法、記録媒体、並びにプログラム
WO2021234255A1 (fr) Procede et systeme d'authentification d'un utilisateur aupres d'un serveur d'authentification

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20130920

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20150420

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20160928