FR3025625A1 - Generation et partage d'applications personnalisees de communication - Google Patents

Abstract

La description se rapporte notamment à un procédé de gestion d'applications de communication, comprenant une génération, par un circuit de génération d'applications (GEN_C) d'un ordinateur serveur (SRV1), d'une pluralité d'applications de communication (APP1, APP2, ... APPN). Le procédé comprend également une transmission, par un circuit de partage d'applications (SHR_C) d'un ordinateur serveur (SRV2), de chaque application de communication de la pluralité d'applications de communication (APP1, APP2, ... APPN), à un ensemble respectif de terminaux ({TERMf(1;1), TERMf(1;2), ... TERMf(1,g(1))}, {TERMf(2;1), TERMf(2;2), ... TERMf(2,g(2))}, ... {TERMf(N;1), TERMf(N;2), ... TERMf(N,g(N))}). La description concerne également un dispositif d'éclairage, un programme d'ordinateur et un support de stockage pour la mise en œuvre d'un tel procédé.

Description

1 Génération et partage d'applications personnalisées de communication L'invention se rapporte au domaine du développement d'applications ainsi qu'au domaine des communications électroniques. Il existe dans ce dernier domaine une multitude de technologies disponibles. Pour chaque type de technologie, il existe de surcroît des multitudes d'outils.

On connaît par exemple la communication par e-mail. Cependant, ce type de communications est susceptible d'utiliser différents types de protocoles (des protocoles relativement ouverts tels que SMTP, POP, ou IMAP etc., mais également des protocoles davantage propriétaires tels que les protocoles Exchange de la société Microsoft). Ainsi, même pour une technologie donnée (l'e-mail), on n'est pas nécessairement capable de faire communiquer n'importe quel client e-mail (Eudora, Firebird, Outlook, etc.) avec n'importe quel autre via n'importe quel serveur e-mail (Exchange, etc.), tout en bénéficiant de toutes les fonctionnalités offertes par chacun de ces clients e-mail.

Il existe par ailleurs quantité d'autres technologies de communications électroniques possibles, telles que la messagerie instantanée ("chat" IRC, ICQ, Jabber, ou les webchats - yahoo groups etc.), le microblogue (Twitter, Tumblr, identi.ca, Heello, Jaiku, Soup, Yammer, Sina Weibo, Tencent Weibo etc.), les services de partages de fichiers multimedia (youtube, dailymotion, etc.) et quantité de réseaux sociaux permettant aux usagers d'échanger des messages électroniques (Facebook, Linkedin, etc.) sans parler des technologies issues de la téléphonie mobile (SMS, MMS etc.). La multiplication des canaux de communication et réseaux sociaux fragmente ainsi les communications entre individus, rendant difficile le suivi des communications électroniques publiques et privées. Dans le domaine du développement d'applications, il est connu 3025625 2 (US8694954B2, Ortiz) de proposer un système permettant à des personnes ne connaissant pas de langage de programmation de développer certains types d'applications mobiles, en sélectionnant et agrégeant des modules de base prédéfinies proposant des fonctions élémentaires couramment désirées.

5 Cette technique pose le problème de ne pas permettre de modifier l'application autrement que par l'adjonction ou le retrait d'un bloc préexistant. Il est également connu (W02012148867A1, Soultanov et al) d'accroître la flexibilité des solutions du type de celle décrite au paragraphe précédent en permettant de surcroît à l'utilisateur de télécharger des images de son choix.

10 Mais cette étape reste fastidieuse. La création et l'édition d'une application de communication dédiée à un utilisateur nécessitent donc souvent des compétences techniques, la création d'un compte développeur auprès des plateformes du marché (Apple, Android), et plus généralement un investissement en temps assez substantiel (dû à la 15 complexité de cette tâche). Les solutions alternatives existantes sont soient insuffisamment performantes (pas assez flexibles) soit trop complexes ou simplement trop longues. L'invention vise donc à améliorer la situation.

20 Un aspect de l'invention concerne un procédé de gestion d'applications de communication, comprenant: /d/ une génération, par un circuit de génération d'applications d'un ordinateur serveur, d'une pluralité d'applications de communication, la 25 génération comprenant, pour chaque application de communication de la pluralité d'applications de communication à générer, une modification d'une copie respective d'une application de communication de référence, ladite modification comprenant l'inclusion, dans la copie respective de l'application de communication de référence, de données propres à un utilisateur respectif 30 d'un terminal respectif d'une pluralité de terminaux, 3025625 3 /f/ une transmission, par un circuit de partage d'applications d'un ordinateur serveur, de chaque application de communication de la pluralité d'applications de communication, à un ensemble respectif de terminaux. Ce procédé est avantageux en ce qu'il permet notamment de proposer 5 une plateforme permettant la création automatique et la publication d'applications mobiles personnelles (parce que personnalisées) unifiant par exemple des communications directes et indirectes via des services tiers. Un autre aspect de l'invention concerne un programme d'ordinateur 10 comprenant une suite d'instructions qui, lorsqu'elles sont exécutées par un processeur, conduisent le processeur à mettre en oeuvre un procédé selon l'aspect précité de l'invention. Un autre aspect de l'invention concerne un support de stockage non 15 transitoire lisible par ordinateur, ledit support stockant un programme d'ordinateur selon l'aspect précité de l'invention. Un autre aspect de l'invention concerne un système de gestion d'applications de communication, comprenant un premier ordinateur serveur, 20 un deuxième ordinateur serveur et une pluralité de terminaux, dans lequel: - le premier ordinateur serveur comprend un circuit de génération d'applications agencé pour générer une pluralité d'applications de communication, et, pour chaque application de communication de la pluralité d'applications de communication à générer, pour modifier une copie respective 25 d'une application de communication de référence, ladite modification comprenant l'inclusion, dans la copie respective de l'application de communication de référence, de données propres à un utilisateur respectif d'un terminal respectif de la pluralité de terminaux, - le deuxième ordinateur serveur comprend un circuit de partage 30 d'applications agencé pour transmettre chaque application de communication 302 562 5 4 d'une pluralité d'applications de communication générées par le circuit de génération d'applications du premier ordinateur serveur à un ensemble respectif de terminaux. Les avantages du procédé précité s'appliquent également à ce système.

