FR2972098A1 - Distribution d'applications dans un reseau - Google Patents
Distribution d'applications dans un reseau Download PDFInfo
- Publication number
- FR2972098A1 FR2972098A1 FR1151614A FR1151614A FR2972098A1 FR 2972098 A1 FR2972098 A1 FR 2972098A1 FR 1151614 A FR1151614 A FR 1151614A FR 1151614 A FR1151614 A FR 1151614A FR 2972098 A1 FR2972098 A1 FR 2972098A1
- Authority
- FR
- France
- 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
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
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, caractérisé en ce que, 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é comporte les étapes préalables de : - 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(ST1), 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 un serveur central de contrôle (SCC).
Description
Distribution d'applications dans un réseau
10 La présente invention concerne de manière générale la distribution d'applications dans les réseaux de télécommunications. On connait 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 15 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, 20 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 25 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 30 téléchargement d'une application sur un terminal utilisateur via un premier serveur de téléchargement associé au premier réseau, 15 caractérisé en ce que, 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é comporte les étapes préalables de : - réception, par un second serveur de téléchargement associé au second 5 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 10 - transmission d'un message contenant des informations relatives au téléchargement de l'application, depuis le second serveur de téléchargement vers un 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 15 réseau par son développeur. 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 20 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 oeuvre de l'invention.
Selon une caractéristique préférée, le procédé comporte en outre une 25 é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 30 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, depuis le premier serveur de téléchargement, d'un message comportant des règles relatives aux applications susceptibles d'être téléchargée via le premier serveur, vers le serveur central de contrôle.
Ainsi, le premier réseau peut définir les types d'applications issues du second réseau qui sont potentiellement téléchargeables depuis ses installations. 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 via 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. 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 via le premier serveur. 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. 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 30 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é, ~o 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, 15 - 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 20 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.
25 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é.
Ces différents dispositifs présentent des avantages analogues à ceux du 30 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 oeuvre dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre 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 disc) 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 oeuvre 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 oeuvre 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 à I'itinérance (en Anglais : roaming) de terminaux de téléphonie mobile entre les réseaux RES1 et RES2.
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.
~o 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 : 15 - 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, 20 - 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, 25 - 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 30 exporte S2 vers le serveur central de contrôle SOC. 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 SOC. 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 S11, 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. Celui-ci peut alors 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 10 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 15 é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. 20 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 à 25 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 30 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 5 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.
10 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. 15 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 20 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 25 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 30 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 25 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 30 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 5 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 10 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. 15 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. 20 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 SOC. 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 25 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 30 Account Procedure 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 inter- ré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 SOC.
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 SOC, à 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 (12)
- REVENDICATIONS1. 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, caractérisé en ce que, l'application téléchargée étant mémorisée dans ~o une entité (BD2, TD2) située dans un second réseau interconnecté au premier réseau, le procédé comporte les étapes préalables de : - 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, 15 - é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 20 vers un 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 25 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 30 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 (S2), depuis le premier serveur de téléchargement, d'un message comportant des règles relatives aux applications susceptibles d'être téléchargée via le premier serveur, 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 l'envoi (S8), par le second serveur de téléchargement, d'une liste d'applications susceptibles d'être téléchargée via 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.
- 6. Procédé selon les revendications 4 et 5, 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ée via le premier serveur.
- 7. 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é 20 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 25 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. 30
- 8. 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 7,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 5 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
- 9. 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. 15
- 10. Système comportant au moins un serveur de téléchargement selon la revendication 7, au moins un serveur de téléchargement selon la revendication 8 et un serveur central de contrôle selon la revendication 9. 20
- 11. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 6 lorsque ledit programme est exécuté par un ordinateur.
- 12. Support d'enregistrement lisible par un ordinateur sur lequel est 25 enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 6.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1151614A FR2972098A1 (fr) | 2011-02-28 | 2011-02-28 | Distribution d'applications dans un reseau |
| EP12709948.9A EP2681899A1 (fr) | 2011-02-28 | 2012-02-21 | Distribution d'applications dans un réseau |
| PCT/FR2012/050369 WO2012117185A1 (fr) | 2011-02-28 | 2012-02-21 | Distribution d'applications dans un réseau |
| US14/002,042 US20140059181A1 (en) | 2011-02-28 | 2012-02-21 | Distribution of applications in a network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1151614A FR2972098A1 (fr) | 2011-02-28 | 2011-02-28 | Distribution d'applications dans un reseau |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2972098A1 true FR2972098A1 (fr) | 2012-08-31 |
Family
ID=45873180
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1151614A Withdrawn FR2972098A1 (fr) | 2011-02-28 | 2011-02-28 | Distribution d'applications dans un reseau |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20140059181A1 (fr) |
| EP (1) | EP2681899A1 (fr) |
| FR (1) | FR2972098A1 (fr) |
| WO (1) | WO2012117185A1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3472993B1 (fr) * | 2016-06-20 | 2022-04-27 | Orange | Procédé de détermination d'un ensemble de formats de codage pour établir une communication |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105511788B (zh) * | 2015-12-08 | 2019-04-30 | 惠州Tcl移动通信有限公司 | 一种移动终端的图片放大显示方法及系统 |
| CN118524093A (zh) * | 2024-05-22 | 2024-08-20 | 中国电信股份有限公司技术创新中心 | 应用程序下载方法、装置、通信设备和可读存储介质 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2598426C (fr) * | 2005-02-22 | 2011-10-18 | 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 |
-
2011
- 2011-02-28 FR FR1151614A patent/FR2972098A1/fr not_active Withdrawn
-
2012
- 2012-02-21 WO PCT/FR2012/050369 patent/WO2012117185A1/fr not_active Ceased
- 2012-02-21 US US14/002,042 patent/US20140059181A1/en not_active Abandoned
- 2012-02-21 EP EP12709948.9A patent/EP2681899A1/fr not_active Withdrawn
Non-Patent Citations (7)
| Title |
|---|
| BRAD CAIN CEREVA NETWORKS OLIVER SPATSCHECK KOBUS VAN DER MERWE AT&T LISA AMINI IBM RESEARCH ABBIE BARBIR NORTEL NETWORKS MARTIN M: "Content Network Advertisement Protocol (CNAP) <draft-cain-cdi-cnap-02.txt>; draft-cain-cdi-cnap-02.txt", IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, no. 2, 1 July 2002 (2002-07-01), XP015000416, ISSN: 0000-0004 * |
| DAY CISCO B CAIN STORIGEN G TOMLINSON TOMLINSON GROUP P RZEWSKI MEDIA PUBLISHER M ET AL: "A Model for Content Internetworking (CDI); rfc3466.txt", IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, 1 February 2003 (2003-02-01), XP015009249, ISSN: 0000-0003 * |
| GILLETTI CACHEFLOW R NAIR CISCO J SCHARBER CACHEFLOW J GUHA APOGEE D: "Content Internetworking (CDI) Authentication, Authorization, and Accounting Requirements; draft-ietf-cdi-aaa-reqs-00.txt", IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, vol. cdi, 1 February 2002 (2002-02-01), XP015016669, ISSN: 0000-0004 * |
| GREEN CACHEFLOW B CAIN CEREVA NETWORKS G TOMLINSON CACHEFLOW S THOMAS TRANSNEXUS P RZEWSKI INKTOMI M: "Content Internetworking Architectural Overview; draft-green-cdnp-gen-arch-03.txt", IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, no. 3, 2 March 2001 (2001-03-02), XP015013775, ISSN: 0000-0004 * |
| NIVEN-JENKINS VELOCIX (ALCATEL-LUCENT) F LE FAUCHEUR CISCO N BITAR VERIZON B: "Content Distribution Network Interconnection (CDNI) Problem Statement; draft-jenkins-cdni-problem-statement-00.txt", CONTENT DISTRIBUTION NETWORK INTERCONNECTION (CDNI) PROBLEM STATEMENT; DRAFT-JENKINS-CDNI-PROBLEM-STATEMENT-00.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 2 December 2010 (2010-12-02), pages 1 - 18, XP015072819 * |
| RZEWSKI INKTOMI J BAI ADERO N ROBERTSON EXODUS P: "Origin/Access Content Peering for HTTP; draft-rzewski-oacp-00.txt", IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, 1 November 2000 (2000-11-01), XP015034829, ISSN: 0000-0004 * |
| RZEWSKI MEDIA PUBLISHER P ET AL: "Content Internetworking (CDI) Scenarios; rfc3570.txt", IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, 1 July 2003 (2003-07-01), XP015009352, ISSN: 0000-0003 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3472993B1 (fr) * | 2016-06-20 | 2022-04-27 | Orange | Procédé de détermination d'un ensemble de formats de codage pour établir une communication |
Also Published As
| Publication number | Publication date |
|---|---|
| EP2681899A1 (fr) | 2014-01-08 |
| WO2012117185A1 (fr) | 2012-09-07 |
| US20140059181A1 (en) | 2014-02-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| 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 | |
| EP1977329A2 (fr) | Systeme et procedes destines a la generation de contenus mobiles | |
| US20060195864A1 (en) | Portable media device interoperability | |
| EP1204044A1 (fr) | Procédé et système d'optimisation de consultations d'ensembles de données par une pluralité de clients | |
| JP2006209326A (ja) | ピアツーピアコンテンツ配信システム | |
| JP2011108241A (ja) | オンライン取引サービスの調停 | |
| 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 | |
| FR2972098A1 (fr) | Distribution d'applications dans un reseau | |
| EP1933244B1 (fr) | Baladodiffusion sur téléphone mobile | |
| KR101608277B1 (ko) | 맞춤형 음원 제공 시스템 및 그 방법 | |
| US20070233816A1 (en) | Digital media management system and method | |
| WO2011073586A1 (fr) | Pre-chargement de contenu entre un serveur de contenu et au moins un terminal | |
| JP2005242399A (ja) | プッシュ型コンテンツ配信サービスシステム、方法及びサーバ | |
| EP2984786B1 (fr) | Architecture centralisée pour l'établissement de fédérations de distributeurs de contenus | |
| WO2004107705A1 (fr) | Système de gestion de contexte pour un réseau comportant un ensemble hétérogène de terminaux | |
| WO2021198611A1 (fr) | Procede et dispositif de personnalisation de contenu multimedia generique | |
| FR3111510A1 (fr) | Procédé de mise à jour d'un état de présence d'un utilisateur d'un terminal de communication pour un ensemble d'applications de communication | |
| 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) | 情報処理システム、情報提供装置および方法、記録媒体、並びにプログラム | |
| EP2166731B1 (fr) | Système et procédé d'établissement de communications. | |
| EP4154137A1 (fr) | Procede et systeme d'authentification d'un utilisateur aupres d'un serveur d'authentification | |
| JP2004080307A (ja) | 番組制作方法、番組制作装置、番組制作プログラム | |
| FR3005181A1 (fr) | Generation d'un document multimedia personnalise relatif a un evenement |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20131031 |