FR3069076A1 - Systeme et procede pour delivrer dynamiquement du contenu - Google Patents

Systeme et procede pour delivrer dynamiquement du contenu Download PDF

Info

Publication number
FR3069076A1
FR3069076A1 FR1756718A FR1756718A FR3069076A1 FR 3069076 A1 FR3069076 A1 FR 3069076A1 FR 1756718 A FR1756718 A FR 1756718A FR 1756718 A FR1756718 A FR 1756718A FR 3069076 A1 FR3069076 A1 FR 3069076A1
Authority
FR
France
Prior art keywords
application
request
data
user
content
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1756718A
Other languages
English (en)
Other versions
FR3069076B1 (fr
Inventor
Eduardo Rafael Lopez Ruiz
Nicolas Guillon
Jeremie Bonfil-Praire
Loic Driencourt
Melinda Monteillet
Davide Romito
Qinglin Ye
Federick Casal
Fabrice Mantoan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Amadeus SAS
Original Assignee
Amadeus SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to FR1756718A priority Critical patent/FR3069076B1/fr
Application filed by Amadeus SAS filed Critical Amadeus SAS
Priority to US16/629,465 priority patent/US11068321B2/en
Priority to PCT/EP2018/068374 priority patent/WO2019011805A1/fr
Priority to ES18734844T priority patent/ES2926005T3/es
Priority to EP22177327.8A priority patent/EP4071637A1/fr
Priority to AU2018299827A priority patent/AU2018299827B2/en
Priority to CN201880053650.9A priority patent/CN111034157B/zh
Priority to EP18734844.6A priority patent/EP3652918B1/fr
Publication of FR3069076A1 publication Critical patent/FR3069076A1/fr
Application granted granted Critical
Publication of FR3069076B1 publication Critical patent/FR3069076B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2457—Query processing with adaptation to user needs
    • G06F16/24578—Query processing with adaptation to user needs using ranking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/109—Time management, e.g. calendars, reminders, meetings or time accounting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0641—Shopping interfaces
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/14—Travel agencies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/567—Integrating service provisioning from a plurality of service providers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/30—Semantic analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5683—Storage of data provided by user terminals, i.e. reverse caching

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Tourism & Hospitality (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Development Economics (AREA)
  • Software Systems (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Computational Linguistics (AREA)
  • Educational Administration (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Library & Information Science (AREA)
  • Health & Medical Sciences (AREA)
  • Game Theory and Decision Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Peptides Or Proteins (AREA)

Abstract

Les modes de réalisation de l'invention fournissent un système pour délivrer dynamiquement du contenu d'un système fournisseur de contenu (2) à un dispositif utilisateur (3), le système fournisseur de contenu (2) étant configuré pour délivrer du contenu en réponse à une requête ayant un ou plusieurs formats prédéfinis, le dispositif utilisateur (3) comprenant une application (4) s'exécutant sur le dispositif utilisateur (3), l'application (4) étant associée à une interface d'application, l'application étant configurée pour recevoir des données d'entrée provenant d'un utilisateur au moins via l'interface d'application, les données d'entrée comprenant un ensemble d'éléments de donnée, chaque élément de donnée ayant un type et une valeur, l'application comprenant une extension d'application exécutable. Le système comprend par ailleurs un dispositif de liaison (10), le dispositif de liaison étant configuré pour connecter dynamiquement l'application (4) au système fournisseur de contenu (2) pendant l'exécution de l'extension d'application, l'extension d'application étant configurée pour activer une connexion au dispositif de liaison (10), en réponse à la détection d'une condition d'activation, l'application (4) étant configurée pour transmettre au moins certains éléments de donnée compris dans chaque bloc de données d'entrée au dispositif de liaison (10) pendant la connexion au dispositif de liaison (10), le dispositif de liaison étant configuré pour générer une requête de contenu selon l'un des formats de requête prédéfinis en utilisant les éléments de donnée reçus de l'application (4) et pour transmettre la requête au système fournisseur de contenu (2).

Description

SYSTÈME ET PROCÉDÉ POUR DELIVRER DYNAMIQUEMENT DU CONTENU
DOMAINE TECHNIQUE
De façon générale, l'invention concerne des ordinateurs et des logiciels informatiques et, en particulier, des systèmes, des procédés et des produits-programmes d'ordinateur pour la fourniture dynamique de contenu.
CONTEXTE
De nombreux développements de platesformes modernes informatisées sont dédiés à l’optimisation de l’échange d’informations entre les systèmes ou dispositifs informatisés. Notamment, dans une architecture de client/serveur, un dispositif informatique client (dispositif utilisateur) peut requérir du contenu à partir d’un dispositif ou système informatique de serveur (système fournisseur de contenu) via un réseau de communication.
Un défi majeur pour les systèmes de fournisseur de contenu consiste à fournir aussi vite et efficacement que possible le contenu demandé (données, services, produits) aux dispositifs client. Une approche explorée pour améliorer les systèmes de fournisseurs de contenu existants est de passer d'une interface statique entre les systèmes de fournisseur de contenu et les dispositifs client, dans lesquels l’utilisateur saisit des requêtes statiquement, à une interface plus dynamique et transparente où les requêtes des utilisateurs sont anticipées ou dérivée par la capture transparente d’un contexte dérivé des actions de l’utilisateur sur le dispositif client.
Une architecture client/serveur basée sur le Web est, par exemple, connue pour capturer le contexte utilisateur en exploitant les « cookies » qui sont des données qu’un serveur Web peut stocker ou lire sur le disque dur d’un dispositif client. Cependant, les cookies transportent des informations limitées qui permettent seulement aux systèmes de fournisseurs de contenu de collecter des informations générales sur l’utilisateur, ce qui requiert encore Une interface statique entre le système fournisseur de contenu et le dispositif utilisateur. De plus, ils sont limités au contexte d’un navigateur et ne sont pas adaptés au contexte des applications.
Une interface dynamique entre le système fournisseur de contenu et le dispositif utilisateur est souhaitable pour réduire le nombre d’actions qu’un utilisateur doit réaliser sur une interface pour accéder à un contenu (tels qu’une information ou un service) et le temps passé par un utilisateur pour accéder au service ou contenu.
Les systèmes fournisseurs de contenu existants permettent la réception des requêtes clients via une interface utilisateur dédiée à travers laquelle un certain nombre de clients utilisateurs peut directement accéder et entrer statiquement une requête de service ou de contenu. Le contenu géré par le système fournisseur de contenu peut être reçu des systèmes fournisseurs de contenu communiquant avec le système fournisseur de contenu, en réponse à la saisie de requêtes par un utilisateur sur l’interface utilisateur dédiée. Cela nécessite que l’utilisateur suspende une action en cours s’il souhaite accéder au service contenu, se connecter au système fournisseur de contenu, saisir les paramètres de sa requête et les différentes options liés au service ou contenu souhaité, les paramètres devant être structurés selon le format prescrit par le système fournisseur de contenu.
Par exemple, le système fournisseur de contenu peut être un système fournisseur de voyage qui détermine les meilleures options de voyage en réponse à une requête d’utilisateur pour un voyage, l’utilisateur précisant sur une interface utilisateur une date, des lieux géographiques de départ/d’arrivée et en option les préférences de l’utilisateur (critères de coût, correspondances, etc.), si l’utilisateur souhaite voyager à des coûts optimisés. L’utilisateur doit ainsi suspendre son action en cours (par exemple, dans un contexte commercial, il doit peutêtre suspendre une tâche professionnelle en cours) pour accéder statistiquement à l’interface utilisateur dédiée du système fournisseur de voyage, saisir les paramètres de voyage, valider la requête de voyage, se connecter à son compte utilisateur, etc. Si toutes ces opérations laborieuses ont été réalisées, il peut accéder aux informations de voyage et/ou directement effectuer une réservation de voyages pour réserver un voyage et éventuellement des services auxiliaires (par ex., location de voiture ou réservation d’hôtel).
Cependant, il arrive souvent que les utilisateurs oublient ou ne trouvent pas le temps d’effectuer lesdites réservations tôt, notamment dans un contexte professionnel où ils ont tendance à donner la priorité à leurs activités professionnelles principales. Par conséquent, ils ne peuvent pas bénéficier du meilleur service au meilleur coût ou avec les meilleures options de voyage.
Plus généralement, les utilisateurs souhaitent passer aussi peu de temps que possible pour accéder au contenu ou aux services fournis par les systèmes fournisseurs de contenu. Le succès des systèmes fournisseurs de contenu modernes peut dépendre du temps requis par un utilisateur pour accéder efficacement ou à acheter un service, et plus généralement de l’optimisation de l’expérience de l’utilisateur. Par exemple, un utilisateur peut ne plus utiliser un système fournisseur de contenu en raison du temps requis pour accéder à l’interface dédiée d’un système fournisseur de contenu.
Les systèmes, procédés et produits de programmes informatiques améliorés fournissant du contenu dynamique sont par conséquent requis. Ils évitent la nécessité pour un utilisateur d’accéder activement à l’interface de l’application dédiée d’un système fournisseur de contenu tout en optimisant l’interaction entre l’utilisateur le système fournisseur de contenu.
RÉSUMÉ
Dans le but de régler ces problèmes et d’autres problèmes, l’invention fournit un système pour délivrer du contenu dynamiquement d’un système fournisseur de contenu à un dispositif utilisateur, le système fournisseur de contenu étant configuré pour délivrer du contenu en réponse à une requête ayant un ou plusieurs formats prédéfinis, le dispositif utilisateur comprenant une application qui s’exécute sur le dispositif utilisateur, l’application étant associée à une interface d’application, l’application étant configurée pour recevoir des données d’entrée provenant au moins d’un utilisateur via l’interface d’application, les données d’entrée comprenant un ensemble d’éléments de donnée, chaque élément de donnée ayant un type et une valeur, dans lequel l’application peut comprendre une extension d’application exécutable. Le système peut en outre comprendre un dispositif de liaison, le dispositif de liaison étant configuré pour connecter de manière dynamique l’application au système fournisseur de contenu pendant l’exécution de l’extension d’application, l’extension d’application étant configurée pour activer une connexion au dispositif de liaison, en réponse à la détection d’une condition d’activation, l’application étant configurée pour transmettre au moins certains éléments de donnée compris dans chaque bloc de données d’entrée vers le dispositif de liaison pendant la connexion au dispositif de liaison, le dispositif de liaison étant configuré pour générer une requête de contenu selon l’un des formats de requête prédéfinis en utilisant les éléments de donnée reçus de l’application et pour transmettre la requête au système fournisseur de contenu.
Dans un mode de réalisation, le dispositif de liaison peut comprendre :
- un analyseur configuré pour analyser un ensemble de valeurs de référence pour chaque paramètre de requête, en réponse à la réception d’un bloc de données d’entrée ;
- un mappeur configuré pour déterminer si au moins certaines valeurs de référence de l’ensemble de valeurs de référence mappent un élément de donnée dans le bloc de données d’entrée ou dans une plusieurs sources auxiliaires le mappeur étant par ailleurs configuré pour associer une notation élémentaire à chaque élément de donnée mappant une valeur de référence.
Dans un mode de réalisation, chaque valeur de référence peut être associée à une liste de valeurs auxiliaires, le mappeur étant configuré pour déterminer un mappage entre une valeur de référence et un élément de donnée dans le bloc de données d’entrée ou dans une ou plusieurs sources auxiliaires, si l’élément de donnée dans le bloc de données d’entrée ou dans une ou plusieurs sources auxiliaires mappe l’une des valeurs auxiliaires.
Le dispositif de liaison peut comprendre :
- un générateur de requête configuré pour générer une requête de contenu basée sur les notations élémentaires associées aux éléments de donnée mappant les valeurs de référence, la requête comprenant des paramètres de requête, chaque paramètre de requêtes étant associé à une ou plusieurs valeurs de référence, la valeur d’au moins un paramètre de requête étant dérivée d’une valeur de référence mappée sur un élément de donnée et associée au paramètre de requête en fonction de la notation déterminée pour la valeur de référence ;
Le dispositif de liaison étant par ailleurs configuré pour envoyer la requête au système fournisseur de contenu.
Dans un mode de réalisation, la valeur d’un paramètre de requête peut être déterminée à partir de la valeur de référence ayant la notation la plus élevée.
Le dispositif de liaison peut être configuré pour déterminer la valeur du paramètre de requête en utilisant une fonction définissant une relation entre la valeur du paramètre de requête et la valeur de référence.
Dans un mode de réalisation, le dispositif de liaison peut par ailleurs comprendre un convertisseur configuré pour convertir le format d'une valeur de référence dans le format du paramètre de requête associé à la valeur de référence.
Dans certains modes de réalisation, l’application peut être associée à une mémoire de données configurée pour stocker les éléments de donnée.
Dans certains modes de réalisation, l’application peut comprendre une mémoire de données utilisateur configurée pour stocker un identifiant utilisateur, l’extension d’application étant configurée pour transmettre, de manière transparente et sécurisée, l’identifiant utilisateur au dispositif de liaison, le dispositif de liaison étant configuré pour contrôler l'accès de l’utilisateur au système fournisseur de contenu utilisant l’identifiant utilisateur.
Le dispositif de liaison est configuré pour recevoir le contenu provenant du système fournisseur de contenu en réponse à la requête, le dispositif de liaison étant configuré pour transmettre le contenu à l’application, l’application comprenant une unité de rendu pour produire un rendu du contenu dans une zone dédiée l’interface de l’application.
Dans un mode de réalisation, l’unité de rendu peut être configurée pour ajuster de manière dynamique les dimensions de l’application en fonction du contenu transmis par le dispositif de liaison.
L’invention concerne un système pour délivrer du contenu dynamique à partir d’un système fournisseur de contenu vers un dispositif utilisateur, système fournisseur de contenu étant configuré pour délivrer du contenu en réponse à une requête ayant un ou plusieurs formats prédéfinis, le dispositif utilisateur comprenant une application s’exécutant sur le dispositif utilisateur, l’application étant associée à une interface d’application, l’application étant configurée pour recevoir une donnée d’entrée provenant au moins d’un utilisateur via l’interface d’application, les données d’entrée comprenant un ensemble d’éléments de donnée, chaque élément de donnée ayant un type et une valeur où l’application peut comprendre une extension d’application exécutable. Par ailleurs, le système peut comprendre un dispositif de liaison, le dispositif de liaison étant configuré pour connecter de manière dynamique l’application au système fournisseur de contenu pendant l’exécution de l’extension d’application, l’extension d’application étant configurée pour activer une connexion au dispositif de liaison, en réponse à la détection d’une condition d’activation, l’application étant configurée pour transmettre au moins certains éléments de donnée compris dans chaque bloc de données d’entrée vers le dispositif de liaison pendant la connexion au dispositif de liaison, le dispositif de liaison étant configuré pour générer une requête de contenu selon l’un des formats de requête prédéfinis en utilisant les éléments de donnée reçus de l’application et pour transmettre la requête au système fournisseur de contenu.
Dans un mode de réalisation, le dispositif de liaison peut comprendre :
- un analyseur configuré pour analyser un ensemble de valeurs de référence pour chaque paramètre de requête, en réponse à la réception d’un bloc de données d’entrée ;
- un mappeur configuré pour déterminer si au moins certaines valeurs de référence de l’ensemble de valeurs de référence mappent un élément de donnée dans le bloc de données d’entrée ou dans une plusieurs sources auxiliaires le mappeur étant par ailleurs configuré pour associer une notation élémentaire à chaque élément de donnée mappant une valeur de référence.
Dans un mode de réalisation, chaque valeur de référence peut être associée à une liste de valeurs auxiliaires, le mappeur étant configuré pour déterminer un mappage entre une valeur de référence et un élément de donnée dans le bloc de données d’entrée ou dans une ou plusieurs sources auxiliaires si l’élément de donnée dans le bloc de données d’entrée ou dans une ou plusieurs sources auxiliaires mappe l’une des valeurs auxiliaires.
Les dispositifs de liaison peuvent comprendre :
- un générateur de requête configuré pour générer une requête de contenu basée sur les notations élémentaires associées aux éléments de donnée mappant les valeurs de référence, la requête comprenant des paramètres de requête, chaque paramètre de requête étant associé à une ou plusieurs valeurs de référence, la valeur d’au moins un paramètre de requête étant dérivée d’une valeur de référence mappée sur un élément de donnée et associée au paramètre de requête en fonction de la notation déterminée pour la valeur de référence ;
Le dispositif de liaison étant par ailleurs configuré pour envoyer la requête au système fournisseur de contenu.
Dans un mode de réalisation, la valeur d’un paramètre de requête peut être déterminée à partir de la valeur de référence ayant la notation la plus élevée.
Le dispositif de liaison peut être configuré pour déterminer la valeur du paramètre de requête en utilisant une fonction définissant une relation entre la valeur du paramètre de requête et la valeur de référence.
Dans un mode de réalisation, le dispositif de liaison peut par ailleurs comprendre un convertisseur configuré pour convertir le format d’une valeur de référence dans le format du paramètre de requête associé à la valeur de référence.
Dans certains modes de réalisation, l’application peut être associée à une mémoire de données configurées pour stocker les éléments de donnée.
Dans certains modes de réalisation, l’application peut comprendre une mémoire de données utilisateur configurée pour stocker un identifiant utilisateur, l’extension d’application étant configurée pour transmettre, de manière transparente et sécurisée, l’identifiant utilisateur au dispositif de liaison, le dispositif de liaison étant configuré pour contrôler l’accès de l’utilisateur au système fournisseur de contenu utilisant l’identifiant utilisateur.
Le dispositif de liaison est configuré pour recevoir le contenu provenant du système fournisseur de contenu en réponse à la requête, le dispositif de liaison étant configuré pour transmettre le contenu à l’application, l'application comprenant une unité de rendu pour produire un rendu le contenu dans une zone dédiée de l’interface de l’application.
Dans un mode de réalisation, l’unité de rendu est configurée pour ajuster de manière dynamique les dimensions de l’application en fonction du contenu transmis par le dispositif de liaison.
BRÈVE DESCRIPTION DES DESSINS
Les dessins qui sont intégrés et font partie intégrante de cette spécification, illustrent des modes de réalisation de l'invention variés et, avec la description générale de l'invention cidessus et la description détaillée des modes de réalisation donnée ci-après, servent à expliquer les modes de réalisation de l'invention.
La Figure 1 est une vue schématique d’un système fournisseur de contenu dynamique, selon certains modes de réalisation.
La Figure 2 est une vue schématique d’un dispositif de liaison, selon certains modes de réalisation.
La Figure 3 montre un système fournisseur de voyage, selon un mode de réalisation exemplaire.
La Figure 4 est un organigramme illustrant le processus d’activation du dispositif de liaison, selon un mode de réalisation de l'invention.
La Figure 5 est un organigramme illustrant le processus de connexion à l’extension d’application, selon un mode de réalisation de l'invention.
La Figure 6 est un organigramme illustrant le processus de création d’une session, selon un mode de réalisation de l'invention.
La Figure 7 est un organigramme illustrant un procédé de fourniture de contenu, selon un mode de réalisation de l'invention.
La Figure 8 est un organigramme illustrant le processus mis en œuvre par le dispositif de liaison, si une condition de génération de requête n’est pas satisfaite, selon un autre mode de réalisation de l'invention.
La Figure 9 est un organigramme illustrant le traitement d’un bloc de données d’entrée, selon un mode de réalisation de l'invention.
La Figure 10 est un organigramme illustrant le processus consistant à déterminer si une condition de génération de requête est satisfaite, selon un mode de réalisation de l'invention.
La Figure 11 est une vue de l’interface d’application, selon un mode de réalisation exemplaire.
La Figure 12 est une autre vue de l’interface d’application de la Figure 11, selon un mode de réalisation exemplaire.
La Figure 13 est une vue de l’interface d’application, selon un autre mode de réalisation exemplaire.
La Figure 14 est une vue schématique d'un système informatique exemplaire pour l’hébergement des systèmes ou des dispositifs de la Figure 1.
DESCRIPTION DÉTAILLÉE
Les modes de réalisation de l'invention fournissent un système et un procédé pour permettre de fournir dynamiquement du contenu dans un environnement informatique.
En référence à la Figure 1, un environnement opérationnel exemplaire d’un système fournisseur de contenu dynamique 100 est illustré, selon certains modes de réalisation.
Le système fournisseur de contenu dynamique 100 peut être mis en œuvre pour fournir dynamiquement du contenu généré par au moins un système fournisseur de contenu 2 à un dispositif utilisateur 3 à partir des données capturées dans une application 4 s’exécutant (ou s’exécutant) sur le dispositif utilisateur 3, via un dispositif de liaison 10.
Le système fournisseur de contenu 2 peut être tout système configuré pour fournir directement du contenu à un ou plusieurs dispositifs utilisateurs 5 en réponse aux requêtes utilisateur via un réseau de communication 62, ou indirectement via le dispositif de liaison 10 à un dispositif utilisateur 3 exécutant une application donnée 4, via un réseau de communication 60. Dans un mode de réalisation, le système fournisseur de contenu 2 peut héberger un ou plusieurs sites web et/ou avoir un service d’hébergement d’hébergement d’un ou plusieurs sites web.
Tel qu’utilisé dans les présentes, le terme « contenu » fait référence à tout contenu qui peut être fourni à un dispositif utilisateur via un système informatique, tel que des données, des produits, services qui incluent non seulement du texte électronique, mais également des images, des enregistrements audio et d’autres formes de données qui peuvent être traitées, stockées et retournées sous la forme électronique à un dispositif utilisateur via une interface utilisateur.
Chaque dispositif client 3, 5 (également ci-après dénommé un « dispositif utilisateur ») peut être un dispositif informatique personnel, une tablette informatique, un terminal client léger, un smartphone et/ou un autre dispositif informatique de ce type. Chaque dispositif client 3, 5 peut héberger des navigateurs Web et/ou un logiciel d’applications personnalisées (par ex., un système client) et peut inclure une interface utilisateur client.
Chaque dispositif utilisateur 3, 5 peut par ailleurs inclure une application de navigateur Web qui communique avec une application de serveur Web hébergée par le système fournisseur de contenu 2. Ladite application de serveur Web peut en retour communiquer avec des systèmes fournisseurs de contenu indirects 20 via un réseau dédié 62 pour permettre au système fournisseur de contenu 2 de fournir indirectement le contenu fourni par ledit système fournisseur de contenu « indirect » 20 aux dispositifs utilisateur 3, 5.
Le dispositif utilisateur 3 peut être tout système informatique approprié, configuré pour exécuter une application 4 associée à une Interface d’Application 40 (également ci-après dénommée « IA) »), à travers laquelle un utilisateur peut saisir ou recevoir des données. Les données 400 saisies dans l’application par l’utilisateur ou reçues par l’utilisateur (généralement dénommée «donnée d’entrée») peuvent être stockées dans une mémoire de données de l’application 4.
Un utilisateur exploitant l’un des dispositifs utilisateurs 3, 5 peut être directement en interface avec le système fournisseur de contenu 100 utilisant les dispositifs utilisateur 3, 5 pendant une session de requête de services liée à une application (par exemple, avec accès effectué par connexion à un service Web). Le système fournisseur de contenu 2 peut stocker un compte utilisateur, l’utilisateur est déjà enregistré, ou autrement ne peut comprendre aucune donnée liée à l’utilisateur, si l’utilisateur n’a pas précédemment créé un compte utilisateur.
Le système fournisseur de contenu 2 peut être dédié à un ou plusieurs champs de services spécifiques (par exemple, le champ de voyage ou le champ immobilier). Alors que chaque dispositif utilisateur 5 peut se connecter au réseau de communication 62 pour permettre de manière conventionnelle l’initialisation d’une session de requête de contenu par un utilisateur avec le système fournisseur de contenu 2 et la réception du contenu demandé par le système fournisseur de contenu 2 en réponse à la requête de contenu, le dispositif utilisateur 3, selon les modes de réalisation de l’invention, peut accéder audit contenu de manière transparente. Plus spécifiquement, le dispositif utilisateur 3 peut accéder au contenu de manière transparente à partir du système fournisseur de contenu 2 en réponse aux données reçues par une application 4 s’exécutant sur le dispositif utilisateur 3, le dispositif utilisateur 3 étant connecté au dispositif de liaison 10 via le réseau de communication 60. Les données reçues par l’application 4 peuvent comprendre :
- l’entrée des données 400 par un utilisateur pendant l’exécution de l’application via l’interface utilisateur de l’application 40 et/ou les données reçues par l’utilisateur ; une telle donnée peut être stockée dans la mémoire de données 400 et/ou
- les données auxiliaires qui peuvent comprendre des données liées à l’utilisateur/au contexte actuel de l’application se rapportant également aux données contextuelles de l’application (par exemple, si l’utilisateur accède à une Carte client comprenant des données telles que l’adresse du client et les informations de contact du client) ; lesdites données peuvent être conservées dans une plusieurs sources auxiliaires, par exemple dans une mémoire 35 (par exemple, l’emplacement profil utilisateur) ou dans les réglages utilisateur 404 (préférences de l’utilisateur définies pour l’application).
Le dispositif de liaison 10 peut interagir avec l’application 4 pour capturer les données d’entrée 400 et déterminer si la requête de l’utilisateur peut être extrapolée en utilisant les données d’entrée 400 et/ou les données auxiliaires, selon un ou plusieurs formats de requêtes prédéfinis, supportés par le système fournisseur de contenu 2. Chaque requête est définie par au moins un ensemble de paramètres de requête représentant les entrées de la requête. Les paramètres de requête sont structurés selon le format prescrit par le système fournisseur de contenu 2.
Si le dispositif de liaison 10 peut extrapoler une requête à partir des données capturées dans l’application et/ou les données auxiliaires, le dispositif de liaison 10 peut être configuré pour générer une requête, les champs de requête étant complétés par des valeurs déterminées par le dispositif de liaison 10 à partir des données d’entrée 400, et éventuellement des données auxiliaires (telles que les données utilisateur stockées dans la mémoire 35 ou les paramètres utilisateurs 404). Le dispositif de liaison 10 peut ainsi transmettre la requête au système fournisseur de contenu 2.
Pour déterminer les paramètres de la requête, le dispositif de liaison peut mapper (ou associer) chaque paramètre de requête à un élément de donnée des données d’entrée 400 et/ou des données auxiliaires. Dans certains modes de réalisation, chaque mappage entre un paramètre de requête et un élément de donnée peut par ailleurs être attribué à une notation qui peut être utilisée pour générer la requête.
Dans une application exemplaire de l’invention à un système fournisseur de voyage mis en œuvre comme un serveur Web et configuré pour fournir des propositions de voyage (pour la préréservation ou la réservation) en réponse à des requêtes de voyage, le format prédéfini d’une requête générée par le dispositif de liaison peut comprendre les paramètres de requête suivants :
- les paramètres de lieux/date/heure de départ ;
- les paramètres de lieux/date/heure d’arrivée ;
- les paramètres supplémentaires liés au voyage.
Les paramètres de la requête peuvent inclure les paramètres de requête « obligatoires » ou « optionnels », les paramètres de requête obligatoire étant requis par le système de gestion du contenu pour lui permettre de traiter la requête. Les paramètres de requête optionnels peuvent inclure par exemple la langue préférée de l’utilisateur, ou des paramètres d’affinage de la requête (par ex. le moment de la journée, la société préférée).
Le système fournisseur de contenu 2 peut délivrer du contenu au dispositif utilisateur 3, soit directement soit via le dispositif de liaison 10, en réponse à la requête générée.
Des modes de réalisation de l'invention peuvent être mis en œuvre par un système informatique comprenant un ou plusieurs ordinateurs ou serveurs en réseau. Le système informatique peut fournir des fonctions de traitement et de bases de données pour un fournisseur de contenu.
Le système fournisseur de contenu 2 peut héberger un ou plusieurs sites Web et/ou avoir un service d’hébergement hébergeant un ou plusieurs sites web.
L’application 4 peut comprendre une extension d’application exécutable 41 (également dénommée « plug-in » d’application, « add-in » ou « composant logiciel d’extension ») configurée pour ajouter une caractéristique de fourniture de contenu dynamique à l’application 4. L’extension d’application 41 peut être statistiquement ou dynamiquement activée dans l’application 4, lorsque l’application est lancée.
L’interface d’application 40 peut avoir une configuration personnalisée en fonction de l’application 4 et peut être mise à jour dynamiquement en fonction de l’exécution de l’application 4 et de l’extension d’application 41, lorsque ladite extension est activée. L’interface d’application 40 peut être rendue sur une unité de rendu 30 du dispositif utilisateur 3, tel qu’une Interface utilisateur (par exemple, une Interface utilisateur graphique) et peut comprendre différents types d’éléments graphiques, tels que des fenêtres, des champs d’entrée de texte, des icônes, des éléments sélectionnables, des éléments de contrôle graphique tels que des menus déroulants ou boîte de liste, des boutons d’activation, etc. L’unité de rendu 30 sera appelée interface utilisateur à des fins d’illustration.
Les données 400 reçues via l’interface d’application 40 peuvent comprendre un ensemble d’éléments de donnée 401. Chaque élément de donnée peut être défini par une valeur ayant un type (chaîne, caractère, numéro, etc.) et en option un format de données (format de date, format d’heure, etc.). Un élément de donnée peut par ailleurs appartenir à une catégorie de donnée (par ex. lieu, date, heure, etc.). Dans certains modes de réalisation dans lesquels les données entrées par l’utilisateur dans l’interface d’application sont structurées comme un outil de gestion d’événements, l’élément de donnée peut par ailleurs avoir une typologie (par exemple, date de début d’événement, lieu de l’événement, etc.).
Dans certains modes de réalisation, l’entrée des éléments de donnée dans l’application 4 peut être structurée selon un graphique de dépendance, chaque élément de donnée étant représenté par un nom et une valeur, ou plus généralement selon un format de représentation de données.
Le dispositif utilisateur 3 peut comprendre un gestionnaire d’interface (non montré) pour générer l’affichage d’informations sur l’interface utilisateur 30, le gestionnaire d’interface générant dynamiquement un affichage de l’interface d’entrée de l'application 40, en fonction de l'exécution de l’application 4 et de l'activation de l’extension d’application 41.
L’application 4 peut être toute application conçue pour recevoir les données via l’interface d’application 40 et supporter l’extension d’application 41. Par exemple, l’application 4 peut être une application de communication à travers laquelle un utilisateur peut communiquer avec un autre utilisateur via une interface de messagerie, telle qu'une application de messagerie (par ex. application courriel) ou une application de réseau social (par ex. FACEBOOK, TWITTER, etc.). L’application peut également être une application d’organisation, telle qu’un calendrier ou un tableau de bord, ou une application de bureau (telle qu’une application de traitement de texte, par exemple). L’application peut comprendre un outil unique ou fournir un ensemble d’outils (tel qu’un outil d’application de messagerie, un outil de gestion de réunions et un outil de gestion du calendrier). Si l’application comprend plusieurs outils, l’accès de l’utilisateur à un outil de l’application 4 peut déclencher la fourniture de contenu dynamique.
II faut noter que, bien que l’invention ait des avantages particuliers pour les données d’entrée 400 de type texte, dans certains modes de réalisation les données d’entrées 400 peuvent inclure tout type de donnée qui peut être analysé ou interprété par le dispositif de liaison 10, tel que des données de type vocal, des données de types d’images ou une combinaison de celles-ci.
L’application 4 peut être située à l’intérieur (par ex. application logicielle de bureau préinstallée sur le dispositif utilisateur) ou à l’extérieur du dispositif utilisateur et/ou distribuée parmi de multiples ordinateurs (par ex. application logicielle client-serveur, telle qu’une application Web). L’application 4 peut être sinon fournie sous la forme d’un service sur le réseau, tel qu’un service informatique en nuage.
Le dispositif utilisateur 3 peut être configuré pour communiquer via le réseau 60 pour exécuter l’application 4, si l’application est une application client-serveur ou une application fournie sous la forme d’un service informatique en nuage.
Chaque réseau de communication 60, 61, 62 peut inclure un ou plusieurs réseaux privés et/ou publics (par ex., Internet) qui permettent d’échanger des données, tels qu’internet, un réseau local (LAN), un réseau étendu (WAN), un réseau de voix/données cellulaire, une ou plusieurs connexions de bus à grande vitesse et/ou d’autres types de réseaux de communication. Chaque réseau de communication 60, 61, 62 peut utiliser les technologies de communication standards et/ou les protocoles tels que 4G, Ethernet, 802.11, TCP/IP (protocole de commande de transmission/protocole Internet), HTTP (protocole de transport hypertexte), FTP (protocole de transfert de fichier), etc. Les données peuvent être échangées via chaque réseau 60, 61, 62 selon les différentes technologies d’échange de données et/ou formats tels que le langage de balisage hypertexte (HTML) et le langage de balisage extensible (XML).
Le dispositif de liaison 10 peut comprendre une première interface 101 pour interagir avec le système fournisseur de contenu 2 via le réseau 61 et une seconde interface 102 pour interagir avec l’application 4 s’exécutant sur le dispositif utilisateur 3 via le réseau 60.
Initialement, un utilisateur peut lancer l’application 4 sur le dispositif utilisateur 3. L’utilisateur peut entrer les données400 («donnée brute») à tout moment sur l’interface d’application 40 de l’application 4 pendant l’exécution de l’application, ce qui change l’état de l’application et peut déclencher dynamiquement une mise à jour de l’affichage de l’interface d’application 40.
L’application 40 peut comprendre une unité d’activation 410 pour activer l’extension d’application 41. Par exemple, ladite unité d’activation 410 peut lancer l’extension d’application en réponse à la sélection d’un élément graphique associé à l’extension d’application 41 sur l’interface d’application 4, tel qu'un bouton d’activation.
Autrement, l’utilisateur peut prédéfinir dans les paramètres utilisateur 404 associés à l’application 4 l’activation automatique de l’extension d’application 41, l’unité d’activation 410 étant ensuite configurée pour activer automatiquement l’extension d’application 41 au lancement de l’application 4. Dans un autre mode de réalisation, l’utilisateur peut activer dynamiquement l’extension d’application 41 en réponse à la détection des conditions d’activation. Par exemple, si l’application est un outil de gestion de réunions, l’extension d’application 41 peut être automatiquement déclenchée si une invitation à une réunion est reçue par l’utilisateur avec un lieu de réunion différent du lieu de l’utilisateur, comme défini dans son profil.
Le dispositif de liaison 10 peut inclure une unité de contrôle d’enregistrement 110 pour contrôler l’accès au dispositif de liaison 10 par un utilisateur de l’application 4 utilisant l’identifiant utilisateur reçu de l’application 4 de manière transparente (connexion permanente).
Le dispositif de liaison 10 peut par ailleurs comprendre un moteur de traitement de données 120 pour traiter les éléments de donnée 401 de chaque bloc de données d’entrée 400 reçu de l’application 4 et/ou les données auxiliaires afin de déduire les valeurs des paramètres de requête et de générer une requête à transmettre au système fournisseur de contenu, si la condition de génération de requête est satisfaite.
Chaque paramètre de requête peut être associé à une liste prédéfinie de valeurs de référence représentant un ensemble de valeurs possibles, à partir desquelles la valeur du paramètre de requête peut être déterminée. Un paramètre de requête peut avoir une typologie (par exemple « lieu de départ», « lieu d’arrivée »), peut appartenir à une catégorie de données (par ex., lieu, date), peut avoir un type de données (par ex. car.) et/ou un format de données (par ex. IATA).
Pour certains paramètres de requête au moins, le moteur de traitement de données 120 peut être configuré pour analyser une ou plusieurs valeurs de référence associées à chaque paramètre de requête.
Le moteur de traitement de données 120 peut être configuré pour déterminer si une ou plusieurs valeurs de référence associée à un paramètre de requêtes peuvent être mappées sur un ou plusieurs éléments de donnée des données d’entrée 400. Le moteur de traitement de données 120 peut par ailleurs déterminer une notation élémentaire (également ci-après dénommée Indicateur de confiance élémentaire ou ETI) pour chaque mappage déterminé entre une valeur de référence et un élément de donnée. Chaque valeur de référence correspondant à un paramètre de requête et mappant un élément de donnée représente une valeur candidate à partir de laquelle la valeur du paramètre de requête correspondant peut être déduite par un générateur de requêtes 150.
Le moteur de traitement de données 120 par ailleurs déterminer la valeur d’un ou de plusieurs paramètres de requête à partir des données auxiliaires (profil utilisateur, préférences utilisateur, données contextuelles d’application, etc.).
Le dispositif de liaison 10 peut en conséquence déduire la valeur d’un paramètre de requête à partir de la valeur d’une valeur de référence associée aux paramètres de requête qui mappe un élément de donnée du bloc de données d’entrée, en fonction de la notation élémentaire calculée pour ledit mappage entre un élément de donnée une valeur de référence.
Le dispositif de liaison 10 peut être configuré pour générer une requête au fournisseur de contenu 2 en utilisant les valeurs déterminées pour au moins certains paramètres de requête, si une condition de génération de requête est satisfaite. Une condition de génération de requête peut par exemple être satisfaite, si une valeur candidate a été trouvée pour chaque paramètre de requête « obligatoire ».
Une application exemplaire de l’invention à la fourniture de contenu de voyage est maintenant envisagée pour illustrer le fonctionnement du dispositif de liaison 10. Pour chaque paramètre de requête (par ex. « lieu de départ »), le moteur de traitement de données 120 peut ainsi initialement analyser une ou plusieurs valeurs de référence prédéfinies, associées au paramètre de requête, déterminer si le bloc de données d’entrée comprend un élément de donnée (par ex. Paris) mappant une ou plusieurs valeurs de référence associée au paramètre de requête (par ex. CDG, Orly, Londres...). Dans un mode de réalisation, les valeurs de référence peuvent comprendre d’éventuelles valeurs du paramètre de requête (par exemple, des valeurs de lieu au format IATA) ou des valeurs équivalentes ou synonymes. Les valeurs de référence peuvent être analysées dans un ordre prédéfini. L’analyse des valeurs de référence pour un paramètre de requête de données peut être stoppée en fonction du nombre de mappages trouvés entre les valeurs de référence associées au paramètre de requête et les éléments de donnée et/ou sur les notations trouvées pour ledit mappage.
Dans certains modes de réalisation, le moteur de traitement de données 120 peut seulement comparer un élément de donnée aux valeurs de référence associées au paramètre de requête, si l’élément de donnée a la même catégorie que le paramètre de requête.
Si un mappage est trouvé entre un élément de donnée d’un bloc de données d’entrée et une ou plusieurs valeurs de référence associée au paramètre de requête en cours de traitement (par ex. l’élément de donnée « Paris » mappe trois valeurs de référence « ORLY », « CDG » et «Paris»), le moteur de traitement de données 120 peut déterminer une notation élémentaire
ETI pour chaque mappage entre un élément de donnée et une valeur de référence.
Chaque paramètre de requête, le moteur de traitement de données 120 peut sélectionner un mappage entre un élément de donnée et une valeur de référence associée au paramètre de requête en fonction des notations élémentaires déterminées pour les différents mappages {Éléments de donnée/Valeur de référence} trouvés pour le paramètre de requête. Dans un mode de réalisation, la notation élémentaire peut être déterminée à partir d’une comparaison sémantique entre un élément de donnée et une valeur de référence et/ou des données ou règles supplémentaires disponibles dans le système fournisseur de contenu ou dans l’application, telles que le profil utilisateur, les préférences utilisateur, etc.
Dans un mode de réalisation, le moteur de traitement de données 120 peut sélectionner pour chaque paramètre de requête le mappage entre un élément de donnée et une valeur de référence correspondant au paramètre de requête qui a la notation la plus élevée, par exemple, la valeur du paramètre requête étant ensuite déduite de ladite valeur de référence. Par exemple, si l’élément de donnée est « 28 juillet » avec une catégorie de date et une typologie « date de début d’événement » tandis que le paramètre de requête à une typologie « date de départ» et appartient également à la catégorie de date. «28/07/2017 » (Valeur de référence 1) et « 28/07/2018 » (Valeur de référence 2) sont deux valeurs de référence qui mappent l’élément de donnée « 28 juillet ». Deux mappages peuvent ainsi être trouvés par le moteur de traitement de données 120 entre :
- la valeur de référence 1 et l’élément de donnée « 28 juillet » (Mappage 1)
- la valeur de référence 2 et l’élément de donnée « 28 juillet » (Mappage 2).
Cela fournit deux valeurs candidates à partir desquels la valeur du paramètre de requête peut être déterminée.
Une notation plus élevée peut être attribuée au « Mappage 1 » qu’au mappage 2 parce que la valeur de référence 1 est la date la plus proche par rapport à la date actuelle. Le moteur de traitement de données 120 peut sélectionner « Mappage 1». Cependant, la valeur du paramètre de requête (« date de départ ») ne sera pas fixée exactement à la valeur de la « valeur de référence 1 » parce que l’élément de donnée à une typologie de « date de début d’événement » différente de la typologie du paramètre de requête. Le moteur de traitement de données 120 peut au lieu de cela déterminer la valeur du paramètre de requête (date de départ) à partir de la valeur de référence sélectionnée (Valeur de référence 1) en utilisant une fonction de calcul. Lesdites valeurs de référence sont ainsi liées au paramètre de requête correspondant par lesdites fonctions de calcul, la valeur du paramètre de requête étant ainsi une fonction de la valeur déterminée pour la valeur de référence.
Par ailleurs, chaque paramètre requête peut être dépendant ou indépendant d’un ou de plusieurs autres paramètres de requête. Par conséquent, la valeur d’un paramètre requête peut être non seulement une fonction d’une valeur de référence correspondante, mais aussi de la valeur d’autres paramètres de requête. Par exemple, le paramètre de requête « heure d’arrivée » est dépendant du paramètre de requête « date d’arrivée ».
Le moteur de traitement de données 120 peut comprendre un analyseur pour analyser les données d’entrée 400. Dans un mode de réalisation, le dispositif de liaison 10 peut être configuré pour recevoir dynamiquement les données d’entrée 400 telles qu’elles sont entrées par l’utilisateur. Dans un mode de réalisation, le dispositif de liaison 10 peut être configuré pour recevoir dynamiquement les données d’entrée 400, en réponse à une action de validation par l’utilisateur. Une action de validation peut être par exemple déclenchée lorsqu’un message est envoyé à un autre utilisateur ou à un autre système ou dispositif, si l’application est une application de communication, lorsqu’une réunion est créée en sauvegardant la réunion dans une application ou un outil de calendrier.
Le dispositif de liaison 10 peut par ailleurs comprendre une unité de test 130 configurée pour déterminer, si une condition de génération de requête est satisfaite à partir du mappage réalisé entre les éléments de donnée et les valeurs de référence.
Le générateur de requêtes 150 peut être configuré pour générer une requête, si la condition de génération de requête est satisfaite, le dispositif de liaison 10 étant configuré pour envoyer la requête ainsi générée au système fournisseur de contenu via l’interface 101.
Le générateur de requêtes 150 peut être configuré pour déduire la valeur du paramètre de requête de la valeur d’une valeur de référence mappant un élément de donnée du bloc de données d’entrée ou des données auxiliaires en fonction de la notation élémentaire obtenue pour ledit mappage. Le générateur de requêtes peut appliquer les règles de structuration des données définies par le système fournisseur de données pour déduire la valeur d’un paramètre de requête, telles que les règles définies par une norme (par ex. IATA). La valeur déduite ainsi calculée peut être attribuée au paramètre de requête correspondant. Le générateur de requête 150 peut par ailleurs tenir compte d’une relation prédéfinie entre les paramètres de requête pour déterminer la valeur d’un paramètre de requête donné. Par exemple, considérant une application de gestion de réunions 4 et un système fournisseur de contenu 2 du système fournisseur de voyage type, supposant qu’une valeur d’élément de donnée d’une typologie de date de début d’évènement et une autre valeur d’élément de donnée d’une typologie de date de début d’évènement ont été chacune mappées sur une valeur de référence (une valeur de référence associée à un paramètre de requête de date de départ et une valeur de référence associée à un paramètre de requête d’heure de départ) par le dispositif de liaison 10, les valeurs des paramètres de requête « date de départ » et « heure de départ » pour une requête de voyage peuvent ensuite être déduites des deux valeurs de référence, à l’aide de fonctions ou de règles de calcul prédéfinies.
Dans certains modes de réalisation, le dispositif de liaison 10 peut également comprendre un convertisseur de données 140 configuré pour convertir les éléments de donnée mappés sur les valeurs de référence dans le format de paramètre de requêtes correspondants, comme défini par le système fournisseur de contenu 2, si la condition de génération de requête est satisfaite, avant la génération de la requête.
En fonctionnement, l’utilisateur peut ainsi accéder au système fournisseur de contenu 2 ou interagir avec lui en utilisant l’interface d’application 40 au lieu d’utiliser directement l’interface du système fournisseur de contenu sans nécessiter de préciser activement une requête de contenu à partir du système fournisseur de contenu 2.
Étant donné que l’application est en cours d’exécution et que l’application 4 reçoit des données, le dispositif de liaison 10 peut générer dynamiquement des requêtes en réponse aux données transmises à partir de l’application 4. Le système fournisseur de contenu 2 peut comprendre un moteur de recherche configuré pour traiter les requêtes reçues selon un protocole de communication approprié (tel que le protocole HTTP, par exemple), les requêtes ayant un format parmi les formats de requêtes prédéfinis supportés par le système fournisseur de contenu 2. En réponse aux requêtes reçues du dispositif de liaison 10, le système fournisseur de contenu 2 peut déclencher une recherche par son moteur de recherche pour déterminer si les résultats existants satisfont la requête.
Du côté de l’application, les données reçues de l’utilisateur ou déduites du contexte via l’interface d’application 40 peuvent être collectées en continu et transmises au dispositif de liaison 10, jusqu’à ce que le dispositif de liaison collecte suffisamment d’informations pour générer une requête de contenu (par exemple de produit ou de données).
L’interface d’application 40 peut comprendre une zone d’interface 403 (représentée schématiquement à la Figure 1) dédiée à l’extension d’application 41. L’interface de la zone dédiée 403 peut changer dynamiquement lorsque l’utilisateur entre des données sur la partie restante de l’interface d’application, suite au traitement effectué par le dispositif de liaison 10. Dans certains modes de réalisation, la forme et/ou la taille et/ou le mode d’affichage de la zone 403 peut être dynamiquement modifié en fonction des résultats retournés par le dispositif de liaison 10 et/ou si une action de l’utilisateur est détectée dans la zone 403. Dans un mode de réalisation, le dispositif de liaison 10 peut retourner un drapeau de fiabilité à l’application pour contrôler le mode d’affichage de la zone d’interface 403. La zone d’interface peut être affichée dans la même fenêtre que l’application d’interface ou dans une fenêtre séparée (fenêtre contextuelle) par exemple. Le drapeau de fiabilité peut être calculé par le dispositif de liaison 10 comme une fonction des notations déterminées pour le mappage entre les éléments de donnée et les valeurs de référence.
Les dispositifs de liaison 10 peuvent par exemple permettre l’achat d’un produit ou d’un service par l’utilisateur en déterminant si les données reçues par l’application correspondent au moins à certains paramètres prédéfinis d’une requête, correspondant à l’un des formats de requêtes prédéfinis par le système fournisseur de contenu.
Si le moteur de recherche du système fournisseur de contenu 2 détermine que le contenu (par ex. un ou plusieurs produits) existant correspond à la requête reçue du dispositif de liaison 10, le système fournisseur de contenu 2 retourner une réponse comprenant les résultats de recherche satisfaisant la requête (par exemple des offres de produits) à l’application 4 via le dispositif de liaison 10. L’extension d’application 41 générer un affichage des résultats dans la zone dédiée 403 de l’interface d’application 40 ou autrement rediriger l’utilisateur vers le Domaine Internet du système fournisseur de contenu 2 en ouvrant une fenêtres contextuelles pour permettre à l’utilisateur de terminer l’accès au contenu (par exemple à l’achat d’un ou de plusieurs produits). Autrement, l’extension d’application 41 peut être associé à une partie dédiée de l’interface d’application sur laquelle l’utilisateur peut accéder aux résultats satisfaisants la requête (par exemple des offres de produits) et peut sélectionner un ou plusieurs résultats pouvant rediriger l’utilisateur vers l’interface du système fournisseur de contenu 2 pour terminer l’accès au contenu (donnée, service), par exemple pour terminer une transaction d’achat de produits.
L’extension d’application 41 peut comprendre une fonction de redirection pour rediriger l’utilisateur au système fournisseur de contenu 2 via une application dédiée installée sur le dispositif utilisateur3 ou via le Domaine Internet du système fournisseur de contenu 2 en utilisant l’URL associée, en réponse à une sélection faite par l’utilisateur.
Par exemple, le dispositif de liaison 10 peut envoyer la requête au système fournisseur de contenu 2 en utilisant une URL d’un type prédéfini qui peut comprendre un ensemble de champs tels que :
- un Corps ;
- le champ d’identifiant du système fournisseur de contenu, tel qu’un Champ de chaîne ;
- des champs liés aux paramètres de requête (paires nom/valeur), tels que déterminés par le dispositif de liaison 10 qui peut inclure en outre la langue détectée par le dispositif de liaison 10 (par exemple la langue américaine).
L’homme du métier comprendra facilement que l’invention ne se limite pas auxdits champs spécifiques dans l’URL de requête et peut inclure différents champs en fonction de l’application de l’invention.
Plus généralement, l’URL de requête peut correspondre à l’un des multiples types d’URL définis par le système fournisseur de contenu en fonction de la hiérarchie du Système de noms de domaine (par exemple par marque, par région géographique). Chaque type d’URL peut comprendre un ensemble de champs, chacun comprenant une clé et une valeur.
La Figure 2 est un diagramme bloc de l’unité de traitement de données 120 selon certains modes de réalisation.
L’unité de traitement 120 peut comprendre :
- une liste prédéfinie de valeurs de référence 12 comprenant la liste des valeurs de référence pour lesquels un mappage est trouvé par le dispositif de liaison 10 en réponse à la réception d’un bloc de données d’entrée de l’application 4 ;
- un analyseur de données 11 configuré pour analyser le bloc de données d’entrée ;
- un mappeur 13 configuré pour déterminer si au moins une valeur de référence de la liste 12 peut être mappée sur un ou plusieurs éléments de donnée du bloc de données d’entrée et/ou données d’une ou plusieurs sources auxiliaires de données (préférence utilisateur, réglage utilisateur, profil utilisateur, etc.); le mappeur 13 peut mettre en œuvre un ou plusieurs algorithmes de recherche adaptés aux structures de données supportées par l’application 4 incluant des algorithmes de recherche optimisés pour limiter l’espace de recherche.
- un bloc de détermination de notation 14 configuré pour déterminer une notation élémentaire ETI pour chaque mappage déterminé entre une valeur de référence et un élément de donnée ;
- une structure de données d’association 16 configurée pour stocker chaque valeur de référence avec l’élément de donnée mappé, et éventuellement la notation associée, pour chaque mappage entre une valeur de référence et un élément de donnée.
Des modes de réalisation de l'invention peuvent être mis en œuvre par un système informatique comprenant un ou plusieurs ordinateurs ou serveurs en réseau. Le système informatique peut fournir des fonctions de traitement et de bases de données pour un fournisseur de contenu.
Faisant maintenant référence à la Figure 3, un environnement d’exploitation exemplaire 300 selon un mode de réalisation de l’invention dans lequel le système fournisseur de voyage 2 est un système de réservation. Le système fournisseur de voyage 2 peut être configuré pour déterminer les propositions de voyage en réponse à une requête et permettre la réservation d’un voyage ou de services liés au voyage en réponse la sélection d’une proposition par un utilisateur, soit directement si le système fournisseur de voyage, soit indirectement.A L’environnement 300 peut inclure un Système de distribution globale (GDS) 200, un ou plusieurs systèmes fournisseurs de produits indirects 20, tels que des systèmes de transporteur 201, un ou plusieurs systèmes d’achat de voyage ou vendeurs indirects (systèmes fournisseurs de contenu auxiliaires), tels qu’un système d’agence de voyages 202, le système fournisseur de voyage 2 et un ou plusieurs dispositifs clients 3, 5. Chaque GDS 200, les systèmes de transporteur 201, le système vendeur indirect 202, le système fournisseur de voyage 2 et le dispositif client 3 ou 5 peuvent communiquer via un réseau 62. Les systèmes de transporteur 201 chacun inclure un Système de réservation informatique (CRS) et/ou un système de facturation pour la compagnie aérienne respective qui permet au GDS 200 et/ou au système vendeur indirect 202 de réserver et de payer des billets d’avion. Les systèmes de transporteur 201 peuvent aussi interagir les uns avec les autres, directement ou via le GDS 200, afin de permettre au transporteur émetteur de vendre des sièges fournis par le transporteur de fait. Le transporteur de fait peut ensuite facturer le transporteur émetteur pour les services fournis.
Le GDS 200 peut être configuré pour faciliter la communication entre les systèmes de transporteur 201 et les systèmes vendeurs indirects 202 en permettant aux agents de voyage, aux transporteurs émetteurs ou à d’autres vendeurs indirects de rechercher les segments disponibles et de confirmer des réservations sur un ou plusieurs systèmes de transporteur 201 via le GDS 200. À cette fin, le GDS 200 peut entretenir des liens avec chacun des systèmes de transporteur 201 via le réseau 62. Ces liens peuvent permettre au GDS 200 d’obtenir des données de planification ou de disponibilité pour les segments à partir des systèmes de transporteur 201 et des requêtes de réservation de proposition de voyage aux systèmes de support 201. Les systèmes de transporteur et d’agence de voyages 201, 202 peuvent ainsi réserver des vols, trains ou autres types de segments auprès de multiples transporteurs via une seule connexion au GDS 200. Le GDS 200 peut stocker et/ou conserver un enregistrement de nom de passager (PNR) qui inclut un ensemble complet de données pour l’itinéraire d’un voyage, notamment les segments de multiples transporteurs et/ou autres services de voyage comprenant le voyage, tels que des réservations d’hôtel ou de location de voiture.
Un système d’agence de voyages 202 peut inclure un serveur Web qui fournit un site Web accessible publiquement. Ce site Web peut être configuré pour accéder aux caractéristiques de planification de voyage, telles que la capacité à rechercher des produits de voyage correspondant à une requête de voyage. À cette fin, le système d’agence de voyages 202 peut fournir au voyageur l’accès à des données dans une ou plusieurs bases de données hébergées par le GDS 200, les systèmes de transporteur 201, le système d’agence de voyages 202 et le système de planification de voyage 203. Dans un autre mode de réalisation de l’invention, le système d’agence de voyages 202 peut être un système propriétaire qui limite l’accès aux fournisseurs de services de voyage ou d’agent de voyages auquel cas l’accès peut être fourni via un site Web privé ou une autre application.
Le système fournisseur de voyage 2 peut être en communication avec le système d’agence de voyages 202 via le réseau 62 ou une autre connexion appropriée. Dans d’autres modes de réalisation de l’invention, tout ou partie du système fournisseur de voyage 2 peut être intégré ou plusieurs autres systèmes 200, 201, 202, 203. Les voyageurs ou les agents de voyage peuvent utiliser le système d’agence de voyages 202 pour générer et/ou rechercher des propositions de voyages qui satisfont une requête de voyage reçue du voyageur utilisant le système fournisseur de voyage 2.
Le GDS 200, les systèmes de transporteur 201, le système d’agence de voyages 202, le système fournisseur de voyage 2 et les dispositifs utilisateur 3, 5 de l’environnement d’exploitation peuvent être mis en œuvre sur un ou plusieurs dispositifs ou systèmes informatiques, désignés collectivement sous le nom d’ordinateur, tels qu’un ordinateur.
La Figure 4 est un organigramme décrivant le processus mis en œuvre par l’application 4 pour se connecter dynamiquement au dispositif de liaison 10, selon un mode de réalisation.
Initialement, l’application 4 est lancée par l’utilisateur (bloc 500).
À l’étape 501, l’utilisateur peut se connecter à l’extension d’application 41. Autrement, l’utilisateur peut se connecter automatiquement à l’extension d’application, lorsqu’il lance l’application, si la connexion automatique a été activée.
À l’étape 502, les données d’entrée sont reçues par l’application 4 (par ex. jeton de sécurité, paramètres, langue) soit directement de l’utilisateur ou par validation des données reçues par l’utilisateur (par exemple, invitation à une réunion, pièce jointe, etc.) via l’interface d’application 40. L’utilisateur peut par exemple entrer les données à l’aide d’un dispositif d’entrée tel qu’un clavier ou un dispositif de point (par ex., un dispositif de souris) via l’interface d’application. Les données d’entrée peuvent être par exemple des données textuelles ayant une structure de données prédéfinie, définie par l’application 4. Dans certains modes de réalisation, tels qu’une application de calendrier ou d’agenda, un outil de calendrier ou d’agenda d’une application (application de messagerie), l’interface d’application peut comprendre des champs prédéfinis, tels que des boîtes de texte, chacune définie par une paire de données comprenant un nom et une valeur. Une boîte de texte peut s'afficher sur l’interface d’application à l’association à un nom. La valeur d’une boîte de texte peut être entrée ou sélectionnée par l’utilisateur ou avoir une valeur par défaut définie par l’application ou être automatiquement remplie par l’application 4 en fonction des paramètres utilisateur 404. Par exemple, si l’application comprend un outil de calendrier, le calendrier comprend un ensemble d’entrées de calendrier. Une entrée de calendrier peut être créée pour un « événement » (par exemple une « réunion »). Lorsqu’il sélectionne une entrée de calendrier, l’utilisateur peut être invité à préciser différents champs (boîtes de texte) notamment :
- un champ d’objet ;
- un champ de lieu ;
- un champ de date de début ;
- un champ de date de fin ;
- un champ d’heure de début ;
- un champ d’heure de fin.
Chacun des champs susmentionnés peut être défini par une paire de données comprenant un nom et une valeur. L’entrée de données par l’utilisateur peut être structurée selon une structure de données prédéfinie par l’application 4, la structure de données identifiant les paires nom/valeur des champs et les relations entre les champs.
À l’étape 503, les données d’entrée peuvent être stockées dans la mémoire d’entrée de données 400 de l’application selon la structure de représentation des données de l’application 4. Les données d’entrée peuvent être stockées comme des blocs de données. Dans certains modes de réalisation, les données d’entrée peuvent être stockées dans la mémoire 400 lorsque l’utilisateur sauvegarde les données d’entrée en effectuant une action, par exemple en sélectionnant un bouton de sauvegarde d’une entrée de calendrier ou en envoyant un message, pour une application de messagerie.
Chaque bloc de données d’entrée stocké dans la mémoire de données d’entrée 400 peut comprendre un ensemble d’éléments de donnée 401, chaque élément de donnée ayant un format de données et une valeur.
À l’étape 504, l’extension d’application (41) peut déterminer si une condition d’activation est satisfaite à partir du bloc de données d’entrée.
Dans certains modes de réalisation, la condition d’activation peut être satisfaite en réponse à la réception de données par l’application 4. Dans un mode de réalisation dans lequel l’interface d’application 40 comprend un ensemble de boîtes de texte défini par une paires nom/valeur, la condition d’activation peut dépendre de la réception d’au moins une valeur pour l’une des boîtes de texte, par exemple suite à une entrée directe par l’utilisateur. Dans d’autres modes de réalisation, la condition d’activation peut être satisfaite en réponse à la réception de données par l’utilisateur, ou à la validation de données reçues par l’utilisateur ou même à l’ouverture d’un enregistrement client (en réponse à l’ouverture dudit enregistrement client, le dispositif de liaison peut par exemple générer une requête de voyage pour rendre visite au client à une date proche telle que la semaine suivante). Dans un autre mode de réalisation dans lequel l’interface d’application 40 comprend des zones d’entrée de texte plein par l’utilisateur (par ex., une application de messagerie), la condition d’activation peut être satisfaite en réponse à l’entrée de texte par l’utilisateur. Dans des modes de réalisation dans lesquels l’application 4 permet la création d’entrées (événement, message), la condition d’activation peut être satisfaite en réponse à la création d’une nouvelle entrée par l’utilisateur (par ex. la création d’un nouveau message ou événement).
À l’étape 506, la connexion au dispositif de liaison peut être activée par l’extension d’application 41 en réponse à la détection de la condition d’activation. L’application 4 peut ensuite transmettre au moins certains éléments de donnée 401 compris dans chaque bloc de données d’entrée 400 au dispositif de liaison 10 pendant l’activation de la connexion au dispositif de liaison 10.
La Figure 5 est organigramme décrivant le processus de connexion permanente d’un utilisateur à l’extension d’application (bloc 501 de la figure 4).
À l’étape 600, en réponse au lancement de l’extension d’application, l’application 4 peut vérifier si la mémoire d’application 35 comprend un identifiant utilisateur tel qu’un justificatif d’identité de l’utilisateur ou un jeton de sécurité pour se connecter au système fournisseur de contenu 2.
Si tel est le cas, l’identifiant d’authentification peut être récupéré de manière transparente de la zone de mémoire 35 à l’étape 602 et envoyé au dispositif de liaison 10 à l’étape 610. L’identifiant utilisateur peut être vérifié par le fournisseur de contenu 2 (transmission via le dispositif de liaison à l’étape 607) et peut être stocké en mémoire 35, s’il est valide à l’étape 608.
Autrement, si aucun identifiant utilisateur ni trouver dans la zone de mémoire 35 (par exemple, parce que l’utilisateur n’a pas entré son identifiant précédemment ou était incapable de stocker son identifiant parce que la zone de mémoire 35 était vide ou insuffisante), l’application 4 peut déclencher l’affichage d’une panne de connexion pour inviter l’utilisateur à entrer un identifiant utilisateur à l’étape 604. Si l’utilisateur entre un identifiant utilisateur (606), l’identifiant utilisateur peut être vérifié par le fournisseur de contenu 2 (transmission via le dispositif de liaison à l’étape 607) et stocké en mémoire 35, s’il est valide à l’étape 608.
La Figure 6 est un organigramme décrivant le processus de création d’une session par le dispositif de liaison 10 pour permettre l’accès transparent d’un utilisateur de l’application 4 au système fournisseur de contenu en réponse à la réception de l’identifiant utilisateur (étape 607 de la Figure 5), selon un mode de réalisation (bloc 700).
À l’étape 701, le dispositif de liaison 10 peut comparer l’identifiant utilisateur reçu de l’application 4 à un ensemble d’identifiants autorisés prédéfinis.
Si l’identifiant d’authentification ne correspond pas à l’ensemble d’identifiants autorisés prédéfinis, le dispositif de liaison 10 peut retourner un message d’erreur de connexion à l’application 4 à l’étape 702 ou autrement créer un profil pour l’utilisateur. L’application 4 peut déclencher l’affichage d’un panneau de connexion pour inviter l’utilisateur à entrer son identifiant utilisateur (de manière similaire à l’étape 604 de la figure 5).
En réponse à un identifiant d’authentification reçu de l’utilisateur, à l’étape 704, le dispositif de liaison 10 peut récupérer les informations liées à l’utilisateur, par exemple les informations utilisateur liées au système/à la société/la communauté à laquelle l’utilisateur appartient, dans le but de valider ou de ne pas valider l’accès utilisateur, sans nécessiter des entrées supplémentaires de l’utilisateur (par ex., entrée de l’identifiant de communauté, identifiant de courriel).
À l’étape 706, une session peut être créée (exemple de système fournisseur de contenu 2).
À l’étape 708, un message de création de sessions peut être envoyé à l’application 4 dans lequel l’application 4 et le dispositif de liaison 10 peuvent échanger des données pour générer des requêtes au système fournisseur de contenu 2. Le dispositif de liaison peut par ailleurs envoyer des informations de profil utilisateur, telles que récupérées à l’étape 704, à l’application pour stockage dans la zone de mémoire 35.
L’application peut créer un identifiant session unique et/ou un jeton de sécurité pour l’échange sécurisé entre l’application 4 et le dispositif de liaison 10.
La zone de mémoire 35 peut comprendre une zone 350 dédiée à l’utilisateur, dans laquelle l’identifiant utilisateur et/ou les informations de profil utilisateur {par ex. système/société/communauté) et/ou l’identifiant de session et/ou le jeton de sécurité peuvent être stockés. Si l’application 4 est une application Web ou une application partagée, la zone de mémoire d’application 35 peut être divisée en une ou plusieurs sous-zones, chaque sous-zone étant liée à un utilisateur. Dans certains modes de réalisation, la mémoire elle-même 35 peut être conservée sur un serveur une copie de la mémoire peut être conservée sur ledit serveur.
Par conséquent, la connexion peut être effectuée de manière transparente pour le compte de l’utilisateur (connexion permanente) par l’application 4 et le dispositif de liaison 10.
La Figure 7 est un organigramme décrivant le processus de génération d’une requête au niveau du dispositif de liaison 10 provenant des données reçues de l’application 4, selon certains modes de réalisation.
Pendant une session, le dispositif de liaison 10 peut être configuré pour échanger dynamiquement avec l’application 4.
Lorsque l’utilisateur saisit des données dans l’application via la mémoire d’application, l’application 4 peut stocker les données d’entrée de manière structurée dans la mémoire 35.
En réponse à la détection d’une condition d’activation (correspondant à l’étape 504 de la figure 4) liée à l’entrée d’un nouveau bloc de données par l’utilisateur via l’interface d’application, l’application peut envoyer le bloc de données au dispositif de liaison 10. Dans un mode de réalisation, l’application peut envoyer le bloc de données d’entrée «tel quel» sans traitement préalable. Autrement, l’application 4 peut retourner au moins certains éléments de donnée du bloc de données d'entrée au dispositif de liaison avec ou sans prétraitement. Si aucune donnée n’est disponible dans l’application 4 (aucune donnée n’a été saisie par l’utilisateur), l’application 4 peut envoyer une valeur vide au dispositif de liaison 10 périodiquement jusqu’à ce que la donnée soit entrée par l’utilisateur dans l’application 4.
À l’étape 800, dispositif de liaison reçoit ainsi un bloc de données de l’application 4, le bloc de données comprenant un ensemble d’éléments de donnée.
Dans une mise en œuvre exemplaire de l’invention utilisant une application de messagerie électronique 4 comprenant un ensemble d’outils ou un système fournisseur de voyage 2 configuré pour déterminer les propositions de voyage en réponse aux requêtes de voyage telles qu’une date/un lieu de départ et/ou une date/un lieu d’arrivée, les étapes suivantes peuvent être par exemple réalisées :
- si l’utilisateur crée ou a reçu une entrée de calendrier dans l’application de messagerie électronique 4, le bloc de données retourné au dispositif de liaison 10 peut inclure un ensemble d’éléments de donnée comprenant une valeur pour un ou plusieurs champs incluant un titre, un lieu, les participants (courriel ou nom), une date et une heure de début (quel fuseau horaire), une date et une heure de fin (quel fuseau horaire) ;
- si l’utilisateur crée ou reçoit une entrée de courriel, le bloc de données retourné au dispositif de liaison 10 peut inclure un ensemble d’éléments de donnée comprenant des données liées à une réunion qui peuvent comprendre de manière similaire une valeur pour un ou plusieurs champs parmi un titre, un lieu, les participants (courriel ou nom), une date et une heure de début (quel fuseau horaire), une date et une heure de fin (quel fuseau horaire) ;
- Si l’utilisateur crée une carte client, le bloc de données retourné au dispositif de liaison 10 peut inclure un ensemble d’éléments de donnée comprenant une valeur pour un ou plusieurs champs parmi une adresse client, un nom de client, une référence de facturation client ;
- Si le client écrit un courriel, le bloc de données retourné au Dispositif de liaison 10 peut inclure un ensemble d’éléments de donnée comprenant une valeur pour un ou plusieurs champs liés au voyage déduits du texte utilisateur et/ou des pièces jointes incluses dans le courriel, tels que les informations de lieu/d’accès. Le dispositif de liaison 10 peut par ailleurs utiliser une ou plusieurs sources auxiliaires d’information, telles que les données disponibles dans l’Application 4 (pas nécessairement dans une entrée de calendrier, un courriel ou une carte client). Par exemple, le profil utilisateur ou les informations de réglage dans l’application (par ex. la langue de l’utilisateur, les informations de lieu/d’accès, la peau ou les valeurs CSS) peuvent être utilisés par le dispositif de liaison 10.
À l’étape 802, le dispositif de liaison 10 peut analyser et traiter le bloc de données d’entrée reçu de l’Application (Figure 3) ou les données auxiliaires pour déterminer si elles comprennent des éléments de donnée qui correspondent à une ou plusieurs valeurs de référence associées à chaque paramètre de requête.
Les valeurs de référence peuvent comprendre des valeurs éventuelles des paramètres de requête. Dans certains modes de réalisation, les valeurs de référence peuvent par ailleurs comprendre des valeurs équivalentes incluses dans le champ lexical de ces valeurs possibles et/ou des synonymes des valeurs possibles. À l’étape 802, le dispositif de liaison 10 peut appliquer différentes techniques de traitement de données, telles que l’analyse de données, la segmentation de données, le filtrage de données, la provenance des données, etc. en tenant compte de la structure des données de l’application 4 pour déterminer si une valeur de référence correspond à un ou plusieurs éléments de donnée du bloc de données d’entrée et/ou des données auxiliaires.
Si une correspondance entre un élément de donnée et une valeur de référence est identifiée, la valeur de référence est appariée (ou mappée) à l’élément de donnée.
Le procédé peut par ailleurs comprendre la détermination d’une notation élémentaire ETI pour chaque paire élément de donnée/valeur de référence, si un mappage a été trouvé entre l’élément de donnée et la valeur de référence, à l’étape de traitement 802. La notation peut être une valeur déterminée pour la paire {valeur de référence/élément de donnée} et indiquant le niveau de pertinence de la correspondance entre la valeur de référence et l’élément de donnée, plus la valeur de la notation est élevée, meilleure est la pertinence. Si aucun mappage n’est trouvé pour une valeur de référence, une valeur nulle peut être attribuée à la notation.
Par exemple, dans une application de l’invention à la fourniture de voyage, un mappage entre un élément de donnée et une valeur de référence peut être considéré comme pertinent, si :
- la valeur est lexicalement équivalente (par ex. IATA PAR et Paris, France sont équivalents),
- correspond au déplacement pour le voyageur (par ex. aéroport CDG est plus pertinent pour une requête de vol que le code de gare SNCF FRCDG), et
- a un bon rapport confort/coût (par ex. voler jusqu’à CDG au lieu d’ORLY sera plus confortable pour le voyageur et tout coût supplémentaire pour la société, tel qu’un taxi, est justifié).
Chaque paire élément de donnée/valeur de référence peut ainsi être associée à un Indicateur de confiance élémentaire ETI. Une correspondance exacte correspond par exemple à une valeur ETI maximale.
Dans certains modes de réalisation, les données apprises par machines peuvent être utilisées à l’étape 802 pour déterminer ΙΈΤΙ, telles qu’une table de recherche stockant des triplets de données, chaque triplet comprenant un élément de donnée, une valeur de référence et une valeur ETI précalculée pour la paire élément de donnée/valeur de référence.
Si au moins un mappage a été déterminé entre un élément de donnée du bloc de données d’entrée et une valeur de référence avec une valeur ETI non nulle, la valeur du paramètre de requête peut être déduite de la valeur de référence en fonction des notes ETI obtenues pour les différents mappages entre les valeurs de référence correspondant au paramètre de requête et les éléments de donnée. Par exemple, le mappage ayant la notation la plus élevée peut être sélectionné et la valeur du paramètre de requête peut être déduite de la valeur de référence correspondant au mappage sélectionné. La valeur de référence sélectionnée pour générer la valeur du paramètre de requête peut être précédemment convertie en un format ou en une structure de donnée supportée par le système fournisseur de contenu pour ce paramètre de requête.
Si au moins certains paramètres de requête ont été traités, le procédé peut déterminer, si une condition de génération de requête est satisfaite dans les valeurs ETI attribuées à chaque paire valeur de référence/élément de donnée à l’étape 805. Autrement, le processus peut attendre un nouveau bloc de données d’entrée de l’application.
Si la condition de génération de requête de l’étape 805 est satisfaite, une requête peut être générée à l’étape 806, la requête comprenant des valeurs pour au moins certains paramètres de requête, chaque paramètre de requête étant attribué à une valeur déduite de l’élément de donnée apparié à une valeur de référence associée au paramètre de requête en fonction de sa notation ETI associée.
À l’étape 808, la requête peut être envoyée au système fournisseur de contenu 2 par exemple à l’aide d’une URL, si le système fournisseur de contenu est un serveur web.
Si la condition de l’étape 805 n’est pas satisfaite, le procédé peut attendre de poursuivre avec un nouveau bloc de données entré à partir de l’application 4 soit traité. Une erreur peut s’afficher dans l’interface d’application.
La réponse du système fournisseur de contenu 2 à la requête envoyée par le dispositif de liaison 10 peut être affichée dans la zone d’interface 403 de l’interface d’application dédiée à l’extension d’application 41. L’utilisateur peut sélectionner un élément de l’affichage lié à l’exemple le fournisseur de contenu, qui peut déclencher une mise à jour de l’affichage via le dispositif de liaison ou une redirection vers l’interface du système fournisseur de contenu.
Par exemple, considérant l’exemple d’un système fournisseur de voyage 2 fournissant des propositions de voyages en réponse à des requêtes de voyages et une application 2 de type calendrier, le bloc de données d’entrée peut comprendre des éléments de donnée liés à un événement, tels qu’au moins un lieu, des dates et heures de début/fin d’évènement, tandis que les paramètres de requête standards comprennent un lieu, une date, une heure et/ou un lieu de départ, un lieu, une date et/ou une heure d’arrivée.
Dans cet exemple, la valeur d’un paramètre de requête peut être déduite de la valeur de référence en utilisant des règles de calcul comme suit :
- Les paramètres de requête d’heure et de date de départ de la requête peuvent être définis comme la date/heure de début de l’événement (valeurs de référence) moins une valeur prédéfinie (par ex. 24 heures).
- Les paramètres de requête d’heure et de date de retour peuvent être définis comme la date de fin de l’événement (valeur de référence) moins une valeur prédéfinie (par ex. 4 heures).
Dans un autre exemple, les paramètres de requête de date et d’heures de départ peuvent être définis comme la date/heure de début de l’événement (valeur de référence) moins le temps nécessaire pour accéder à l’événement du lieu de départ de l’utilisateur vers le lieu de l’événement, ce qui peut inclure la somme des durées moyennes requises par un utilisateur pour :
- atteindre l’aéroport à partir de votre point de départ (pris dans les données historiques et du profil) ;
- passer le contrôle de sécurité et de vol au point de départ ;
- voler du lieu de départ au lieu d’arrivée ;
- passer le contrôle de sécurité et de vol au point d’arrivée ; et
- atteindre le lieu de l’événement à partir du port d’arrivée (notamment la durée moyenne de location de voiture).
De manière similaire, les paramètres d’heure et de date de retour de la requête peuvent être définis comme la date/heure de fin de l’événement (valeur de référence) plus le temps nécessaire pour que l’utilisateur retourne sur le lieu de l’utilisateur à partir du lieu de l’événement, ce qui peut inclure la somme des durées moyennes requises par un utilisateur pour :
- atteindre l’aéroport à partir du lieu de l’événement (notamment la durée moyenne estimée de retour de location de voiture) ;
- passer le contrôle de sécurité et de vol au point de départ.
Dans un mode de réalisation de l’invention, le dispositif de liaison 10 par ailleurs déclencher la création d’une ou de plusieurs entrées de calendrier ou d’agenda dans l’application, si l’application 4 est une Application de calendrier/d’agenda ou comprend un Outil de calendrier/d’agenda (tel qu’une application de messagerie), et si une requête est générée par le dispositif de liaison 10 et si l’utilisateur valide une proposition de voyage et des services complémentaires possibles fournis par les fournisseurs de contenu auxiliaires via le système fournisseur de contenu (2), par exemple une réservation d’hôtel, une location de voiture dans l’exemple d’un système fournisseur de contenu 2 fournissant des propositions de voyage (système fournisseur de voyage).
Dans l’exemple d’un système fournisseur de voyage 2, considérant l’exemple d’une application 4 comprenant un outil de calendrier ou d’agenda (tel qu’une application de messagerie) comprenant des entrées de calendrier/d’agenda, si un utilisateur réserve une des propositions (de voyage) et des services supplémentaires retournés par le système fournisseur de voyage via le dispositif de liaison 10, le dispositif de liaison peut ainsi créer dynamiquement le calendrier exemplaire, des entrées peuvent être générées pour cet événement de voyage :
- une entrée de rappel pour se diriger vers le port de départ. Un rappel peut être par exemple généré pour inviter l’utilisateur à commencer à se diriger vers l’aéroport. Cet événement peut être généré à un moment prédéfini avant le premier segment dans une liaison (par ex. 2 heures avant le départ du vol). Les données de port pertinentes peuvent être associées aux instructions et conseils ;
- une entrée de rappel de l’enregistrement du vol/train : un tel rappel peut être généré à un moment prédéfini avant le premier segment (par ex. 24 heures avant le premier vol). Le lien d’enregistrement auprès de la compagnie aérienne peut être inclus ainsi que les informations de voyage pertinentes pour faciliter l’enregistrement (par ex. le Numéro de réservation) ;
- une entrée de segments de vol/train : une telle entrée peut indiquer chaque segment d’un voyage d’utilisateur, les heures de départ et de fin du voyage étant celles des segments de vol. Les détails des vols et les informations pertinentes peuvent être inclus (tels que les informations sur le terminal, les informations sur l’aéroport/la gare, la durée, les numéros de vol/train...) ;
- les entrées pour une réservation d’hôtel : deux entrées peuvent être créées pour chaque réservation d’hôtel, une pour l’évènement d’« enregistrement » et une autre pour l’heure de « départ ». Les détails des hôtels et les informations pertinentes peuvent être inclus (par ex. Adresse, infos de réservation...) ;
- les entrées de réservation de location de voiture : deux entrées peuvent être créées pour chaque réservation de location de voiture notamment un évènement de ramassage et un évènement de dépôt. Le détail de location de voiture et les informations pertinentes peuvent être inclus (par ex. prestataire de location de voitures, adresse du lieu de ramassage, informations de réservation, etc.).
Le dispositif de liaison 10 peut par ailleurs créer une ou plusieurs entrées dans une ou plusieurs autres applications s’exécutant sur le dispositif client 3 (différentes de l’application 4), par exemple une application de navigation sociale GPS (GPS signifie positionnement global).
La Figure 8 est un organigramme décrivant le processus de génération d’une requête (étape 808 de la figure 7) selon une autre approche. Au lieu d’attendre une nouvelle entrée de bloc de données, si la condition de génération de requête n’est pas satisfaite à l’étape 805 de la figure 7, le dispositif de liaison 10 peut autrement envoyer un message à l’application 4 afin que l’extension d’application 41 génère l’affichage d’un formulaire de requête invitant l’utilisateur à entrer des valeurs pour certaines valeurs de référence au moins, comme décrit à la Figure 8.
Par conséquent, s’il est déterminé que la condition de génération de requête n’est pas satisfaite sur la base des Indicateurs de confiance élémentaire déterminés pour chaque valeur de référence, à l’étape 8080, une ou plusieurs valeurs de référence R, peuvent être marquées avec une étiquette en fonction de la valeur ETI associés à chaque valeur de référence Rj. Par exemple, les valeurs de références qui sont associées à une valeur ETI plus basse ou égale à une valeur de seuil prédéfini peuvent être marquées à l’étape 8080. Les valeurs de référence marquées peuvent correspondre aux valeurs de référence pour lesquels un mappage a été trouvé avec un élément de donnée du bloc de données d’entrée, mais avec une valeur ETI basse ou pour laquelle aucun mappage n’a été trouvé. Dans certains modes de réalisation, les valeurs de référence pour lesquelles deux ou plusieurs valeurs candidates (mappage d’éléments de donnée) ont été trouvées avec des valeurs ETI égales peuvent être par ailleurs marquées.
À l’étape 8082, le dispositif de liaison 10 peut envoyer un message à l’extension d’application 41 pour générer l’affichage d’un formulaire de requête sur l’interface utilisateur. Le formulaire peut comprendre au moins un champ à compléter par l’utilisateur pour chaque valeur de référence marquée. Dans certains modes de réalisation, le formulaire peut comprendre un champ pour chaque valeur de référence de la requête conformément au format de requête prédéfini, les champs des valeurs de référence marquées étant vides et les champs des autres valeurs de référence étant préremplis avec les éléments de donnée correspondants du bloc de données d’entrée.
Si l’utilisateur entre des valeurs dans le formulaire de l’interface d’application 40 pour les valeurs de référence marquées, les valeurs peuvent être transmises au dispositif de liaison 10.
L’utilisateur peut par ailleurs modifier les autres valeurs de paramètres de requête. Si tel est le cas, les valeurs mises à jour peuvent également être transmises au dispositif de liaison 10 et le dispositif de liaison 10 peut générer la requête sur la base des valeurs mises à jour pour les paramètres de requête au lieu de la valeur déterminée par le dispositif de liaison.
Le procédé de fourniture du contenu peut ensuite traiter l’étape de génération de la requête (808).
II faut noter que dans certains modes de réalisation, le formulaire de requête peut s’afficher dans la zone 403 au lancement de l’extension d’application. Les champs de paramètres de requête peuvent être complétés dynamiquement en réponse aux paires de requête paramètre/valeur retournées par le dispositif de liaison 10. Le dispositif de liaison 10 peut retourner lesdites paires chaque fois qu'une valeur est trouvée pour un paramètre de requête, et même avant que la condition de génération de requête ne soit testée à l’étape 805.
Dans un tel mode de réalisation, l’utilisateur peut mettre à jour les valeurs à tout moment, ladite mise à jour étant transmise au dispositif de liaison qui remplace ensuite la valeur de la requête par la nouvelle valeur précisée par l’utilisateur. Dans des modes de réalisation où un formulaire s’affiche pour permettre à l’utilisateur de fournir une valeur pour les paramètres de requête pour lesquels aucun mappage n’a été trouvé ou de corriger une valeur candidate identifiée par le dispositif de liaison pour chaque paramètre de requête, le dispositif de liaison 10 peut collecter les données de méta-apprentissage provenant des corrections ou des entrées ainsi fournies par l’utilisateur pour le traitement du mappage suivant.
Si deux éléments de donnée ont été mappés à une même valeur de référence et ont une même notation ETI, le dispositif de liaison 10 peut sélectionner arbitrairement l’une d’entre elles ou utiliser les données contextuelles pour sélectionner l’une d’entre elles.
La Figure 9 est organigramme décrivant l’étape de traitement d’un bloc de données, selon un mode de réalisation (étape 802 de la figure 7).
La table de traitement peut être mise en œuvre en réponse à la réception d’un bloc de données de l’application 4 (étape 800 de la figure 7).
À l’étape 8020, le dispositif de liaison 10 peut traiter chaque paramètre de requête.
À l’étape 8021, une liste de valeurs de référence prédéfinies R, correspondant au paramètre de requête peut être analysée. La liste de valeurs de référence prédéfinies R peut avoir été préalablement reçue du système fournisseur de contenu 2 et stockée. Autrement, la valeur de référence R, peut être stocké dans une ou plusieurs bases de données (bases de données publiques et/ou privées). Les valeurs de référence correspondent aux valeurs possibles du paramètre de référence, ou les valeurs qui sont équivalentes ou synonymes auxdites valeurs possibles du paramètre de requête.
À l’étape 8022 chaque valeur de référence R, (bloc 8021), on peut déterminer si un mappage existe entre la valeur de référence R et un élément de donnée du bloc de données d’entrée ou des données auxiliaires en comparant la liste de valeurs de référence associée à la valeur de référence Rs avec les éléments de donnée du bloc de données d’entrée et/ou des données auxiliaires. Dans certains modes de réalisation, un élément de donnée peut être traité uniquement s’il a la même catégorie que le paramètre de requête.
S’il est déterminé qu’un élément de donnée Dk correspond à une valeur de référence associée à la valeur de référence R, (bloc 8023), un Indicateur de confiance élémentaire ETI peut être déterminé pour le mappage entre Ri et Dk à l’étape 8025. Autrement, une valeur nulle peut être attribuée à la valeur de référence à l’étape 8024.
Le traitement des valeurs de référence pour un paramètre de requête de données peut être terminé, si au moins un mappage a été trouvé avec un ETI plus élevé ou égal à un seuil S prédéfini (bloc 8023) à l’étape 8026.
À l’étape 8028, la valeur du paramètre de requête peut être dérivée d’une valeur de référence pour laquelle mappage a été trouvé avec un élément de donnée du bloc de données d’entrée ou des données auxiliaires en fonction de la notation ETI (sélectionnée à l’étape 8026).
Le processus peut ensuite être répété pour certains autres paramètres de requête au moins.
Le processus peut ensuite poursuivre avec l’étape 806 de la figure 7.
La Figure 10 est organigramme décrivant le processus pour déterminer si une condition de génération de requête est satisfaite, selon un mode de réalisation (étape 805 de la figure 7).
Le processus peut ensuite être déclenché, si une correspondance au moins est trouvée pour certains paramètres de requête au moins (bloc 804 de la figure 7).
Le processus peut comprendre la détermination d’un Indicateur de confiance globale (GTI) pour le bloc de données d’entrée, à l’étape 8052, basé sur les Indicateurs de confiance élémentaire ETI déterminés pour les valeurs de référence utilisées pour déduire la valeur de chaque paramètre de requête.
À l’étape 8054, une condition liée à la valeur du GTI peut être déterminée. Par exemple, on peut déterminer si la valeur du GTI est plus basse ou égale à un seuil S prédéfini. Dans un tel mode de réalisation, la condition de génération de requête est ainsi une condition liée au GTI.
Si la condition de l’étape 8054 est satisfaite, une requête peut être générée comme décrit précédemment 806.
Autrement, si la condition de l’étape 8054 n’est pas satisfaite, le processus peut retourner à l’étape 800 comme décrit à la figure 7 ou effectuer l’étape 8080, comme décrit à la figure 8.
Les Figures 11 à 13 montrent des vues successives d’une l’interface d’application exemplaire 40 d’une application de messagerie 4 comprenant un outil de gestion de réunions et connectée à un système fournisseur de voyage 2 via un dispositif de liaison 10. L’utilisateur peut accéder à l’application pour créer une réunion ou ouvrir une réunion existante. Les éléments de donnée saisis par l’utilisateur dans l’application 4 sont structurés comme nom/valeur.
La vue de la figure 11 correspond à une phase initiale du procédé de fourniture de contenu dans lequel l’utilisateur a ouvert l'outil de réunion pour créer un événement. L’outil comprend un ensemble de boîtes incluant des boîtes de participants pour indiquer les participants à la réunion, une boîte objet pour indiquer l’objet de la réunion, une boîte lieu pour indiquer le lieu de la réunion, des boîtes d’heure de début et de fin pour indiquer le début et la fin de la réunion, une boîte de messages de réunion où les informations liées à la réunion peuvent être entrées. Lors de la phase initiale, les boîtes sont toutes vides et l’extension d’application 41 a été automatiquement lancée.
Une zone 700 est dédiée à l’extension d’application 41, l’interface de cette zone change dynamiquement à mesure que l’utilisateur entre des données dans les boîtes. Dans les modes de réalisation des figures 12 et 13, un formulaire de requête s’affiche dans la zone dédiée 403 de l’application d’interface 40 et les champs du formulaire de requête peuvent être dynamiquement complétés suite au traitement effectué par le dispositif de liaison.
Dans l’exemple de la figure 11, l’utilisateur a saisi une date/heure de début et une date/heure de fin dans les boîtes correspondantes de l’outil de réunion. Ces entrées sont passées au dispositif de liaison 10 sous la forme d’un bloc de données d’entrée. Le dispositif de liaison 10 traite ensuite le bloc de données d’entrée et détermine une association entre les éléments de donnée de ce bloc de données d’entrée et un ensemble de valeurs de référence correspondant aux paramètres de requête de voyage standards. Comme indiqué dans la partie gauche de l’interface d’application, les paramètres de requête incluent :
- une date de départ déduite par le dispositif de liaison 10 à partir de la date de début de la réunion ;
- une heure de départ déduite par le dispositif de liaison 10 à partir de l’heure de début de la réunion ;
- une date de retour déduite par le dispositif de liaison 10 à partir de la date de fin de la réunion ;
- une heure de retour déduite par le dispositif de liaison 10 à partir de l’heure de fin de la réunion ;
- un lieu de départ (correspondant au champ « de » de la zone 700) fixé au lieu « SEA » (Seattle) ; le lieu de départ peut être déduit par le dispositif de liaison 10 à partir d’une source auxiliaire telle que le profil utilisateur qui fournit le lieu de l’utilisateur ;
- un lieu d'arrivée (correspondant au champ « à » de la zone 700) fixé au lieu « RDM » (RDM est le code IATA pour Redmond Municipal Airport, dans l’Orégon aux ÉtatsUnis) ; le lieu d’arrivée peut être déduit par le dispositif de liaison 10 des entrées de l’utilisateur puisqu’aucun lieu n’a été indiqué jusqu’ici par l’utilisateur.
Le dispositif de liaison 10 convertit ensuite le format de lieu de départ et d’arrivée dans son nom correspondant dans « l’industrie du voyage » comme défini par le code de la norme IATA (IATA signifie «International Air Transport Association») utilisant une table de mappage qui associe chaque lieu à un lieu standard. Le lieu « SEA » est ainsi converti dans le lieu standard correspondant « PARIS » et le lieu « RDM » est converti dans le lieu standard Heathrow. Le dispositif de liaison 10 génère ainsi la requête en conséquence et envoie la requête générée au système fournisseur de contenu 2 qui retourne le résultat à l'application 4 via le dispositif de liaison 10. L’extension d’application 41 affiche le résultat dans la zone 700 sous forme de propositions de voyage correspondant au lieu.
Bien que la figure 11 illustre un exemple simplifié dans lequel les éléments de donnée de type IATA sont détectés dans le bloc de données d’entrée pour déterminer les paramètres de requête de lieu, l’homme de métier comprendra aisément que l’invention s’applique également aux éléments de donnée qui ne sont pas des normes IATA pour lesdits paramètres de requête, tels que par exemple un élément de donnée « Chambre 345 » qui peut être décodé par le dispositif de liaison 10 dans une entrée pour la requête de voyage (par ex. Chambre 345 qui sera soumis au système de voyage comme Aéroport RDM, dans la mesure où c’est le plus pertinent).
Par conséquent, les actions de l’utilisateur sont traitées de manière transparente pour détecter un besoin de requête de voyage et générer ladite requête dynamiquement dans une zone 403 de l’interface d’application tout en n’interrompant pas l’utilisateur dans son action principale (créer un événement de réunion), sauf s’il dessine de passer à la zone dédiée.
L’utilisateur peut ignorer les résultats affichés dans la zone 403 ou sélectionner une proposition de voyage en pointant sur le bouton « réserver ».
Dans certains modes de réalisation, les résultats de la requête peuvent être affichés dans une fenêtre contextuelle, comme le montre la figure 13 au lieu d’être affichés dans la zone 4903. Dans l’exemple indiqué à la figure 13, la fenêtre contextuelle comprend les propositions de voyage proposées par deux sociétés AIR FRANCE et KLM (AIR FRANCE est une marque de commerce de la SOCIÉTÉ AIR FRANCE ; KLM est une marque de commerce et une marque de KLM. (H.K.) LTD). Dans un mode de réalisation, le dispositif de liaison 10 peut retourner les résultats à l’application 4 avec un drapeau de fiabilité indiquant si les résultats doivent s’afficher dans la zone 700 ou dans une fenêtre contextuelle. Le drapeau de fiabilité peut être calculé par le dispositif de liaison 10 comme une fonction des Indicateurs de confiance élémentaire déterminés pour les valeurs de référence. Le dispositif de liaison 10 peut ainsi attribuer une valeur de drapeau correspondant un affichage de fenêtre contextuelle, si le mappage entre les valeurs de référence et les éléments de donnée à un niveau élevé de fiabilité qui correspond à une probabilité élevée selon laquelle utilisateur a besoin de contenu du système fournisseur de contenu 2.
Faisant maintenant référence à la figure 14, le système fournisseur de contenu 2, le dispositif de liaison 10 et les dispositifs utilisateurs 3, 5 de l’environnement d’exploitation peuvent être mis en œuvre sur un ou plusieurs dispositifs ou systèmes informatiques, désignés collectivement sous le nom d’ordinateur, tel que l’ordinateur 30. L'ordinateur 30 peut inclure un processeur 32, une mémoire 34, un dispositif de mémoire de stockage de masse 36, une interface d’entrée/sortie (I/O) 38 et une interface homme-machine (HMI) 39. L'ordinateur 30 peut aussi être couplé de façon fonctionnelle à une ou plusieurs ressources extérieures 42 via le réseau 6 (qui peut-être le réseau 60, 61 ou 62 par exemple) et/ou l’interface I/O 38. Les ressources externes peuvent inclure, mais sans s’y limiter des serveurs, des bases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau en nuage (cloud), ou toute autre ressource informatique appropriée qui peut être utilisée avec l'ordinateur 30.
Le processeur 32 peut inclure un ou plusieurs dispositifs sélectionnés : des microprocesseurs, des microcontrôleurs, des processeurs de signal numérique, des micro ordinateurs, des unités centrales de traitement, des réseaux de portes programmables, des dispositifs logiques programmables, des machines à état défini, des circuits logiques, des circuits analogiques, des circuits numériques, ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) basé sur des instructions de fonctionnement enregistrées dans la mémoire 34. La mémoire 34 peut inclure un seul dispositif ou une pluralité de dispositifs de mémoire, notamment mais sans s’y limiter, la mémoire à lecture seule (read-only memory (ROM), la mémoire à accès aléatoire (random access memory (RAM), la mémoire volatile, la mémoire non volatile, la mémoire vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, l'antémémoire (cache memory) ou tout autre dispositif capable de stocker des informations. Le dispositif de mémoire de masse 36 peut inclure des dispositifs de stockage de données tels qu'un disque dur, un disque optique, un dérouleur de bande magnétique, un circuit à l'état solide volatile ou non volatile ou tout autre dispositif capable de stocker des informations. Une base de données 44 peut résider sur le dispositif de stockage de mémoire de masse 36, et peut être utilisée pour collecter et organiser les données utilisées par les différents systèmes et modules décrits dans les présentes.
Le processeur 32 peut fonctionner sous le contrôle d'un système d'exploitation 46 qui réside dans la mémoire 34. Le système d'exploitation 46 peut gérer les ressources informatiques de telle façon que le code de programme de l'ordinateur, intégré sous forme d'une ou de plusieurs applications logicielles, telles que l'application 48 qui réside dans la mémoire 34, puisse disposer d'instructions exécutées par le processeur 32. Dans un autre mode de réalisation, le processeur 32 peut exécuter directement l'application 48 ; dans ce cas le système d'exploitation 46 peut être omis. Une ou plusieurs structures de données 50 peuvent également résider dans la mémoire 34, et peuvent être utilisées par le processeur 32, le système d'exploitation 46, et/ou l'application 48 pour stocker ou manipuler des données.
L'interface I/O 38 peut fournir une interface machine qui couple le processeur 32 de façon fonctionnelle avec d'autres dispositifs et systèmes, tels que le réseau 6 et/ou la ressource externe 42. L'application 48 peut ainsi collaborer avec le réseau 6 et/ou avec la ressource externe 42 en communiquant par l'intermédiaire de l'interface I/O 38 pour fournir les diverses caractéristiques, fonctions, applications, processus, et/ou les modules composant les modes de réalisation de l'invention. L'application 48 peut aussi comporter un programme codé qui est exécuté par une ou plusieurs ressources externes 42, ou autrement reposer sur les fonctions et/ou signaux fournis par d'autres composants de système ou de réseau externes à l'ordinateur 30. En effet, au vu des configurations presque infinies de matériel informatique et de logiciel possibles, les hommes de métier comprendront que les modes de réalisation de l'invention peuvent inclure des applications situées à l’extérieur de l’ordinateur 30, distribuées à des ordinateurs multiples ou à d’autres ressources externes 42 ou fournies par des ressources informatiques (matériel et logiciel) qui sont fournies par un service tel qu’un service informatique en nuage, par l’intermédiaire du réseau 6.
Le HMI 39 (tel que le HMI 30 dans la mise en œuvre de la figure 1 du dispositif utilisateur 3) peut être couplé de façon fonctionnelle au processeur 32 de l’ordinateur 30 d’une manière connue pour permettre à un utilisateur de l’ordinateur 30 d’interagir directement avec l’ordinateur 30. Le HMI 39 peut inclure des affichages vidéo et/ou alphanumériques, un écran tactile, un haut-parleur et tout autre indicateur visuel et audio capable de fournir des informations à l’utilisateur. Le HMI 39 peut aussi inclure des dispositifs et des contrôles d’entrée tels qu'un clavier alphanumérique, un dispositif de pointage, des claviers, des boutons poussoir, des boutons de commande, des microphones, etc., capables d'accepter des commandes ou des entrées de l'utilisateur et de les transmettre au processeur 32.
La base de données 44 peut résider sur le dispositif de stockage de mémoire de masse 36, et peut être utilisée pour collecter et organiser les données utilisées par les différents systèmes et modules décrits dans les présentes. La base de données 44 peut inclure des données et accommoder les structures de données qui stockent et organisent les données. En particulier, la base de données 44 peut être aménagée avec toute organisation ou structure de base de données, notamment, mais sans s’y limiter, une base de données relationnelle, une base de données de type hiérarchique, une base de données en réseau, une base de données orientée objet, ou des combinaisons de celles-là. Un système de gestion de base de données sous forme d'application logicielle informatique qui s'exécute sous la forme d'instructions sur le processeur 32 peut être utilisé pour accéder à l'information ou aux données stockées dans des fichiers de la base de données 44 en réponse à une requête, si une requête peut être déterminée de façon dynamique et exécutée par le système d'exploitation 46, les autres applications 48, ou un ou plusieurs modules. Bien que des modes de réalisation de l'invention puissent être décrits dans les présentes en utilisant une terminologie de base de données relationnelle, hiérarchique, de réseau, orientée-objet ou autre terminologie dans des cas spécifiques, les hommes de métier comprendront que les modes de réalisation de l'invention peuvent utiliser tout modèle de gestion de base de données approprié, et ne sont pas limités à un quelconque type particulier de base de données.
Alors que l’invention comporte des avantages particuliers pour les systèmes fournisseurs de contenu que les requêtes de support comprenant au moins certains paramètres de requête liés à une date, une heure et/ou un lieu, tels qu’un système fournisseur de voyage, l’homme de métier comprendra aisément que l’invention n’est pas limitée auxdits systèmes fournisseurs de contenu et peut s’appliquer à différents systèmes fournisseurs de contenu, tel qu’un système de recherche de biens immobiliers.
En général les routines exécutées pour mettre en œuvre les modes de réalisation de l'invention, qu'elles soient mises en œuvre dans le cadre d'un système d'exploitation ou d'une application spécifique, d'un composant, d'un programme, d'un objet, d'un module ou d'une séquence d'instructions, ou même d’un sous-ensemble de ceux-là, peuvent être désignées dans les présentes comme “code de programme informatique” ou simplement “code de programme». Le code de programme comprend typiquement des instructions lisibles par ordinateur qui résident à divers moments dans des dispositifs divers de mémoire et de stockage dans un ordinateur et qui, lorsqu'elles sont lues et exécutées par un ou plusieurs processeurs dans un ordinateur, amènent l’ordinateur à effectuer les opérations nécessaires pour exécuter les opérations et/ou les éléments propres aux aspects variés des modes de réalisation de l'invention. Les instructions d'un programme, lisibles par ordinateur, pour réaliser les opérations des modes de réalisation de l'invention peuvent être, par exemple, le langage d'assemblage, ou encore un code source ou un code objet écrit en combinaison avec un ou plusieurs langages de programmation.
Divers codes de programme décrits dans les présentes peuvent être identifiés, selon l'application dans laquelle ils sont mis en œuvre, dans des modes de réalisation spécifiques de l'invention. Cependant, on remarquera que toute nomenclature d'un programme particulier qui suit est utilisée uniquement par commodité ; ainsi l'invention ne peut être limitée à un seul usage dans toute application spécifique identifiée et/ou sous-entendue par ladite nomenclature. Par ailleurs, au vu du nombre généralement infini de moyens par lesquels les programmes informatiques peuvent être organisés selon des sous-programmes, procédures, procédés, modules, objets, et ainsi de suite, ainsi que les façons variées d'affecter les fonctionnalités d'un programme parmi diverses couches de logiciels qui résident dans un ordinateur typique (par ex., les systèmes d'exploitation, les bibliothèques, les interfaces d'application de programme [API], les applications, les applets, etc.), on notera que les modes de réalisation de l'invention ne sont pas limités à l'organisation spécifique et à l'affectation spécifique des fonctionnalités de programme telles qu'elles sont décrites dans les présentes.
Le code de programme intégré dans l’une quelconque des applications/modules décrits dans les présentes peut être distribué individuellement ou collectivement comme un produit de programme, sous une variété de formes différentes. En particulier, le code de programme peut être distribué en utilisant un médium de stockage lisible par ordinateur, disposant en lui-même d'instructions de programme lisibles par ordinateur permettant à un processeur de réaliser des aspects des modes de réalisation de l'invention.
Les supports de stockage lisibles par ordinateur et qui sont intrinsèquement durables, peuvent inclure des médias tangibles, volatiles et non volatiles, amovibles et non amovibles, mis en œuvre dans toute méthode ou technologie de stockage d’informations, telles que des instructions de programme lisibles par ordinateur, des structures de données, des modules de programme ou autres données. Les supports de stockage lisibles par ordinateur peuvent aussi inclure une mémoire RAM, ROM, EPROM (mémoire à lecture exclusivement, programmable et effaçable), EEPROM (mémoire à lecture exclusivement, programmable et effaçable électriquement), une mémoire flash, ou toute technologie de support solide de mémoire, CD-ROM (disque compact portable doté d'une mémoire à lecture seule) ou tout autre stockage optique, bandes d'enregistrement magnétique, mémoire à disque magnétique ou autres dispositifs de stockage magnétique ou tout autre médium pouvant être utilisé pour stocker l’information désirée et qui peut être lue par un ordinateur. Un support de stockage lisible par ordinateur ne peut être interprété comme des «signaux transitoires» en soi (p. ex., des ondes radio ou d’autres ondes électromagnétiques se propageant à travers un support de transmission telle qu'un guide d'ondes ou des signaux électriques transmis par câble). Les instructions de programme lisibles par ordinateur peuvent être téléchargées sur un ordinateur, un autre type d'appareil de traitement de données programmable ou sur tout autre dispositif de support de stockage lisible par ordinateur ou vers un ordinateur externe ou vers un dispositif de stockage externe via un réseau.
Les instructions de programme lisibles par ordinateur, enregistrées sur un support lisible par ordinateur, peuvent être utilisées pour amener un ordinateur, d'autres types d'appareils programmables de traitement de données ou d'autres dispositifs, à fonctionner d'une façon particulière, de sorte que les instructions stockées sur un support lisible par ordinateur produisent un article de fabrication incluant les instructions qui mettent en œuvre les fonctions, les actions et/ou les opérations précisées dans les organigrammes, diagrammes séquentiels et/ou les diagrammes blocs. Les instructions de programme informatique peuvent être fournies à un ou plusieurs processeurs d'un ordinateur à usage général, un ordinateur dédié ou un autre appareil programmable de traitement de données pour produire une machine, de sorte que les instructions, lorsqu’elles sont exécutées à l'aide d’un ou de plusieurs processeurs, accomplissent une série de calculs à effectuer pour mettre en œuvre les fonctions, actions, et/ou les opérations précisées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs.
Bien que l'invention soit illustrée par une description de divers modes de réalisation et bien que ces modes de réalisation soient décrits de façon très détaillée, le Requêteur n’a pas l’intention de restreindre ou de limiter, de quelque manière que ce soit, l'étendue des revendications jointes à de tels détails. Des avantages supplémentaires et des modifications possibles apparaîtront aisément aux hommes de métier. Par exemple, l’étape de traitement 802 peut être mise en œuvre en utilisant différentes techniques de recherche optimisées pour déterminer l’association entre chaque valeur de référence et un élément de donnée. Par ailleurs, la zone 403 de l’interface d’application 40 peut être dynamiquement ajustée en fonction des données à afficher et/ou des informations reçues par le dispositif de liaison, telles que le drapeau de fiabilité. Tandis que les modes de réalisation des figures 7 à 10 ont été décrits dans un ordre d’étapes particulier, l’homme de métier comprendra aisément que l’invention ne se limite pas à ladite séquence des étapes et que certaines étapes peuvent être mises en œuvre dans un ordre différent. Plus généralement, dans certains autres modes de réalisation, les fonctions, les actions et/ou les opérations précisées dans les organigrammes, les diagrammes séquentiels et/ou les diagrammes blocs peuvent être commandées à nouveau, traitées en série et/ou traitées en même temps conformément aux modes de réalisation de l'invention. De plus, tout organigramme, diagramme séquentiel et/ou diagramme bloc peut inclure plus ou moins de blocs que ceux qui sont illustrés, tout en restant conformément aux modes de réalisation de l'invention.

Claims (11)

  1. REVENDICATIONS
    1. Système pour délivrer dynamiquement du contenu d’un système fournisseur de contenu (2) à un dispositif utilisateur (3), ledit système fournisseur de contenu (2) étant configuré pour délivrer du contenu en réponse à une requête ayant un ou plusieurs formats prédéfinis, le dispositif utilisateur (3) comprenant une application (4) s’exécutant sur le dispositif utilisateur (3), l’application (4) étant associée à une interface d’application, l’application étant configurée pour recevoir des données d’entrée d’au moins un utilisateur via l’interface d’application, lesdites données d’entrée comprenant un ensemble d’éléments de donnée, chaque élément de donnée ayant un type et une valeur, l’application comprenant une extension d’application exécutable, le système comprenant par ailleurs un dispositif de liaison (10), le dispositif de liaison étant configuré pour connecter dynamiquement ladite application (4) audit système fournisseur de contenu (2) pendant l’exécution de l’extension d’application, l’extension d'application étant configurée pour activer une connexion au dispositif de liaison (10), en réponse à la détection d’une condition d’activation, l’application (4) étant configurée pour transmettre au moins certains des éléments de donnée compris dans chaque bloc de données d’entrée au dispositif de liaison (10) pendant la connexion au dispositif de liaison (10), le dispositif de liaison étant configuré pour générer une requête de contenu selon l’un desdits formats de requête prédéfinis en utilisant lesdits éléments de donnée reçus de l’application (4) et pour transmettre ladite requête au système fournisseur de contenu (2).
  2. 2. Système selon la revendication 1 dans lequel le dispositif de liaison comprend :
    - un analyseur (11) configuré pour analyser un ensemble de valeurs de référence pour chaque paramètre de requête, en réponse à la réception d’un bloc de données d’entrée ;
    - un mappeur(13) configuré pour déterminer si au moins certaines valeurs de référence dudit ensemble de valeurs de référence mappe un élément de donnée dans le bloc de données d’entrée ou dans une ou plusieurs sources auxiliaires, le mappeur étant par ailleurs configuré pour associer une notation élémentaire à chaque élément de donnée mappant une valeur de référence.
  3. 3. Système selon la revendication 2, dans lequel chaque valeur de référence peut être associée à une liste de valeurs auxiliaires et dans lequel le mappeur (13) est configuré pour déterminer un mappage entre une valeur de référence et un élément de donnée dans ledit bloc de données d’entrée ou dans une ou plusieurs sources auxiliaires, si l’élément de donnée dans ledit bloc de données d’entrée ou dans une ou plusieurs sources auxiliaires mappe l’une desdites valeurs auxiliaires.
  4. 4. Système selon l’une quelconque des revendications précédentes 2 ou 3 dans lequel le dispositif de liaison (10) comprend :
    - un générateur de requêtes configuré pour générer une requête de contenu basée sur les notations élémentaires associées aux éléments de donnée mappant lesdites valeurs de référence, la requête comprenant des paramètres de requête, chaque paramètre de requêtes étant associé à une ou plusieurs valeurs de référence, la valeur d’au moins un paramètre de requête étant déduite d’une valeur de référence mappée sur un élément de donnée et associée audit paramètre de requête en fonction de la notation déterminée pour ladite valeur de référence ;
    le dispositif de liaison (10) étant par ailleurs configuré pour envoyer ladite requête au système fournisseur de contenu (2).
  5. 5. Système selon la revendication 4, dans lequel la valeur d’un paramètre de requête est déterminée à partir de la valeur de référence ayant la notation la plus élevée.
  6. 6. Système selon la revendication 5, dans lequel le dispositif de liaison est configuré pour déterminer la valeur dudit paramètre de requête en utilisant une fonction définissant une relation entre la valeur du paramètre de requête et ladite valeur de référence.
  7. 7. Système selon l’une quelconque des revendications précédentes 2 à 6, dans lequel le dispositif de liaison comprend par ailleurs un convertisseur (140) configuré pour convertir le format d’une valeur de référence dans le format du paramètre de requête associé à la valeur de référence.
  8. 8. Système selon l’une quelconque des revendications précédentes, dans lequel ladite application (4) est associée à une mémoire de données (400) configurée pour stocker lesdits éléments de donnée.
  9. 9. Système selon l’une quelconque des revendications précédentes, dans lequel ladite application (4) comprend une mémoire de données utilisateur (35) configurée pour stocker un identifiant utilisateur, l’extension d’application étant configurée pour transmettre, de manière transparente et sécurisée, ledit identifiant utilisateur audit dispositif de liaison (10), ledit dispositif de liaison (10) étant configuré pour contrôler l’accès dudit utilisateur au système fournisseur de contenu (2) en utilisant ledit identifiant utilisateur.
  10. 10. Système selon l’une quelconque des revendications précédentes, dans lequel le dispositif de liaison (10) est configuré pour recevoir le contenu du système fournisseur de contenu (10)
    5 en réponse à ladite requête, le dispositif de liaison (10) étant configuré pour transmettre ledit contenu à l’application, l’application comprenant une unité de rendu pour produire un rendu dudit contenu dans une zone dédiée (403) de l’interface d’application (40).
  11. 11. Système selon la revendication (10), dans lequel l’unité de rendu (30) est configurée pour ajuster dynamiquement les dimensions de l’application (4) en fonction du contenu transmis par
    10 le dispositif de liaison.
FR1756718A 2017-07-13 2017-07-13 Systeme et procede pour delivrer dynamiquement du contenu Active FR3069076B1 (fr)

Priority Applications (8)

Application Number Priority Date Filing Date Title
FR1756718A FR3069076B1 (fr) 2017-07-13 2017-07-13 Systeme et procede pour delivrer dynamiquement du contenu
PCT/EP2018/068374 WO2019011805A1 (fr) 2017-07-13 2018-07-06 Système et procédé de distribution dynamique de contenu
ES18734844T ES2926005T3 (es) 2017-07-13 2018-07-06 Sistema y método para entregar contenido dinámicamente
EP22177327.8A EP4071637A1 (fr) 2017-07-13 2018-07-06 Système et procédé de remise de contenu dynamique
US16/629,465 US11068321B2 (en) 2017-07-13 2018-07-06 System and method for dynamically delivering content
AU2018299827A AU2018299827B2 (en) 2017-07-13 2018-07-06 System and method for dynamically delivering content
CN201880053650.9A CN111034157B (zh) 2017-07-13 2018-07-06 用于动态投递内容的***和方法
EP18734844.6A EP3652918B1 (fr) 2017-07-13 2018-07-06 Système et procédé de distribution dynamique de contenu

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1756718 2017-07-13
FR1756718A FR3069076B1 (fr) 2017-07-13 2017-07-13 Systeme et procede pour delivrer dynamiquement du contenu

Publications (2)

Publication Number Publication Date
FR3069076A1 true FR3069076A1 (fr) 2019-01-18
FR3069076B1 FR3069076B1 (fr) 2021-02-19

Family

ID=62091936

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1756718A Active FR3069076B1 (fr) 2017-07-13 2017-07-13 Systeme et procede pour delivrer dynamiquement du contenu

Country Status (7)

Country Link
US (1) US11068321B2 (fr)
EP (2) EP4071637A1 (fr)
CN (1) CN111034157B (fr)
AU (1) AU2018299827B2 (fr)
ES (1) ES2926005T3 (fr)
FR (1) FR3069076B1 (fr)
WO (1) WO2019011805A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3809345A1 (fr) * 2019-10-18 2021-04-21 Amadeus S.A.S. Dispositif, système et procédé d'intermédiation entre un système de fournisseur qui fournit des objets de fournisseur et un dispositif client
FR3102280A1 (fr) * 2019-10-18 2021-04-23 Amadeus S.A.S. Dispositif, système et procédé pour une intermédiation entre un système de fournisseur qui fournit des objets de fournisseur et un dispositif client
US11276094B2 (en) 2019-10-18 2022-03-15 Amadeus S.A.S. Device, system and method for intermediation between a provider system that provides provider objects and a client device

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
USD947224S1 (en) * 2020-03-09 2022-03-29 Smartnomad Display screen or portion thereof with animated graphical user interface

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020032589A1 (en) * 2000-09-13 2002-03-14 Infospace, Inc. System and method for providing an advanced personal information manager
US20030023463A1 (en) * 2001-04-16 2003-01-30 Frank Dombroski Method and system for automatically planning, booking, and calendaring travel arrangements
US20080201178A1 (en) * 2007-02-20 2008-08-21 Yuri Vizitei On-demand travel management service and platform
US20130046788A1 (en) * 2011-08-16 2013-02-21 Adam Julian Goldstein Calendar-based suggestion of a travel option
US20150371155A1 (en) * 2014-06-24 2015-12-24 Philippe Saint-Just Method, compupter program, and system for planning, reserving, and purchasing travel accommodations from calendar events
US20170068551A1 (en) * 2015-09-04 2017-03-09 Vishal Vadodaria Intelli-voyage travel

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4533092B2 (ja) * 2003-12-11 2010-08-25 キヤノン株式会社 テレビジョン放送受信装置及びテレビジョン放送受信装置の制御方法
US20060080321A1 (en) * 2004-09-22 2006-04-13 Whenu.Com, Inc. System and method for processing requests for contextual information
US8631137B2 (en) * 2008-06-27 2014-01-14 Sony Corporation Bridge between digital living network alliance (DLNA) protocol and web protocol
JP5488180B2 (ja) * 2010-04-30 2014-05-14 ソニー株式会社 コンテンツ再生装置、制御情報提供サーバ、及びコンテンツ再生システム
SG176405A1 (en) * 2010-05-27 2011-12-29 Global Blue Holdings Ab Method and application for location-based services
WO2012127484A1 (fr) * 2011-03-24 2012-09-27 Yogesh Chunilal Rathod Système et procédé permettant de gérer, contrôler, suivre, mettre à jour, mesurer et faciliter le maintien du statut et de l'état d'un utilisateur
AU2014251347B2 (en) * 2013-03-15 2017-05-18 Apple Inc. Context-sensitive handling of interruptions
EP3176736A1 (fr) * 2015-12-04 2017-06-07 Nextop Italia SRL Semplificata Système électronique et procédé de planification de voyage, basé sur la technologie orientée objet

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020032589A1 (en) * 2000-09-13 2002-03-14 Infospace, Inc. System and method for providing an advanced personal information manager
US20030023463A1 (en) * 2001-04-16 2003-01-30 Frank Dombroski Method and system for automatically planning, booking, and calendaring travel arrangements
US20080201178A1 (en) * 2007-02-20 2008-08-21 Yuri Vizitei On-demand travel management service and platform
US20130046788A1 (en) * 2011-08-16 2013-02-21 Adam Julian Goldstein Calendar-based suggestion of a travel option
US20150371155A1 (en) * 2014-06-24 2015-12-24 Philippe Saint-Just Method, compupter program, and system for planning, reserving, and purchasing travel accommodations from calendar events
US20170068551A1 (en) * 2015-09-04 2017-03-09 Vishal Vadodaria Intelli-voyage travel

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3809345A1 (fr) * 2019-10-18 2021-04-21 Amadeus S.A.S. Dispositif, système et procédé d'intermédiation entre un système de fournisseur qui fournit des objets de fournisseur et un dispositif client
FR3102280A1 (fr) * 2019-10-18 2021-04-23 Amadeus S.A.S. Dispositif, système et procédé pour une intermédiation entre un système de fournisseur qui fournit des objets de fournisseur et un dispositif client
US11276094B2 (en) 2019-10-18 2022-03-15 Amadeus S.A.S. Device, system and method for intermediation between a provider system that provides provider objects and a client device

Also Published As

Publication number Publication date
US20210133006A1 (en) 2021-05-06
AU2018299827B2 (en) 2021-05-13
WO2019011805A1 (fr) 2019-01-17
ES2926005T3 (es) 2022-10-21
EP3652918A1 (fr) 2020-05-20
EP4071637A1 (fr) 2022-10-12
CN111034157A (zh) 2020-04-17
AU2018299827A1 (en) 2020-02-06
US11068321B2 (en) 2021-07-20
EP3652918B1 (fr) 2022-06-22
FR3069076B1 (fr) 2021-02-19
CN111034157B (zh) 2023-04-07

Similar Documents

Publication Publication Date Title
US20190354901A1 (en) Distributing a user interface for accessing files
US11178010B2 (en) Personalized machine learning model management and deployment on edge devices
FR3069076A1 (fr) Systeme et procede pour delivrer dynamiquement du contenu
US20190171977A1 (en) Using Machine Learning System to Dynamically Process Events
US20210218784A1 (en) Determining a communication channel for a meeting
FR3090926A1 (fr) Procédé et système autoadaptatif d’agrégation de sources de données
US20180276287A1 (en) Generating contextual insights from deployed applications in multiple computing devices
FR3084947A1 (fr) Systèmes et procédés de contrôle des mises à jour des données de réservation
US20230101037A1 (en) Determining optimized parking based on user preferences
US11681895B2 (en) Cognitive assistant with recommendation capability
US10949818B2 (en) Intelligent payment link
US10664328B2 (en) Calendar entry creation by interaction with map application
US20160012495A1 (en) Soliciting customer feedback based on indoor positioning system detection of physical customer presence
US10650353B2 (en) Context oriented assessment for travel companionship
US11733957B2 (en) Real time sharing of relevant information in virtual meetings
US11289076B2 (en) Assisting meeting participants via conversation loop detection and resolution using conversation visual representations and time-related topic usage
US11593411B2 (en) Historical augmentation of electronic maps
US11133099B2 (en) Memory recall assistance for memory loss
US20210056615A1 (en) Enhanced shopping using mobile devices and micro-location data for in-store item pick-up by a trusted contact
US12014617B2 (en) Contextual item discovery and pattern inculcated reminder mechanism
FR3070781A1 (fr) Identifiants bases sur une interrogation pour le suivi de reponses de sessions croisees
US11118931B2 (en) Enhanced endpoint directions in a mapping program
US20230412654A1 (en) Coordinating knowledge from visual collaboration elements
US11288634B1 (en) Resource management system
FR3079040A1 (fr) Systeme et procede de fourniture de produits

Legal Events

Date Code Title Description
PLSC Publication of the preliminary search report

Effective date: 20190118

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7