5 D'autres aspects, buts et avantages de l'invention apparaîtront à la lecture de la description de quelques uns de ses modes de réalisation. L'invention sera également mieux comprise à l'aide de la figure 1, qui illustre un système selon un mode de réalisation possible de l'invention, ainsi 10 que des figures 2, 2a et 2b qui se rapportent à des variantes possibles. Selon un premier mode de réalisation, un système de gestion d'applications de communication comprend un premier ordinateur serveur SRV1, un deuxième ordinateur serveur SRV2 et une pluralité de terminaux 15 TERM1, TERM2, ... TERMN. Selon une mise en oeuvre possible, le premier et le deuxième ordinateur serveur sont distincts. Selon une autre mise en oeuvre possible les deux serveurs sont intégrés à un même ordinateur (ou à un même groupe d'ordinateurs assurant collectivement les fonctions pertinentes des serveurs considérés). Les terminaux sont par exemple des smartphones 20 (parfois appelés téléphones intelligents en français). Il peut également s'agir d'une tablette tactile, d'un ordinateur portable, ou de tout dispositif électronique personnel programmable. Le premier ordinateur serveur SRV1 comprend un circuit de génération d'applications GEN_C agencé pour générer une pluralité d'applications de 25 communication (par exemple N applications notées APP1, APP2, ... APPN). Pour chaque application de communication de la pluralité d'applications de communication à générer, le circuit de génération d'applications GEN_C est agencé pour modifier une copie respective d'une application de communication de référence. Le circuit GEN_C peut par exemple lire depuis 30 une base de données ou depuis tout support de stockage local ou distant un 3025625 5 fichier contenant l'application de communication de référence, afin de la dupliquer en autant de copies qu'il y a d'applications de communication à générer. Le circuit GEN_C peut alors (en parallèle ou en série) effectuer les modifications de ces copies. La modification comprend l'inclusion, dans la 5 copie respective de l'application de communication de référence, de données propres à un utilisateur respectif U1, U2, ..., UN d'un terminal respectif de la pluralité de terminaux TERM1, TERM2, ... TERMN. Selon une mise en oeuvre possible, les données propres englobent notamment des éléments de simple paramétrage en plus d'éléments effectivement propres à l'utilisateur. Ces 10 éléments de paramétrage peuvent ne pas être propres à l'utilisateur. Selon une mise en oeuvre possible, il n'est ainsi pas nécessaire que chaque sous ensemble possible des données dites propres soit propre à un utilisateur. Nous reviendrons ultérieurement sur différentes manières d'effectuer ces inclusions. On aboutit ainsi à N copies (dans l'exemple supra) dont chacune 15 est personnalisée pour un utilisateur. Dans l'exemple donné, il y a autant d'utilisateurs que de terminaux. Selon une mise en oeuvre possible, à chaque utilisateur (par exemple U3) correspond un unique terminal (TERM3), et réciproquement (à chaque terminal correspond un seul utilisateur). Selon une autre mise en oeuvre, un utilisateur détient et utilise plusieurs terminaux. Selon 20 une autre mise en oeuvre, plusieurs utilisateurs se partagent un même terminal. Le circuit GEN_C est par exemple un circuit comprenant à la fois un processeur et une mémoire stockant un programme d'ordinateur apte à mettre en oeuvre les fonctions de ce circuit. Il peut notamment s'agir d'un processeur 25 du serveur et d'une mémoire du serveur (disque dur et RAM par exemple). Alternativement le circuit GEN_C est un circuit électronique sur mesure (réalisé par exemple sous la forme d'un FPGA ou d'un ASIC, etc.). Le deuxième ordinateur serveur SRV2 comprend un circuit de partage d'applications SHR_C agencé pour transmettre chaque application de 30 communication d'une pluralité d'applications de communication (par exemple, les applications précitées, notées APP1, APP2, ... APPN, qui sont associées respectivement aux utilisateurs U1, U2, ... UN) générées par le circuit de 302 5 6 2 5 6 génération d'applications GEN_C du premier ordinateur serveur SRV1. Le circuit SHR_C transmet ces applications à un ensemble respectif de terminaux. Ainsi, il transmet par exemple l'application APP1 aux terminaux TERMfol), TERNAf(1;2), TERMfo,gm, l'application APP2 aux terminaux 5 TERMf(21), TERMf(2;2), TERMf(2,g(2)), et ainsi de suite jusqu'à l'application APPN, transmise aux terminaux TERMf(N1), TERMf(N;2), TERMf(N,g(N)). La fonction g() indique dans l'exemple précité à combien de terminaux une application donnée doit être transmise. Par exemple, si l'application n°3 est transmise à 12 terminaux, alors g(3)=12. La fonction g() peut être mise en 10 oeuvre sous forme d'un vecteur dont on vient lire le ième élément pour savoir à combien de terminaux envoyer l'application n9. La fonction g() n'est pas nécessairement fixe (elle peut évoluer). Il est évidemment possible de mettre à jour le nombre de terminaux auxquels une application est transmise (on peut alors mettre à jour le vecteur précité représentant la fonction g()). La 15 fonction g() peut potentiellement prendre des valeurs supérieures à N. En effet, le système peut comprendre de nombreux terminaux en plus des terminaux TERM1, TERM2, TERMN de l'exemple envisagé. Ces terminaux peuvent être adaptés pour recevoir des applications personnalisées de personnes tierces sans que leur utilisateur n'ait lui-même l'intention de générer 20 des applications personnalisées. La fonction f() identifie dans l'exemple précité les terminaux auxquels le circuit SHR_C doit transmettre les applications. La fonction f() peut être mise en oeuvre sous la forme d'une matrice, dont les éléments de chaque ligne (par exemple la ligne numéro i) spécifient les terminaux auxquels envoyer une 25 certaine application (par exemple l'application n9). La matrice peut bien sûr être mise à jour. Il est même possible de supprimer de la matrice des identifiants de terminaux qui auraient détruit l'application qu'ils ont reçu ou de terminaux auxquels le système (ou une autre entité) aurait a posteriori interdit l'accès à l'application. Il convient de noter que dans l'exemple précité, la 30 matrice peut comporter N lignes (une pour chaque application), mais peut comporter plus de N colonnes, ou moins de N colonnes. Par exemple, si N=1000, et si l'on sait qu'une application de communication n'est jamais (dans 3025625 7 le système considéré) partagée par plus de 20 terminaux, alors 20 colonnes suffisent. A l'inverse, dans un système comportant 1000 applications personnalisées dites "corporate" pour 1000 petites entreprises, jusqu'à 10000 terminaux susceptibles de recevoir chaque application personnalisée (il peut 5 s'agir par exemple de la limite supportée par le système), et 100000 terminaux en tout, la matrice pourrait avoir 1000 lignes mais 10000 colonnes. Tous les éléments d'une ligne de la matrice ne sont pas nécessairement utilisés. Pour la ligne n°i, les éléments de la colonne g(i)+1 jusqu'à la dernière colonne ne sont pas utilisés.

10 Dans l'exemple précité, il y a N utilisateurs et N applications personnalisées. Selon une autre mise en oeuvre possible, il y a plus d'applications personnalisées que d'utilisateurs (certains utilisateurs générant plusieurs applications personnalisées). Ces fonctions f() et g() peuvent ne pas apparaître (y compris dans 15 l'éventuel logiciel animant ce système), et peuvent n'être que des outils utiles pour décrire le fonctionnement du système. Elles peuvent également être mises en oeuvre d'une manière autre qu'une implémentation respectivement matricielle et vectorielle. Le circuit SHR_C est par exemple un circuit comprenant à la fois un 20 processeur et une mémoire stockant un programme d'ordinateur apte à mettre en oeuvre les fonctions de ce circuit. Il peut notamment s'agir d'un processeur du serveur et d'une mémoire du serveur (disque dur et RAM par exemple). Alternativement le circuit SHR_C est un circuit électronique sur mesure (réalisé par exemple sous la forme d'un FPGA ou d'un ASIC, etc.).

