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.