Brevet FR3011357A1 — publié le 20150403

La présente invention concerne un moteur contextuel de recommandation pour application mobile. C'est un système contextuel perfectionné auto-apprenant de sélection et de présentation de données sur terminal de communication mobile. L'invention s'adapte notamment à une application professionnelle qui propose des fonctionnalités pour téléphone mobile qui, à tout moment et pour chaque utilisateur, peut filtrer, trier, sélectionner et proposer des informations pertinentes issues de bases de données lourdes et situations contextuelles. L'art antérieur propose des systèmes experts contextuels se basant sur une gestion fine d'éléments connus en intégrants d'éventuelles mesures contextuelles (liées à la géolocalisation par exemple quand on parle de systèmes mobiles). L'art antérieur propose par ailleurs des systèmes de recommandation auto-apprenants dont certains tiennent compte des mesures qui vont au-delà de la simple précision du système. Une nouvelle mesure dite de sérendipité (hasard heureux) peut être introduite ; c'est une mesure qui indique comment le système de recommandation peut trouver des objets inattendus et utiles pour les utilisateurs afin de renforcer l'apprentissage du système. Cela peut se concrétiser par des propositions faites à l'utilisateur. Un problème important que se propose de résoudre l'invention est qu'un moteur auto-apprenant, basé sur des propositions hasardeuses pour renforcer son apprentissage, doit émettre des propositions non pertinentes et que cela peut être mal toléré par l'utilisateur d'un terminal de communication mobile dans certaines situations. Lors d'une réunion professionnelle par exemple, l'utilisateur ne souhaite recevoir que des informations liées à son besoin immédiat. Il est important de noter que si ledit utilisateur juge l'information proposée comme perturbante à un moment sensible, alors le moteur est en échec car il ne pourra plus « apprendre » de ses propositions car les « réponses » de l'utilisateur seront contre-productives. Comme réponse non productive on peut lister : la réponse de l'utilisateur est fausse (réponse rapide énervée, sans lire), l'utilisateur ne répond pas à la sollicitation (il ferme la fenêtre de dialogue plutôt que de répondre), l'utilisateur désinstalle ou désactive l'application proposant des sollicitations trop souvent erronées... A cause de ce genre de problème il n'existe pas d'hybridation de moteurs contextuels (dédié mobilité notamment) et de sérendipité. L'invention va rendre cette hybridation possible. Selon l'art antérieur il n'existe pas des moteurs de données qui recommandent des informations liées à la sérendipité tout en intégrant le risque de déranger l'utilisateur. Selon l'invention, la recommandation d'informations destinées à la sérendipité est effectuée dans les situations considérées comme non risquées, par exemple "à la maison" ou "en vacances" et le système selon l'invention se permet alors d'explorer des recommandations qui ne sont pas forcément liées aux intérêts de l'utilisateur. Par contre, lors d'une réunion professionnelle par exemple, le système selon l'invention recommande exclusivement des informations qu'il considère comme pertinentes. Selon un art antérieur, il n'existe pas de moteurs de données qui recommandent des informations en considérant la péremption des centres d'intérêts de l'utilisateur. Selon l'invention, le système intégrera la péremption des centres d'intérêt, par exemple en scrutant un nombre de consultations effectuées dans un centre d'intérêt. Selon l'art antérieur, la forme de la réponse (vitesse de réponse par exemple) n'est pas intégrée à l'apprentissage par le système, qui ne considère que le contenu de la réponse. Selon l'invention la forme de la réponse (par exemple sa rapidité excessive) ou sa variation statistique (par exemple le fait de refuser la proposition en fermant une fenêtre de dialogue plutôt qu'en sélectionnant une réponse alors que précédemment c'était le cas) sera traitée et intégrée à l'apprentissage du moteur de sérendipité. L'apprentissage se fera donc sur deux axes des retours utilisateurs : la réponse elle-même (intégrée pour renforcer l'apprentissage) et la forme de la réponse (intégrée pour modifier un moteur de gestion de risque par exemple) captée par exemple par le type d'interaction entre l'utilisateur et le terminal mobile. On peut donc parler de l'invention comme étant un moteur hybride auto- apprenant évolutif intelligent. Les dessins annexés illustrent l'invention. En Fig. 1 : Représentation symbolique de l'invention avec : - Le moteur (1) selon l'invention comprenant plusieurs sous-moteurs (3, 4, 5, 6 et 10). - L'utilisateur (2) - Le moteur de sérendipité (3), aussi appelé par sa fonction : gestion de sérendipité. - Le moteur de personnalisation (4), aussi appelé par sa fonction : gestion de personnalisation. - Le moteur de gestion de péremption des centres d'intérêt (5) - Le moteur contextuel (6), aussi appelée par sa fonction : gestion contextuelle. - Les informations construites (7) par ou autour de l'utilisateur (2) contenant tous types de données (c) tels que des fichiers clients, l'historique de l'usage ou des applications... - Les paramètres et composantes (b) des informations liées à la situation (8) tels que la géolocalisation, l'activité (réunion...) et le contexte (heure, jour de travail, repos...) - L'interaction (9) de l'utilisateur (2) avec le terminal (a) et le reste du système. - Le moteur de gestion des risques (10), aussi appelé par sa fonction : gestion des risques. La Fig. 1 contient aussi des représentations de procédé entre les éléments décrits avec : 1. L'échange d'information bidirectionnelle (A) entre l'utilisateur (2) et le moteur de sérendipité (3) qui s'opère notamment par le bais du terminal mobile (a). 2. La remonté d'information (B) du moteur de personnalisation (4) vers le moteur de sérendipité (3). 3. L'échange d'information bidirectionnelle (C) entre le moteur de personnalisation (4) et le moteur de gestion de péremption des centres d'intérêt (5). 4. La remontée d'information (D) du moteur contextuel (6) vers le moteur de personnalisation (4). 5. La remontée d'information (E) des informations construites (7) par ou autour de l'utilisateur (et son usage) vers le moteur contextuel (6). 6. La mesure (F) d'informations liées à la situation (8) mêlant des paramètres (b) tels que géolocalisation, activité et contexte pour alimenter le moteur contextuel (6). 7. La mesure (G) d'informations liées à la situation (8) mêlant des paramètres (b) tels que géolocalisation, activité et contexte pour alimenter le moteur de gestion de risque (10). 8. La mesure (H) d'informations liées à l'interaction (9) entre utilisateur (2) et son terminal (a) pour alimenter la gestion des risques (10). 9. La remontée d'information (I) entre le moteur de gestion des risques (10) et le moteur de sérendipité (3). Il faut comprendre que le terme « mesure » peut être associé à l'évaluation et au calcul par exemple. Il faut comprendre que le terme « remontée d'information » peut être associé à la scrutation, l'accès, l'évaluation, au tri et à la sélection, au transfert d'informations.... Dans l'architecture décrite de l'invention, identifions les principaux éléments du système : - Terminal (a) : permet l'interaction entre le système et le contexte. - Données transmises et/ou stockées : sont hétérogènes et peuvent être une base de données ou un logiciel. - Moteur contextuel (6) : récupère et traite les informations rattachées au contexte de l'utilisateur (2), par exemple sa situation (8). - Moteur de personnalisation (4) : personnalise les informations en fonction du profil de l'utilisateur (2) en interagissant avec le moteur de gestion de la péremption des centres d'intérêts (5). - Moteur de gestion de la péremption des centres d'intérêts (5) : ce moteur calcule si une information est périmée ou non en fonction du nombre de fois que l'utilisateur (2) l'a consulté. - Moteur de gestion du risque (10) : calcule le risque de déranger l'utilisateur (2) en fonction du contexte et transmet cette valeur au moteur de sérendipité (3). - Moteur de sérendipité (3) : Définit le taux de sérendipité en fonction du risque de déranger l'utilisateur et opère des recommandations en fonction de ce facteur. Exemple de fonctionnement de l'invention : Le moteur (1) selon l'invention est constitué de sous-moteurs (3, 4, 5, 6 et 10) interconnectés (B, C, D et I) pour permettre de soumettre à l'utilisateur (2) des recommandations pertinentes au meilleur moment : un moteur contextuel (6) est notamment alimenté (E et F) par des informations construites (7) par et autour de l'utilisateur telles qu'un répertoire (c) et par une situation (8) contenant divers types d'informations (b) telles que la géolocalisation, l'activité et le moment. Une gestion, par exemple de type 'système expert', de ces informations par le moteur contextuel (6) permet de transmettre des informations pertinentes (D) au moteur de personnalisation (4). Un exemple d'information pertinente remontée (D) peut être de nature à proposer l'organisation d'un rendez-vous clientèle à l'utilisateur (2) si les informations construites (7) montrent une disponibilité (agenda (c) vide) et une opportunité (proximité clientèle) en corrélation avec la situation (8) (heure et géolocalisation). Un moteur de gestion de péremption des intérêts (5) pilote l'actualité desdits centres d'intérêts, notamment en coopérant (C) avec le moteur de personnalisation (4). Ce moteur calcule par exemple si une information est périmée, ou non, en fonction du nombre de fois que l'utilisateur (2) l'a consultée. Un moteur de personnalisation (4) coopérant (D) avec un moteur contextuel (6) va personnaliser les informations transmises (B) à un moteur de sérendipité (3) en fonction du profil de l'utilisateur (2) par la coopération avec le moteur de gestion de la péremption des centres d'intérêts. Dans l'exemple présenté plus haut, si le moteur contextuel (6) proposait un rendez-vous clientèle, ce possible rendez-vous est maintenant confronté à la gestion de péremption des centres d'intérêts (5) et sera, ou non, poussé (B) vers le moteur de sérendipité (3). Un moteur de gestion des risques (10) évalue (G) la situation (8) de l'utilisateur (2) et considère (H) l'interaction (9) avec le terminal (a) pour calculer le risque de déranger l'utilisateur en fonction du contexte. Ledit moteur (10) transmet (I) une préconisation de risque au moteur de sérendipité (3). Premier exemple de fonctionnement : le moteur de gestion des risques (10) mesure (G) une situation (8) et décide qu'elle est propice à une préconisation hasardeuse (visant à nourrir l'apprentissage par sérendipité). L'information sera alors poussée (I) vers le moteur de sérendipité (3). Second exemple de fonctionnement : l'utilisateur (2) dans un contexte (8) répond brusquement (H) à la sollicitation. Le moteur (10) pourra traiter ces informations de façon à améliorer la gestion des risques, par exemple en augmentant le taux de risque pour cette situation (b). Un moteur de sérendipité (3) qui peut transmettre (A) directement à l'utilisateur (2) les recommandations ou informations issues (D) du moteur de personnalisation (4), peut aussi décider de proposer des recommandations plus aléatoires au profit de l'apprentissage par sérendipité. Il se base notamment sur le taux transmis (I) par le moteur de gestions des risques (10). On voit bien que de nombreuses variantes éventuellement susceptibles de se combiner peuvent ici être apportées sans jamais sortir du cadre de l'invention tel 10 qu'elle est définie. Ces schémas de principes ne présument en rien de la mise en oeuvre qui peut varier. Selon une certaine mise en oeuvre le moteur de recommandation (1) pour application mobile comprenant une pluralité de sous-moteurs (3, 4, 5, 6 et 10) coopérant entre eux (B, C, D, I) et avec un contexte (A, E, F, G, H) hybride a) une 15 gestion contextuelle (6) coopérant avec une situation (8) de l'utilisateur (2) telle qu'une réunion (b) et des informations (7) construites par ou autour de l'utilisateur (2) telles qu'un agenda (c), avec b) une gestion de sérendipité (3). Le Moteur de recommandation (1) pour application mobile intègre une gestion des risques (10) coopérant par exemple avec une situation (8) pour transmettre des informations (I) à 20 un moteur de sérendipité (3) sur l'opportunité de faire des propositions hasardeuses à l'utilisateur (2). Le moteur de recommandation (1) pour application mobile intègre une gestion de péremption des centres d'intérêts (5) coopérant (C) avec un autre sous-moteur (4) pour l'informer de l'opportunité de considérer une information, par exemple en évaluant le nombre de fois que ladite information a été consultée dernièrement. Le 25 moteur de recommandation (1) pour application mobile considère (H) la forme de l'interaction (9) avec le terminal (a), en plus de la valeur de la réponse, par exemple pour différencier une réponse pertinente dont on considérera la valeur, d'une réponse non pertinente qui affectera un sous-moteur (10) de façon à apprendre de cette réponse. Le moteur de recommandation (1) pour application mobile évalue l'interaction (9) entre le terminal (a) et le reste du système en combinant divers paramètres tels que des détections de mouvement, des mesures de vitesse de réponse, des évaluations de pression sur une surface tactile. L'invention est particulièrement destinée à permettre le renforcement de l'apprentissage par sérendipité dans un moteur contextuel auto-apprenant de sélection et de présentation de données sur terminal de communication mobile. REVENDICATIONS1) Moteur de recommandation (1) pour application mobile comprenant une pluralité de sous-moteurs (3, 4, 5, 6 et 10) coopérant entre eux (B, C, D, I) et avec un contexte (A, E, F, G, H) caractérisé en ce qu'il hybride a) une gestion contextuelle (6) coopérant avec une situation (8) de l'utilisateur (2) telle qu'une réunion (b) et des informations (7) construites par ou autour de l'utilisateur (2) telles qu'un agenda (c), avec b) une gestion de sérendipité (3) afin de permettre audit moteur d'améliorer ses recommandations par apprentissage. 10 2) Moteur de recommandation (1) pour application mobile selon la revendication 1) caractérisé en qu'il intègre une gestion des risques (10) coopérant par exemple avec une situation (8) pour transmettre des informations (I) à un moteur de sérendipité (3) sur l'opportunité de faire des propositions hasardeuses à l'utilisateur (2). 15 3) Moteur de recommandation (1) pour application mobile selon la revendication 1) caractérisé en qu'il intègre une gestion de péremption des centres d'intérêts (5) coopérant (C) avec un autre sous-moteur (4) pour l'informer de l'opportunité de considérer une information, par exemple en évaluant le nombre de fois que ladite information a été consultée dernièrement. 20 4) Moteur de recommandation (1) pour application mobile selon la revendication 1) caractérisé en qu'il considère (H) la forme de l'interaction (9) avec le terminal (a), en plus de la valeur de la réponse, par exemple pour considérer différemment une réponse jugée pertinente (par exemple si le temps de réponse est supérieur ou égal à une valeur étalon, ce qui tend à montrer que la 25 réponse peut être considérée) dont on considèrera la valeur, d'une réponse jugée non pertinente (par exemple si le temps de réponse est trop rapide par rapport à une valeur étalon, ce qui tend à montrer que la réponse n'a pas étéréfléchie) qui affectera un sous-moteur (10) de façon à apprendre de cette réponse (par exemple que ce n'était pas la bonne situation (8) pour interrompre l'utilisateur (2)). 5) Moteur de recommandation (1) pour application mobile selon les revendications 1) à 4) caractérisé en que l'évaluation de l'interaction (9) entre le terminal (a) et le reste du système peut combiner divers paramètres tels que des détections de mouvement, des mesures de vitesse de réponse, des évaluations de pression sur une surface tactile.