25 Si le premier et le deuxième serveurs sont distincts, le système est agencé pour transmettre les applications de communication générées par le premier serveur au deuxième serveur, ou pour permettre au deuxième serveur de contrôler le premier serveur afin de requérir de sa part la transmission pour son compte d'applications de communication aux terminaux pertinents. Dans 30 l'hypothèse de deux serveurs distincts, le deuxième serveur peut être mis en oeuvre au sein d'un groupe de serveurs tel que celui de la plateforme de téléchargement d'applications en ligne dénommée AppStore de la société 3025625 8 Apple, ou encore du groupe de serveurs équivalent (dénommé Google Play) de la société Google. Selon une mise en oeuvre possible, le système comprend un ordinateur serveur de gestion de communication afin de permettre aux applications de 5 communication générées par le circuit GEN_C d'effectuer leurs communications à travers ce serveur de gestion de communications. Selon une mise en oeuvre possible, les applications de communication sont des applications natives (par opposition à des applications dites "web apps"), et sont signées numériquement (par exemple à l'aide d'un algorithme 10 de cryptographie asymétrique, tel que l'algorithme RSA ou encore tel qu'un algorithme s'appuyant sur des courbes elliptiques). Selon une mise en oeuvre possible, c'est le circuit GEN_C qui effectue la signature numérique (il stocke par exemple, à cet effet, des clés privées de signature). Grâce par exemple à de telles signatures, les applications de 15 communication ne s'écrasent pas les unes les autres lorsqu'on les installe sur un même terminal, alors même qu'elles dérivent toutes d'une même application de communication de référence. Cela fait de chaque application de communication personnalisée une application unique.

20 Selon un deuxième mode de réalisation, chaque terminal (noté par exemple TERIV1i) d'un système de gestion d'applications de communication selon le premier mode de réalisation, comprend un circuit d'authentification AUTH_Ci agencé pour authentifier un utilisateur 1J; dudit terminal TEMA; auprès d'un troisième ordinateur serveur SRV3.

25 Ledit terminal comprend également un circuit d'obtention OBT_Ci agencé pour requérir de la part du troisième ordinateur serveur SRV3 des données propres à un utilisateur 1J; authentifié par le circuit d'authentification AUTH_Ci dudit terminal TEMA. Selon une mise en oeuvre possible, le circuit d'obtention OBT_Ci se contente de requérir les données propres l'un utilisateur 1J; sans 30 pour autant les recevoir (les données étant reçues par une autre entité, par exemple directement par le premier serveur SRV1). La requête est alors une 3025625 9 requête d'envoi, à une autre entité, des données propres à l'utilisateur U. Les circuits AUTH_Ci et OBT_Ci sont par exemple chacun un circuit comprenant à la fois un processeur et une mémoire stockant un programme d'ordinateur apte à mettre en oeuvre les fonctions de ce circuit. Il peut 5 notamment s'agir d'un processeur du terminal et d'une mémoire du terminal (mémoire Flash et RAM par exemple). Alternativement chacun de ces deux circuits est un circuit électronique sur mesure (réalisé par exemple sous la forme d'un FPGA ou d'un ASIC, etc.). Nous avons considéré ci-dessus l'exemple d'un terminal TEM& mais 10 chacun des autres terminaux TERM1, TERM2, TERMN présente les caractéristiques correspondantes et comprend notamment des circuits AUTH_C1 et OBT_Ci , AUTH_C2 et OBT_C2, AUTH_CN et OBT_CN. Le serveur SRV3 est avantageusement un serveur auprès duquel l'utilisateur U1 dispose d'un compte permettant de l'authentifier. Cela permet 15 notamment de s'appuyer sur une relation de confiance préexistante. Le serveur SRV3 est par exemple un serveur de réseau social (tel que Facebook, Google+, Twitter ou autre). Ceci est avantageux car l'utilisateur y dépose (ou s'y fait automatiquement aspirer) de nombreuses données personnelles qui sont alors réutilisables pour personnaliser son application (photos, etc.).

20 Selon un troisième mode de réalisation, chaque terminal TERM; d'un système de gestion d'applications de communication selon le deuxième mode de réalisation comprend un circuit de transmission TRN_Ci agencé pour transmettre, au premier ordinateur serveur SRV1, des données propres à un 25 utilisateur 1.1; authentifié par le circuit d'authentification AUTH_Ci dudit terminal TEM& obtenues par le circuit d'obtention OBT_Ci dudit terminal TEMA. Ainsi, le système peut amener un utilisateur à se connecter à l'aide de son terminal (un smartphone par exemple) à un réseau social (par exemple Facebook), par exemple en lui présentant une fenêtre listant les réseaux 30 sociaux supportés, et lui demandant de cliquer sur celui de son choix auprès duquel il détient un compte. Après authentification, le smartphone reçoit des 3025625 10 données personnelles que l'utilisateur aura choisies simplement et rapidement parmi celles disponibles pour personnaliser son application. Il peut typiquement s'agir de la photo de son profile Facebook, qui peut même être transmise par défaut et automatiquement (sans aucune action de l'utilisateur).

5 Le smartphone peut alors transmettre automatiquement les données personnelles au serveur SRV1. Le circuit TRN_Ci est par exemple un circuit comprenant à la fois un processeur et une mémoire stockant un programme d'ordinateur apte à mettre en oeuvre les fonctions de ce circuit (transmission de données personnelles 10 extraites d'un serveur SRV3 à un serveur SRV1 selon des modalités définies). Il peut notamment s'agir d'un processeur du terminal et d'une mémoire du terminal (mémoire Flash et RAM par exemple). Alternativement le circuit TRN_Ci est un circuit électronique sur mesure (réalisé par exemple sous la forme d'un FPGA ou d'un ASIC, etc.).

15 Les circuits AUTH_Ci, OBT_Ci et TRN_Ci peuvent comprendre un processeur commun et une mémoire physique commune stockant les trois programmes d'ordinateur aptes à mettre en oeuvre les fonctions respectives de ces trois circuits. Il peut notamment s'agir du processeur principal du terminal et d'une mémoire du terminal (mémoire Flash et RAM par exemple).

20 Alternativement un même circuit électronique sur mesure (réalisé par exemple sous la forme d'un FPGA ou d'un ASIC, etc.) peut implémenter les fonctions de ces trois circuits. Nous avons considéré ci-dessus l'exemple d'un terminal TEM& mais chacun des autres terminaux TERM1, TERM2, TERMN présente les 25 caractéristiques correspondantes et comprend notamment un circuit respectif TRN_Ci, TRN_C2 TRN_CN. Selon un quatrième mode de réalisation, chaque application APP; de la pluralité d'applications de communication APP1, APP2, APPN d'un système 30 de gestion d'applications de communication selon le premier, deuxième ou troisième mode de réalisation est prévue pour être installée sur un terminal 3025625 11 TEMA; de l'utilisateur 1J; dont elle contient des données propres, et pour transmettre un même flux d'informations depuis ledit terminal TEMA; à tous les terminaux TERMf(;l), TERNAf(;;2), TERMfo,go» (non représentés) auxquels, à l'instant de la transmission de ce flux d'information, le circuit de partage 5 d'applications SHR_C du deuxième ordinateur serveur SRV2 a déjà transmis ladite application APPi. Chaque utilisateur peut ainsi communiquer une même information aux autres utilisateurs de manière globale (simultanément ou en mode pull).

10 Bien évidemment, si l'un des terminaux auxquels l'application APP1 a été transmise antérieurement ne comporte plus cette application, il n'y a pas lieu de transmettre le flux d'information à ce terminal. Selon un mode de réalisation, un script de désinstallation associé à l'application APP; notifie le système de sa désinstallation (cela s'applique si c'est l'utilisateur de ce 15 terminal qui a décidé de supprimer l'application). Si la désinstallation est initiée via le système (ou lorsque ce n'est pas possible, si le système est agencé pour exclure l'application APP; de ce terminal et pour ne plus communiquer avec cette application de ce terminal), alors par hypothèse le système peut mettre à jour sa liste de terminaux en conséquence.

20 Nous avons considéré ci-dessus l'exemple d'une application APPi, mais chacune des autres applications APP1, APP2, APPN présente les caractéristiques correspondantes. Par ailleurs, nous avons déjà rappelé qu'il pouvait également y avoir plusieurs utilisateurs par terminal ou plusieurs terminaux par utilisateur.

25 Selon un autre mode de réalisation, dont des mises en oeuvre particulières sont illustrées sur les figures 2, 2a et 2b, chaque application de communication d'un système de gestion d'applications de communication selon le premier, deuxième ou troisième mode de réalisation est prévue pour 30 être installée sur le terminal d'au moins un utilisateur autre que celui pour lequel cette application de communication est personnalisée. Chaque 3025625 12 application de communication est de plus agencée pour communiquer en point à point, c'est-à-dire que chaque application de communication est agencée pour ne communiquer une information donnée qu'avec une autre application de communication (d'un terminal donné) à un moment donné. On peut qualifier 5 ce mode de communication de privé (puisqu'il n'implique que deux parties). On observe ainsi, sur la figure 2, un utilisateur U1 générant (flèche verticale) une application APP1 (représentée sous l'utilisateur U1, à la verticale) en passant par un réseau social parmi une pluralité de réseaux sociaux 10 représentés par des cercles quasi concentriques (sur la base desquels il est possible d'extraire des données propres à l'utilisateur). Un utilisateur U1 installe de surcroît une application APP2 (représentée sous l'utilisateur U2, à la verticale) qui est l'application générée par l'utilisateur U2. De façon croisée, on observe sur la figure 2 un utilisateur U2 générant 15 (flèche verticale) une application APP2 (représentée sous l'utilisateur U2, à la verticale) en passant par un réseau social parmi une pluralité de réseaux sociaux représentés par des cercles quasi concentriques. L'utilisateur U2 installe de surcroît une application APP1 (représentée sous l'utilisateur Ui, à la verticale), qui est l'application générée par l'utilisateur Ui.

20 La configuration de la figure 2 permet notamment une utilisation selon la figure 2a. Selon la figure 2a, l'utilisateur Ui a installé l'application de communication APP2 de l'utilisateur U2 et suit les informations diffusées par l'utilisateur U2 via cette application APP2. Selon une mise en oeuvre possible, 25 l'application APP2 lui permet non seulement de recevoir les informations diffusées par U2, mais aussi d'interagir avec U2. La configuration de la figure 2 permet aussi une utilisation selon la figure 2b. Selon la figure 2b, chacun des deux utilisateurs U1 et U2 30 communique avec l'autre utilisateur via l'application de communication de cet autre utilisateur. Ainsi, Ui et U2 peuvent utiliser une fonction de messagerie 3025625 13 instantanée mise en oeuvre par ces applications de communication. Pour écrire à U2, Ui utilise l'application APP2 d'U2, et réciproquement pour écrire à Ui, U2 utilise l'application APP1 d'U1. Ainsi, chaque utilisateur peut disposer sur son terminal d'une multitude 5 d'applications de communication personnalisées chacune en fonction de données propres de l'un des interlocuteurs de cet utilisateur. Chaque utilisateur peut alors utiliser, lorsqu'il entend communiquer avec un interlocuteur donné, l'application de communication qui a été personnalisée pour cet interlocuteur. Ceci permet, au sein du terminal de cet utilisateur, 10 d'améliorer la gestion des flux de communication de cet utilisateur. Selon un cinquième mode de réalisation, un procédé de gestion d'applications de communication, comprend une génération, par un circuit de génération d'applications GEN_C d'un ordinateur serveur SRV1, d'une pluralité 15 d'applications de communication (notées par exemple APP1, APP2, APPN), la génération comprenant, pour chaque application de communication de la pluralité d'applications de communication à générer, une modification d'une copie respective d'une application de communication de référence, ladite modification comprenant l'inclusion, dans la copie respective de l'application 20 de communication de référence, de données propres à un utilisateur respectif (notés par exemple U1, U2, UN) d'un terminal respectif d'une pluralité de terminaux (notés par exemple TERM1, TERM2, TERMN). Le procédé comprend une transmission, par un circuit de partage d'applications SHR_C d'un ordinateur serveur SRV2, de chaque application de 25 communication de la pluralité d'applications de communication à un ensemble respectif de terminaux (un premier ensemble {TERMf(1l), TERMf(1;2), TERMf(1,g(1))}, un deuxième ensemble {TERMf(21), TERMf(2;2), TERMf(2,g(2))}, ... et finalement un Nème ensemble {TERMf(N1), TERMf(N;2), TERMf(N,g(N))}). Ce procédé a vocation à être mis en oeuvre notamment par un système 30 selon le premier mode de réalisation. Les caractéristiques relative à ce procédé sont applicables au système correspondant et réciproquement.

3025625 14 Selon un sixième mode de réalisation, un procédé de gestion d'applications de communication selon le cinquième mode de réalisation comprend une authentification, par un circuit d'authentification AUTH_C1 d'un 5 terminal TERMi de la pluralité de terminaux, d'un utilisateur Ui dudit terminal TERM1, auprès d'un troisième ordinateur serveur SRV3. Le procédé comprend l'envoi d'une requête, par un circuit d'obtention OBT_C1 dudit terminal TERM1 au troisième ordinateur serveur SRV3, visant à obtenir de ce troisième ordinateur serveur SRV3 des données propres à 10 l'utilisateur U1 authentifié par le circuit d'authentification AUTH_C1 dudit terminal TERM1. Ce procédé a vocation à être mis en oeuvre notamment par un système selon le deuxième mode de réalisation. Les caractéristiques relative à ce procédé sont applicables au système correspondant et réciproquement.

15 Selon un septième mode de réalisation, un procédé de gestion d'applications de communication selon le sixième mode de réalisation comprend une transmission, par un circuit de transmission TRN_C1 dudit terminal TERM1, au premier ordinateur serveur SRV1, des données propres à 20 un utilisateur authentifié par le circuit d'authentification AUTH_C1 dudit terminal TERM1, obtenues par le circuit d'obtention OBT_C1 dudit terminal TERM1. Ce procédé a vocation à être mis en oeuvre notamment par un système selon le troisième mode de réalisation. Les caractéristiques relative à ce procédé sont applicables au système correspondant et réciproquement.

25 Selon un huitième mode de réalisation un procédé de gestion d'applications de communication selon l'un des cinquième, sixième et septième modes de réalisation comprend une installation de chaque application APP1 de la pluralité d'applications de communication sur un 30 terminal TERM1 de l'utilisateur U1 dont elle contient les données propres.

3025625 15 Le procédé comprend une transmission d'un même flux d'informations depuis ledit terminal TERM1 à tous les terminaux TERMfo TERMf(1;2), TERMfo,gm, auxquels, à l'instant de cette transmission, le circuit de partage d'applications SHR_C du deuxième ordinateur serveur SRV2 a déjà transmis 5 ladite application APP1. Ce procédé a vocation à être mis en oeuvre notamment par un système selon le quatrième mode de réalisation. Les caractéristiques relative à ce procédé sont applicables au système correspondant et réciproquement.

10 Selon un neuvième mode de réalisation, un programme d'ordinateur comprend une suite d'instructions qui, lorsqu'elles sont exécutées par un ou plusieurs processeurs, conduisent le (ou les) processeur(s) à mettre en oeuvre un procédé selon l'une des revendications 5 à 8. Le ou les processeurs sont par exemple le processeur du serveur SRV1/SRV2 (s'il s'agit d'un serveur 15 unique monoprocesseur) ou les processeurs de ce ou ces serveur(s) dans le cas contraire, ainsi que le cas échéant le ou les processeur(s) du terminal considéré, pour chaque terminal considéré. Le programme d'ordinateur peut être développé par exemple en langage C, C++, Java, .NET, ou dans tout autre langage approprié. Il peut également être développé en plusieurs 20 langages (par exemple un premier langage ou une première série de langages pour les parties du programme ayant vocation à être exécutées sur des serveurs, et un deuxième langage ou une deuxième série de langages pour les parties du programme ayant vocation à être exécutées sur des terminaux).

25 Selon un dixième mode de réalisation, un support de stockage non transitoire lisible par ordinateur stocke un programme d'ordinateur selon le neuvième mode de réalisation. Ce support de stockage peut être constitué de plusieurs sous supports, notamment lorsque le programme considéré à vocation à être installé sur des entités physiques distinctes (terminaux et 30 serveurs par exemple). Ce support est par exemple un disque dur ou encore une mémoire non volatile de type EEPROM, Flash, ROM ou autre.

3025625 16 D'autres modes de réalisation sont décrits ci-dessous, et sont évidemment combinables avec les modes de réalisation précités.

5 Un mode de réalisation consiste à mettre en oeuvre le processus suivant. Dans un premier temps, un utilisateur télécharge une application de création d'applications sur son smartphone, puis il l'exécute. L'application lui demande de se connecter à un réseau social. Dans un deuxième temps, une plateforme de création d'applications 10 comprenant un serveur (auquel l'application de création d'applications s'est connectée) enregistre le profil de l'utilisateur, récupéré depuis le réseau social et/ou depuis des données stockées sur le smartphone (ces données stockées pouvant comprendre par exemple un numéro de téléphone) et génère une application unique sur cette base (en partant d'une application de 15 communication non personnalisée). Cette application peut être par exemple une application pour système iOS, Android ou encore Windows Phone. Dans un troisième temps l'application de création d'applications donne à l'utilisateur l'opportunité de personnaliser davantage son application (en téléchargeant des photos, en agrégeant des services tiers au sein de son 20 application, en adaptant le design de l'interface graphique, etc.). Si l'utilisateur saisit cette opportunité, l'application de communication est générée à nouveau en fonction des éléments de personnalisation supplémentaires. Dans une variante, on attend le troisième temps avant de générer l'application de communication afin de ne pas la générer inutilement lors du deuxième temps.

25 Dans un quatrième temps, l'utilisateur a l'opportunité de restreindre la diffusion de l'application qu'il a générée. Ainsi, il peut définir une liste blanche (liste des personnes autorisées à télécharger l'application de communication personnalisée). Il peut définir une liste noire (liste des personnes non autorisées à télécharger l'application de communication personnalisée). Il peut 30 opter pour un mode dit public, dans lequel tout le monde peut télécharger l'application de communication personnalisée. Le fait de contrôler la diffusion 3025625 17 de l'application (par exemple selon l'une des trois options précitées) est une caractéristique pouvant être combinée notamment à l'un quelconque des premier au dixième modes de réalisation.

5 Une fois installée par les utilisateurs éventuellement autorisés (ci-après dénommés destinataires), l'application personnalisée devient un outil de communication centré sur l'utilisateur à l'origine de l'application (ci-après dénommé émetteur). Selon un mode de réalisation possible, l'application personnalisée affiche 10 tous les messages diffusés par l'émetteur sur les services tiers associés à l'application personnalisée, via un flux de données unifié. Selon un mise en oeuvre possible, l'application personnalisée est agencée pour permettre au destinataire d'interagir avec l'émetteur via chacun des messages reçus via le flux unifié de la même manière qu'il le ferait 15 nativement sur chacun des services tiers (sans le flux unifié par l'application personnalisée). Ces interactions peuvent comprendre les actions suivantes: répondre, commenter, "liker", "retweeter", "+1", etc.). Selon une mise en oeuvre possible, l'application personnalisée intègre son propre service de messagerie, permettant au destinataire et à l'émetteur 20 de dialoguer par exemple en s'échangeant des messages et/ou des fichiers multimédia (photos, vidéos, sons, dessins...). Ces messages, privés au sens où leur diffusion se limite à deux personnes (émetteur et récepteur), apparaissent sur les terminaux des utilisateurs concernés, via leur 'application personnalisée respective. Selon une mise en oeuvre possible, l'émetteur et le 25 récepteur se limitent à chacun à une personne. Selon une autre mise en oeuvre possible, l'émetteur et/ou le récepteur désignent une liste de diffusion (par exemple un club de football, etc.) dont tout les membres ont accès aux messages. Selon une mise en oeuvre possible, chaque message génère une 30 notification utilisant la fonctionnalité dite "push notification". De même, selon une mise en oeuvre possible, l'application personnalisée 3025625 18 génère une notification aux destinataires à chaque fois que l'émetteur diffuse un message sur les services tiers associés. La plateforme de création d'applications permet ainsi une création 5 d'applications personnalisées mobiles de façon très rapide (si l'utilisateur n'use pas de l'option proposée au troisième temps ci-dessus, la création de l'application personnalisée prend typiquement moins d'une minute). Elle ne requiert pas que l'émetteur dispose d'un compte développeur auprès des propriétaires de plateformes mobiles (telles qu'Android, iOS). Elle ne nécessite 10 pas, de la part de l'émetteur, d'équipement autre qu'un smartphone. Selon une mise en oeuvre, le processus, qui peut être conçu pour supporter d'importants volumes, peut varier selon les plateformes.

15 A titre d'exemple, une mise en oeuvre possible sous Android est la suivante. La plateforme de création d'applications maintient à tout instant une application mobile de "référence" développée en utilisant les outils (SDK) mis à disposition par Android/Google. Toutes les applications personnalisées sont 20 basées sur cette application de référence. Afin de créer une application personnalisée, le processus suivant est exécuté de manière automatique en arrière plan : - Désassemblage de l'application de référence, par exemple en utilisant l'outil apktool de Google (le résultat étant mis en cache pour meilleure vitesse 25 d'exécution - il est en effet inutile de désassembler à chaque fois le même code) - Mise à jour de l'icône de l'application de référence, de son nom et de sa configuration en fonction des paramètres spécifiques de l'utilisateur (récupérés par exemple sur un réseau social) 30 - Réassemblage de l'application, par exemple en utilisant l'outil apktool 3025625 19 de Google - Signature digitale de l'application avec un certificat officiel de la plateforme de création d'applications - Optimisation de l'application, par exemple avec l'outil zipalign.

5 L'application personnalisée peut alors instantanément être mise à disposition au téléchargement sur une plateforme de distribution d'applications propriétaire. Elle peut également être soumise aux plateformes de distribution d'applications publiques, comme par exemple Google Play.

10 A titre d'exemple, une mise en oeuvre possible sous iOS est la suivante. Apple impose que toute application mobile native soit soumise pour approbation sur l'App store, avant qu'elle ne soit, le cas échéant, autorisée et disponible au téléchargement par les utilisateurs finaux (destinataires). Ceci introduit un délai gênant, ainsi qu'un risque de non approbation.

15 Pour ces raisons les aménagements suivants sont possibles. L'application personnalisée sur iOS est publiée sous format "webapp", offrant les mêmes fonctionnalités que les applications natives Android (hormis quelques fonctions telles que les "push notifications"). Les destinataires installent l'application en enregistrant un lien avec la commande "Add to Home 20 Screen". Compte tenu de la personnalisation de l'icône et du nom de l'application, celle-ci apparaît de la même façon qu'une application native (un utilisateur non spécialiste n'est pas surpris et ne voit pas de différence). Dans un premier temps, une "webapp" de référence est créée.

25 Afin de créer une application personnalisée, le processus suivant est alors exécuté de manière automatique : - Génération d'une page web montrant la "webapp" personnalisée - Personnalisation du "favicon" et du titre 3025625 20 - Si le paramètre window.navigator.standalone a la valeur "faux", indiquant que l'utilisateur n'a pas lancé la "webapp" depuis son écran d'accueil ("home screen"), le processus propose à l'utilisateur l'option "Add to Home Screen".

5 En parallèle, une application native peut être construite en utilisant les outils de création automatique décrits précédemment, et soumise en parallèle à l'App Store iTunes. Une fois que l'application personnalisée est approuvée, la plateforme de création d'applications propose au destinataire de migrer vers 10 l'application native. Selon une mise en oeuvre possible, la gestion des droits d'accès à l'application personnalisée est opérée de la manière suivante (précisant le quatrième temps décrit ci-dessus).

15 L'identité du destinataire (invité par l'émetteur) est vérifiée par l'application personnalisée une fois cette application téléchargée, installée et lancée. De cette façon: - l'application peut être diffusée de manière publique (par exemple disponible au téléchargement sur Google Play ou l'App Store) et 20 - le partage éventuel des liens de téléchargement par un destinataire autorisé à un utilisateur non autorisé ne soulève pas de risque de sécurité. Le processus est le suivant : - L'application de création d'applications personnalisées affiche la liste des contacts du carnet d'adresse du téléphone de l'utilisateur (émetteur). 25 - L'émetteur invite certains de ses contacts (destinataires) en les sélectionnant. Ceci déclenche l'envoi automatique d'un SMS au(x) destinataire(s), SMS comprenant une invitation (pouvant comprendre un lien de téléchargement) à télécharger l'application personnalisée depuis le une plateforme de distribution d'applications. 30 - La sélection du destinataire déclenche également un 3025625 21 enregistrement automatique du numéro de téléphone du destinataire dans une liste blanche (personnes autorisées). - Lorsque le destinataire lance l'application personnalisée pour la première fois, ce destinataire doit fournir son propre numéro de téléphone. Le 5 système valide que ce dernier figure bien dans la liste blanche. Des étapes supplémentaires peuvent être prévues afin de vérifier que le numéro appartient effectivement au destinataire. - L'émetteur de l'application personnelle peut à tout instant révoquer l'accès à un destinataire spécifique, à partir de l'application de création 10 d'applications personnalisées. Lors de son lancement suivant, l'application personnalisée se connecte (comme à chaque lancement) à la plateforme de création d'applications personnalisées, qui (informée par l'application de création d'applications personnalisées), la désactive.

15 Selon une mise en oeuvre possible, une application personnalisée peut être configurée de la manière suivante. Une nouvelle application personnelle est (ré)générée comme indiqué précédemment, et rediffusée aux destinataires, notamment si l'émetteur met à jour des paramètres de son application tels que l'icône ou le nom de 20 l'application, ou encore si l'application de référence est mise à jour. En revanche si la nouvelle configuration de l'application personnalisée ne tient par exemple qu'à l'ajout d'un nouveau flux d'un service tiers, ou à une personnalisation du design de l'application, l'application existante pourra simplement lire la configuration en communiquant avec la plateforme (par 25 exemple via un lien sécurisé et authentifié de type SSL) au lancement suivant. Le suivi ("monitoring") et la collecte de statistiques concernant l'usage d'une application sont généralement réservés à l'éditeur et/ou au développeur de l'application. Toutefois, selon une mise en oeuvre possible, certains 30 paramètres sont rendus accessibles aux émetteurs des applications 3025625 22 personnalisées, via une interface dédiée au sein de leur application de création d'applications personnalisées. Des données sont collectées par les serveurs de la plateforme de création d'applications personnalisées depuis les applications personnalisées.

5 Lorsque les applications personnalisées ne sont pas connectées, les statistiques sont mises en cache et envoyées lors de la connexion web suivante. La plateforme de création d'applications personnalisées transforme alors ces statistiques brutes en indicateurs synthétiques simples d'usage, tels que : 10 - Nombre de téléchargements de l'application personnalisée - Nombre de destinataires actifs (défini par exemple par un minimum de quatre utilisations de l'application durant le mois précédent, d'autre seuils étant possibles) - Score d'utilisation de l'application personnalisée par destinataire, 15 prenant en compte le nombre, la durée des sessions, et le nombre de messages échangés. Ces indicateurs sont affichés sur l'application de création d'applications personnalisées de l' émetteur.

20 Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d'exemples ; elle s'étend à d'autres variantes. Par exemple, les quatrième et huitième modes de réalisation comprennent deux caractéristiques que sont d'une part l'installation d'une application sur le terminal de l'utilisateur dont elle contient les données 25 propres, et d'autre part la transmission d'un flux aux autres terminaux. Ces deux caractéristiques coopèrent dans ce contexte, mais peuvent également exister indépendamment l'une de l'autre. Par exemple l'utilisateur pourrait déclencher l'envoi d'un flux d'information vers les terminaux considérés en se connectant à un site web approprié (sans avoir installé l'application lui-même).

30 Réciproquement l'installation de l'application sur le terminal de l'utilisateur dont elle contient les données propres peut être opérée sans pour autant que la 3025625 23 transmission de flux aux autres terminaux ne soit envisagée. D'autres applications de communications sont en effet possible.

Claims (10)

1. REVENDICATIONS1. Système de gestion d'applications de communication, comprenant un premier ordinateur serveur (SRV1), un deuxième ordinateur serveur (SRV2) et une pluralité de terminaux (TERM1, TERM2, TERMN), dans lequel: - le premier ordinateur serveur (SRV1) comprend un circuit de génération d'applications (GEN_C) agencé pour générer une pluralité d'applications de communication (APP1, APP2, APPN), et, pour chaque application de communication de la pluralité d'applications de communication à générer, agencé pour modifier une copie respective d'une application de communication de référence, ladite modification comprenant l'inclusion, dans la copie respective de l'application de communication de référence, de données propres à un utilisateur respectif (U1, U2, ..., UN) d'un terminal respectif de la pluralité de terminaux (TERM1, TERM2, TERMN), - le deuxième ordinateur serveur (SRV2) comprend un circuit de partage d'applications (SHR_C) agencé pour transmettre chaque application de communication d'une pluralité d'applications de communication (APP1, APP2, APPN) générées par le circuit de génération d'applications (GEN_C) du premier ordinateur serveur (SRV1) à un ensemble respectif de terminaux ({TERMf(1l), TERMf(1 ;2), ... TERMfo,g0Q, {TERMf(21), TE RNAf(22), TERMf(2,g(2))}, {TERMf(N1), TE RNAf(N;2), ... TE RNAf(N,g(N))/)-
2. 2. Système de gestion d'applications de communication selon la revendication 1, dans lequel chaque terminal (TERN/1i) de la pluralité de terminaux (TERM1, TERM2, TERMN) comprend: - un circuit d'authentification (AUTH_Ci) agencé pour authentifier un utilisateur (14 dudit terminal (TERN/1i) auprès d'un troisième ordinateur serveur (SRV3), - un circuit d'obtention (OBT_Ci) agencé pour requérir de la part du troisième ordinateur serveur (SRV3) des données propres à un utilisateur (Ui) authentifié par le circuit d'authentification (AUTH_Ci) dudit terminal (TERMi). 3025625 25
3. 3. Système de gestion d'applications de communication selon la revendication 2, dans lequel chaque terminal (TERMi) de la pluralité de terminaux (TERM1, TERM2, TERMN) comprend un circuit de transmission (TRN_Ci) agencé pour transmettre, au premier ordinateur serveur (SRV1), des 5 données propres à un utilisateur (14 authentifié par le circuit d'authentification (AUTH_Ci) dudit terminal (TERM;), obtenues par le circuit d'obtention (OBT_Ci) dudit terminal (TERMi).
4. 4. Système de gestion d'applications de communication selon l'une des 10 revendications précédentes, dans lequel chaque application (APP1) de la pluralité d'applications de communication (APP1, APP2, APPN) est prévue pour être installée sur un terminal (TERM1) de l'utilisateur (U1) dont elle contient les données propres, et pour transmettre un même flux d'informations depuis ledit terminal (TERM1) à tous les terminaux (TERMf(1l), TERMf(1;2), 15 TERMfo;g(1))) auxquels, à l'instant de la transmission de ce flux d'information, le circuit de partage d'applications (SHR_C) du deuxième ordinateur serveur (SRV2) a déjà transmis ladite application (APP1).
5. 5. Procédé de gestion d'applications de communication, comprenant: 20 /d/ une génération, par un circuit de génération d'applications (GEN_C) d'un ordinateur serveur (SRV1), d'une pluralité d'applications de communication (APP1, APP2, APPN), la génération comprenant, pour chaque application de communication de la pluralité d'applications de communication à générer, une modification d'une copie respective d'une 25 application de communication de référence, ladite modification comprenant l'inclusion, dans la copie respective de l'application de communication de référence, de données propres à un utilisateur respectif (Ui, U2, ..., UN) d'un terminal respectif d'une pluralité de terminaux (TERM1, TERM2, TERMN), /f/ une transmission, par un circuit de partage d'applications (SHR_C) d'un 30 ordinateur serveur (SRV2), de chaque application de communication de la pluralité d'applications de communication (APP1, APP2, APPN), à un ensemble respectif de terminaux ({TERMf(1l), TERMf(1;2), --- TERMf(1,g(1))1, 3025625 26 {TERMf(21), TE RNAf(2;2), ... TE RNAf(2,g(2))}, {TERMf(N1), TERMf(N;2), - TERMf(N,g(N))}).
6. 6. Procédé de gestion d'applications de communication selon la 5 revendication 5, comprenant: /a/ une authentification, par un circuit d'authentification (AUTH_Ci) d'un terminal (TERMi) de la pluralité de terminaux (TERM1, TERM2, TERMN), d'un utilisateur (14 dudit terminal (TERN/1i), auprès d'un troisième ordinateur serveur (SRV3), 10 /b/ une requête, par un circuit d'obtention (OBT_Ci) dudit terminal (TERMi) au troisième ordinateur serveur (SRV3), visant à obtenir de ce troisième ordinateur serveur (SRV3) des données propres à l'utilisateur (14 authentifié par le circuit d'authentification (AUTH_Ci) dudit terminal (TERMi). 15
7. 7. Procédé de gestion d'applications de communication selon la revendication 6, comprenant: /c/ une transmission, par un circuit de transmission (TRN_Ci) dudit terminal (TERM;), au premier ordinateur serveur (SRV1), des données propres à un utilisateur authentifié par le circuit d'authentification (AUTH_Ci) dudit terminal 20 (TERN/1i), obtenues par le circuit d'obtention (OBT_Ci) dudit terminal (TERMi).
8. 8. Procédé de gestion d'applications de communication selon l'une des revendications 5 à 7, comprenant: /e/ une installation de chaque application (APP1) de la pluralité 25 d'applications de communication (APP1, APP2, APPN) sur un terminal (TERM1) de l'utilisateur (U1) dont elle contient les données propres, et /g/ une transmission d'un même flux d'informations depuis ledit terminal (TERM1) à tous les terminaux (TERMf(1l), TERMf(1;2), TERMf(1;g(1))) auxquels, à l'instant de cette transmission, le circuit de partage d'applications 30 (SHR_C) du deuxième ordinateur serveur (SRV2) a déjà transmis ladite application (APP1). 3025625 27
9. 9. Programme d'ordinateur comprenant une suite d'instructions qui, lorsqu'elles sont exécutées par un processeur, conduisent le processeur à mettre en oeuvre un procédé selon l'une des revendications 5 à 8. 5
10. 10. Support de stockage non transitoire lisible par ordinateur, ledit support stockant un programme d'ordinateur selon la revendication 9.