Brevet FR3051932A1 — publié le 20171201

Arrière-plan de l'invention La présente invention se situe dans le domaine général des logiciels de navigation ou navigateurs, et trouve une application privilégiée mais non limitative dans le domaine des navigateurs Web (« Web Browsers » en anglais). Elle concerne plus particulièrement l'utilisation de services applicatifs dans un navigateur. Ces services applicatifs sont également appelés services en ligne. Les navigateurs permettent actuellement à leurs utilisateurs d'accéder à des services applicatifs fournis par des tiers, par exemple des entreprises. Les fonctions principales de ces tiers ou ces entreprises sont l'hébergement, la gestion et la maintenance de logiciels, par exemple au sein de serveurs, ces logiciels permettant de fournir à des terminaux d'utilisateurs les services en question. Ces services applicatifs peuvent être accessibles dans des pages de navigateurs, ces derniers étant installés sur ces terminaux. L'accès à de tels service peut nécessiter un abonnement et/ou une identification des utilisateurs. Ces services peuvent par exemple consister en des services disponibles sur Internet, des services de mise en relation, par exemple téléphonique ou visiophonique, des services de traduction de contenu, des services de messagerie, des services d'analyse antivirale, etc. Actuellement, l'accès aux services en ligne dans un navigateur présente certaines difficultés. En effet, il n'existe à ce jour pas de technique permettant d'accéder de manière simple, rapide et efficace à un ou plusieurs services applicatifs ou services en ligne à partir d'une page quelconque d'un navigateur. La présente invention propose de répondre notamment à ce problème et vise, de manière générale, à améliorer l'accès à un service dans un navigateur. Objet et résumé, de l'invention A cet effet, la présente invention propose un mécanisme permettant, à partir d'un type de donnée présent dans une page quelconque d'un navigateur, par exemple un numéro de téléphone (contact, SAV, annuaire, etc.), d'invoquer un service applicatif ou service en ligne prenant en entrée ce type de donnée, par exemple un service de téléphonie. Plus spécifiquement et selon un premier aspect, l'invention concerne un procédé d'invocation dans un terminal d'un service applicatif par un navigateur, ce procédé comportant : - une étape de détection, dans une première page chargée dans le navigateur, d'une donnée d'invocation conforme à un type de donnée d'invocation enregistré pour le service applicatif ; et - une étape d'invocation, dans cette première page chargée, de ce service à partir de cette donnée d'invocation détectée. 3051932 2 Corrélativement, l'invention concerne un terminal permettant l'invocation d'un service applicatif par un navigateur, ce terminal comportant : - un module de détection, dans une première page chargée dans le navigateur, d'une donnée d'invocation conforme au type de donnée d'invocation enregistré pour le 5 service applicatif, par exemple en association avec un identifiant du service ; et - un module d'invocation, dans la première page chargée, de ce service à partir de cette donnée d'invocation détectée. Un navigateur est un logiciel mis en oeuvre dans un terminal et permettant de consulter et d'afficher un contenu provenant d'un réseau auquel est connecté ce terminal. 10 Dans le cas particulier d'un navigateur Web et d'un terminal relié à Internet, ce contenu est un contenu Internet. A titre d'alternative, le terminal est relié à un réseau Intranet ou un réseau privé. Le navigateur charge et éventuellement affiche sur une interface du terminal une ou plusieurs pages, chacune de ces pages comportant, au sens de l'invention, un ensemble de 15 données de page, ces données étant fournies par le réseau. Dans un mode de réalisation particulier, ces données de page comporte : - une description HTML (« HyperText Markup Language ») permettant de structurer et mettre en forme les pages lors de leurs chargements dans le navigateur ; des fonctions en langage de programmation « Javascript » pouvant être appelées dans 20 la description HTML ; et - d'autres données, par exemple des données multimédias, pouvant être également appelées dans la description HTML, par exemple des images à afficher. Une page est dite chargée lorsque le navigateur finit d'interpréter la description HTML qui lui est associée. 25 Une page d'un navigateur peut proposer un service applicatif ou service en ligne, en d'autres mots un service accessible via le réseau auquel est connecté le terminal. En d'autres termes, au sens de l'invention, un service applicatif est un service fourni directement par une page du navigateur et ne nécessitant donc aucune installation logicielle spécifique. 30 Un service applicatif peut comporter différentes fonctions. Par exemple, un service de téléphonie peut proposer une fonction d'appel, mais également d'autres fonctions, comme par exemple la gestion d'une liste de contacts ou d'un agenda. Un service applicatif est caractérisé par le ou les types de données qu'il est capable de traiter ou d'utiliser, c'est à dire par les données qu'il peut prendre en entrée. 35 Au sens de l'invention, les données d'entrée du service sont appelées données d'invocation puisqu'elles peuvent être utilisées pour invoquer ce service. On parle alors également de types de données d'invocation. 3051932 3 L'invocation d'un service applicatif correspond au moment où le service est rendu utilisable pour un utilisateur. Par exemple, l'invocation du service peut correspondre à l'instant où l'utilisateur commence à utiliser l'une de ses fonctions. L'invocation du service correspond donc au déclenchement de son exécution. 5 Ainsi, l'invention permet avantageusement d'invoquer, dans une page quelconque du navigateur, un service applicatif à partir d'une donnée d'invocation présente dans cette page et dont le type est conforme au type de donnée que ce service applicatif peut utiliser. En particulier, l'invention ne nécessite pas une installation d'un logiciel fournissant ce service, mais simplement de connaître le type de donnée utilisable par le service applicatif ou 10 service en ligne et de détecter ce type de donnée dans une page chargée du navigateur. Dans un mode particulier de réalisation, ce procédé comporte, préalablement à l'étape de détection d'une donnée d'invocation, une étape d'enregistrement du type de donnée d'invocation pour le service invoqué. Dans un mode particulier de réalisation, ce procédé comporte, préalablement à l'étape de 15 détection d'un donnée d'invocation, une étape de réception d'une première instruction définissant une deuxième page fournissant le service, cette première instruction définissant le type de donnée d'invocation associé à ce service. Cette première instruction permet à la fois de proposer le service à l'utilisateur dans une page du navigateur, mais également de définir le type de donnée d'invocation utilisable par ce 20 service. Cette première instruction peut être comprise dans l'ensemble des données de page associé à cette deuxième page fournissant le service et tel que décrit précédemment. Avantageusement, cette première instruction peut être envoyée simultanément à ces données de page. 25 Elle peut donc éventuellement faire l'objet d'une « normalisation » auprès des fournisseurs de services, ces derniers ayant simplement à ajouter cette première instruction ainsi « normalisée » à l'ensemble de données de page envoyé au terminal pour permettre à n'importe quel navigateur mettant en oeuvre l'invention d'enregistrer les types de donnée d'invocation utilisables par ces services. 30 Dans un mode particulier de réalisation, ce type de donnée d'invocation est enregistré dans une table du terminal. Dans un mode particulier de réalisation, l'étape de détection comporte : une étape d'identification de données d'invocation présentes dans la première page chargée ; et 35 une étape de détermination pour déterminer, pour une donnée d'invocation identifiée, si cette donnée est conforme au type de donnée d'invocation enregistrée. 3051932 4 Dans un mode particulier de réalisation, lors de l'étape d'identification, la donnée d'invocation est identifiée en réponse à une commande d'un utilisateur reçue par le navigateur. Ainsi, cette donnée d'invocation est par exemple sélectionnée par l'utilisateur avant qu'il soit déterminé si cette donnée est conforme au type de donnée d'invocation associé au service 5 applicatif. Dans un mode particulier de réalisation, l'étape de détection comporte l'une parmi : - une étape d'analyse sémantique de la première page chargée ; et - une étape de détection d'un marqueur codé dans cette première page en association avec les données d'invocation. 10 Dans un mode particulier de réalisation, la première instruction définit une adresse réseau pointant vers une troisième page, l'étape d'invocation comporte une étape de déclenchement du chargement de cette troisième page à partir de cette adresse, et le procédé comporte une étape d'exécution du service dans cette troisième page. De manière avantageuse, le service applicatif est invoqué au sein de la deuxième page, mais 15 le service s'exécute dans une troisième page dont le chargement est déclenché au moment de l'invocation. La manière de définir cette adresse réseau peut faire l'objet d'une « normalisation » auprès des fournisseurs de services. N'importe quel fournisseur d'un service peut simplement ajouter une instruction 20 « normalisée » permettant de définir cette adresse réseau à l'ensemble de données de page associée à la deuxième page fournissant le service pour permettre à n'importe quel navigateur mettant en oeuvre l'invention d'invoquer ce service dans cette troisième page différente de la deuxième page. Dans un mode particulier de réalisation, lors de l'étape de détection, la deuxième page 25 proposant le service n'est pas chargée dans le navigateur. Avantageusement, un utilisateur peut invoquer le service applicatif sans avoir à charger juste avant la page proposant ce service. Dans un mode particulier de réalisation : - la première instruction définit une fonction d'invocation du service ; 30 - l'étape d'invocation comporte une étape d'invocation de cette fonction ; et l'étape d'exécution du service dans la troisième page comporte l'exécution de cette fonction. Dans un mode particulier de réalisation, l'exécution de cette fonction cause l'affichage, dans la première page chargée, d'une unité de commande accessible par un utilisateur pour contrôler le 35 service invoqué lors de son exécution dans la troisième page. Avantageusement, l'utilisateur peut contrôler le service dans la première page sans avoir à accéder à la troisième page exécutant le service. Dans un mode particulier de réalisation, l'étape d'invocation est effectuée : 3051932 5 - automatiquement, en réponse à l'étape de détection d'une donnée d'invocation dans la première page chargée ; ou en réponse à une commande d'un utilisateur. Dans un mode particulier de réalisation, le procédé comporte une étape de déclenchement 5 de la fourniture d'une notification indiquant l'accessibilité, dans la première page, du service applicatif. L'utilisateur est alors notifié de l'accessibilité du service. Dans un mode particulier de réalisation, lors de l'étape de déclenchement, le navigateur fournit la notification. 10 Dans un mode particulier de réalisation, lors de l'étape de déclenchement, le navigateur affiche la notification dans la première page chargée. Dans un mode particulier de réalisation, l'étape de déclenchement comporte une étape d'envoi d'une commande, vers un dispositif, causant la fourniture de cette notification par ce dispositif. 15 Dans un mode particulier de réalisation, ce dispositif peut consister en un quelconque parmi - le terminal mettant en oeuvre le procédé ; et - un dispositif externe à ce terminal. Par conséquent, la fourniture de cette notification peut être effectuée soit par le navigateur, 20 soit sur le terminal, mais via un logiciel différent du navigateur, soit sur un dispositif connecté à ce terminal. Dans un mode particulier de réalisation, le type de donnée d'invocation correspond à l'un quelconque parmi : un numéro de téléphone ; 25 - une adresse postale ; - une adresse mail ; une donnée multimédia ; et - un URL (pour « Uniform Resource Locator » en anglais). Dans un mode particulier de réalisation, les différentes étapes du procédé d'invocation d'un 30 service applicatif par un navigateur sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre par un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre du procédé d'invocation d'un 35 service applicatif par un navigateur tel que mentionné ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. 3051932 6 L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par 5 exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau 10 de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. 15 Brève description des figures D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit, faite en référence aux dessins annexés dans lesquels : - la figure 1 représente un terminal conforme à l'invention permettant 20 l'invocation d'un service applicatif et communicant avec un serveur distant ; la figure 2 représente un terminal conforme à l'invention ; la figure 3 représente les étapes principales d'un procédé d'invocation conforme à l'invention ; - la figure 4 représente un mode de réalisation particulier d'un procédé 25 d'invocation de services applicatifs conforme à l'invention ; - la figure 5 représente un vision schématique de l'étape de réception d'une première instruction, cette étape étant comprise dans un procédé conforme à l'invention ; la figure 6 représente un mode de réalisation particulier d'un procédé 30 conforme à l'invention ; - la figure 7 représente un vision schématique de l'étape de fourniture d'une notification, cette étape étant comprise dans un procédé conforme à l'invention les figures 8 et 9 représentent deux modes de réalisation particuliers d'un 35 procédé conforme à l'invention ; - la figure 10 représente une table dans laquelle sont enregistrées des types de donnée d'invocation associés à des services ; et - les figures 11 à 17 représentent des pages chargées dans un navigateur. 3051932 7 Description détaillée de modes de réalisation La figure 1 représente un terminal T conforme à l'invention, en communication avec un 5 serveur distant SERV fournissant un service Si. Ce terminal T met en oeuvre les différentes étapes d'un procédé d'invocation d'un service applicatif telles que décrites en référence aux figures 3 à 9. Ce terminal T peut consister par exemple en un ordinateur, un téléphone, un téléphone intelligent (ou « Smartphone » en anglais), une tablette ou un quelconque objet connecté. 10 Dans le mode de réalisation décrit ici, le terminal T possède l'architecture matérielle d'un ordinateur. Ainsi, le terminal T comporte un processeur 10, une mémoire 11 de type ROM (pour « Readonly memory » en anglais), une mémoire non volatile réinscriptible 12 (de type Flash par exemple), une mémoire vive de type RAM (pour « Random-access memory », en anglais) 13 et un 15 module COM de communication. La mémoire non volatile 12 du terminal T constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 10 et sur lequel est enregistré un navigateur NAV permettant de charger une ou plusieurs pages, par exemple une page fournissant le service S1 et dont les données associées DATA sont reçues depuis le serveur distant SERV et envoyées par un premier 20 module ENVOI de ce serveur. Comme expliqué précédemment, les données de page DATA associées à la page fournissant le service Si peuvent comporter : - une description HTML (« HyperText Markup Language ») permettant de structurer et mettre en forme la page fournissant le service S1 lors de son chargement dans un 25 navigateur ; des fonctions en langage de programmation « Javascript » pouvant être appelée dans la description HTML ; et - d'autres données, par exemple des données multimédias, pouvant être également appelées dans la description HTML, par exemple des images à afficher. 30 Le format et la structure des données de page DATA peuvent toutefois varier selon l'exemple de réalisation considéré. Ces données de pages DATA peuvent en outre être traitées par le terminal T pour charger dans le navigateur NAV la page fournissant le service Si, mais également pour invoquer le service S1 dans une autre page, différente de celle proposant initialement le service S1 et comme il sera 35 décrit ultérieurement. La mémoire non volatile 12 du terminal T comporte également une table TAB, dont le contenu sera détaillé en référence à la figure 11, et comportant en outre un ou des types de données TY1 que le service S1 est apte à traiter. 3051932 8 Le serveur distant SERV comporte également un second module INSER permettant d'insérer dans ces données de page DATA, ou d'envoyer de manière séparée, au moins un type de données TY1 utilisable par le service Si. Le serveur distant SERV est géré par un fournisseur du service S1 et comporte un logiciel 5 non représenté permettant de fournir ce service S1 au terminal T. A noter que, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité. La figure 2 représente le terminal T de la figure 1 selon un mode de réalisation particulier. 10 Le terminal T met en oeuvre un navigateur NAV configuré pour invoquer un service applicatif. Le terminal T comporte un module DET permettant de détecter, dans une première page chargée dans le navigateur NAV, une donnée d'invocation conforme à un type TY1 de donnée enregistré pour ce service applicatif. Le terminal T comporte aussi un module INV permettant d'invoquer, dans cette première 15 page chargée, ce service à partir de cette donnée d'invocation. Le terminal T comporte également un support d'information SUP dans lequel est stocké un programme PG, tous deux conformes à l'invention, le programme PG comportant des instructions pour l'exécution des étapes d'un procédé d'invocation d'un service applicatif conforme à l'invention, dont les étapes seront détaillées en référence aux figures 3 à 9. 20 Dans un mode particulier de réalisation, le terminal T comporte également un module ENR non représenté permettant d'enregistrer le type de donnée d'invocation associé avec le service, par exemple dans la table TAB. La figure 3 représente un procédé général d'invocation d'un service applicatif S1 conforme à l'invention. 25 Ce procédé peut être mis en oeuvre par un terminal T tel que décrit en référence aux figures 1 ou 2. Le service applicatif S1 peut par exemple consister en un service disponible sur Internet, un service de mise en relation comme par exemple un service téléphonique ou visiophonique, un service de navigation, etc. 30 Ce procédé comporte une première étape E40 de détection, dans un première page chargée (notée ici TAB2) dans le navigateur NAV, d'une donnée d'invocation DN conforme à un type de donnée d'invocation TY1 enregistré en association avec le service Si. Ce type de donnée d'invocation TY1 correspond au type de donnée utilisable par le service Si. 35 Par exemple, en référence à la figure 12, une première page TAB2 est chargée dans le navigateur NAV et affiche la page Internet d'un restaurant. 3051932 9 Dans ce mode de réalisation, la donnée d'invocation DN correspond au numéro de téléphone du restaurant visible sur la page chargée . La donnée d'invocation DN est contenue dans les données associées à la page chargée TAB2. Plus précisément, cette donnée d'invocation DN peut être contenue dans la description 5 HTML associée à la page chargée TAB2 et reçue depuis le serveur distant SERV. Une description HTML générale de la première page chargée TAB2 représentée à la figure 12 pourrait présenter une structure de ce type (numéros de ligne ajoutés) : 1 10 2 `http://www.exemple/image/assiette.png' 3 RESTAURANT 4 BOOK AT : 5 + 33 122 333 455 6 15 Ici, la donnée DN correspondant au numéro de téléphone est détectable à la ligne 5 de cette description HTML, entre les balises et , ces balises indiquant par ailleurs ici explicitement le type de donnée TY1 utilisé (« phone » en anglais correspondant au type de donnée « téléphone »). 20 Ce type de donnée d'invocation TY1 est enregistré, par exemple dans la table TAB stockée dans le terminal T, en association avec un identifiant du service S1. Un exemple de table TAB est représenté plus précisément à la figure 10. Ce type de donnée d'invocation TY1 peut également être associé dans la table TAB à un identifiant HOME permettant de le différencier d'un autre type de donnée ou d'un même type de 25 donnée associé à un autre service. Enfin, ce type de donnée d'invocation TY1 peut être associé, dans la table TAB, à des données (URL dans cet exemple) définissant la méthode d'invocation MI mise en oeuvre par le navigateur NAV pour invoquer le service S1. Dans ce mode de réalisation, la méthode d'invocation correspond à la méthode dite « URL », 30 qui sera détaillée par la suite. L'étape E40 de détection est suivie d'une étape E60 d'invocation, dans la première page chargée TAB2, du service S1 à partir de cette donnée d'invocation DN, correspondant dans le mode de réalisation décrit ici au numéro de téléphone « +33 122 334 455 ». Ainsi, si le service S1 propose par exemple un service de mise en relation comme un service 35 de téléphonie, la donnée d'invocation détectée DN correspondant à un numéro de téléphone peut être utilisée comme variable d'entrée du service de téléphonie S1. 3051932 10 Ce service est alors invoqué dans la première page chargée TAB2, par exemple sous l'action de l'utilisateur, puis éventuellement contrôlable dans cette même page chargée TAB2, par exemple au moyen d'une unité de commande UNIT, tel qu'illustré en référence à la figure 13. Dans ce mode de réalisation, un utilisateur du terminal T pourra, directement sur la 5 première page chargée TAB2 du navigateur NAV correspondant au site du restaurant, accéder au service de téléphonie S1 pour appeler le restaurant dont le numéro s'affiche dans cette première page chargée TAB2. Dans ce mode de réalisation, l'invocation du service S1 correspond par exemple au déclenchement de la fonction « appel » du service, permettant d'appeler un numéro. 10 Le service S1 invoqué sera exécuté dans une troisième page TAB1' chargée au moment de l'invocation et représentée en référence à la figure 14. La page TAB1' exécute ici la fonction « appel » du service de téléphonie Si. Cette page TAB1' peut consister en une mise à jour de la page TAB1 proposant le service S1, précédemment chargée. 15 En variante, la page TAB1 proposant le service S1 n'est pas chargée initialement et le chargement de cette page TAB1' est déclenché dans le navigateur NAV au moment de l'étape d'invocation et ne constitue donc pas une mise à jour. Dans le cas où une unité de commande UNIT permettant de contrôler le service, ajoutée par le navigateur NAV, est affichée dans la première page TAB2, l'utilisateur pourra tout de même 20 consulter cette troisième page TAB1' s'il souhaite utiliser des fonctions du service non disponible via l'unité de commande UNIT, par exemple consulter son agenda ou sa liste de contact. Dans ce mode de réalisation, la page TAB1' exécutant le service S1 et la page TAB2 permettant de contrôler le service S1 interagissent, de manière avantageuse pour l'utilisateur qui peut choisir de rester sur la première page TAB2 ou de consulter l'autre page TAB1'. 25 Dans un mode particulier de réalisation, l'invocation du service S1 déclenche l'affichage en premier plan dans le navigateur NAV de la troisième page TAB1' exécutant le service. En variante, l'invocation du service S1 déclenche uniquement le chargement de la troisième page TAB1' et la première page chargée TAB2 correspondant au site du restaurant reste affichée au premier plan, la troisième page TAB1' étant par exemple chargée dans un autre onglet du 30 navigateur NAV non visible. Dans un mode particulier de réalisation, le procédé d'invocation d'un service applicatif par un navigateur comporte une première étape E20 non représentée à la figure 3, cette étape E20 permettant d'enregistrer, préalablement à l'étape E40 de détection, le ou les types de donnée d'invocation TY1 associés au service à invoquer S1. 35 Le ou les types de donnée d'invocation sont par exemple enregistrés avec un identifiant du service S1. Cet enregistrement E20 peut se faire, par le terminal T dans une table TAB telle que représentée à la figure 10. 3051932 11 La figure 4 représente les étapes d'un procédé d'invocation d'un service applicatif S1 par un navigateur NAV, selon un mode de réalisation particulier de l'invention. Ce procédé d'invocation peut être mis en oeuvre dans un terminal T tel que décrit en référence aux figures 1 et 2. 5 Ce procédé reprend les étapes E20, E40, et E60 du procédé telles que décrites précédemment. Dans ce mode de réalisation, le procédé d'invocation d'un service applicatif S1 comporte une étape E10 préalable à l'étape d'enregistrement E20 ou à l'étape de détection E40, cette étape E10 permettant la réception d'une première instruction INS1 définissant une deuxième page TAB1 10 fournissant le service S1, cette instruction INS1 définissant le type de donnée d'invocation TY1 associé au service S1. Dans ce mode de réalisation, et en référence à la figure 5, le terminal T reçoit, en étape E10, depuis le serveur distant SERV, l'instruction INS1 qu'il exécute dans le navigateur NAV, cette exécution permettant en particulier d'enregistrer à l'étape E20 d'enregistrement le type de donnée 15 d'invocation TY1 dans la table TAB. Dans un mode particulier de réalisation, cette première instruction INS1 correspond plus largement à un ensemble des données de page DATA associé à la page TAB1 proposant le service S1. Dans un mode particulier de réalisation, cette première instruction INS1 correspond à la 20 description HTML de la page TAB1 définissant le service S1, cette description HTML pouvant en outre appeler des fonctions en langage Javascript ou éventuellement d'autres données, par exemple multimédia. Dans un mode particulier de réalisation, en référence à la figure 11, le navigateur NAV recevant l'instruction INS1 l'exécute et charge en conséquence dans une deuxième page TAB1 le 25 service S1, correspondant ici à un service de téléphonie, permettant d'appeler un correspondant à partir du numéro [HOME +33 234 567 890], par exemple le numéro de téléphone personnel de l'utilisateur, vers un numéro de téléphone quelconque pris comme donnée d'entrée du service. Le service S1 présente certaines fonctions (appeler, consulter une liste de contact, raccrocher,...) pouvant être utilisées par exemple en cliquant sur des objets graphiques BS1. 30 Parallèlement au chargement de cette page TAB1, un élément de code Javascript contenu dans les données de page associé à la page TAB1 peut être exécuté et permet entre autre l'enregistrement dans la table TAB du type de donnée d'invocation TY1 associé au service S1, ici le type de donnée « numéro de téléphone ». Cette première instruction INS1 permet donc de définir le type de donnée d'invocation TY1 35 utilisable par le service S1. Dans un exemple particulier, une pluralité de types de donnée d'invocation TY1 utilisables par le service S1 est spécifiée dans la première instruction INS1. 3051932 12 Dans un mode particulier de réalisation, la description HTML de la page TAB1 fournissant le service S1 appelle un élément de code Javascript pouvant éventuellement être standardisé comme expliqué précédemment. Ce code Javascript est compris dans les données de page DATA associé à la page TAB1 et 5 fourni par le serveur distant SERV. L'exécution de cet élément de code permet au navigateur NAV d'enregistrer le type de donnée d'invocation TY1 dans le terminal T, par exemple dans la table TAB. L'exécution de cet élément de code permet également de fournir au navigateur des données lui permettant de comprendre que le service S1 associé au type de donnée d'invocation TY1, est 10 invocable, et par quelle méthode il peut l'invoquer. Par exemple, cet élément de code Javascript standardisé pourrait être le suivant : RegisterDataService(TYn, URL, null), pour une méthode d'invocation dite « URL » (URL dans la table TAB de la figure 10), ou RegisterDataService(TYn, URL, function()), pour une méthode d'invocation dite « Callback Javascript » (URL + CJ dans la table TAB de la figure 10). 15 L'exécution de cet élément de code peut permettre d'enregistrer dans la table TAB : le type de donnée d'invocation TYn ; - une adresse réseau URL, visant par exemple une page proposant le service S1 ou une page proposant une fonction particulière de ce service ; et - dans le cas d'une méthode d'invocation Callback Javascript, une fonction 20 « function » pouvant être invoquée lors de l'étape (E60) d'invocation du service ; ces différents éléments étant enregistrés de manière associée, par exemple dans une ligne de la table TAB associée à un identifiant NOM. Dans le cas particulier du service de téléphonie S1, cet élément de code pourrait être écrit sous la forme : RegisterDataService(TY1, http://communicationservice/number, null) (dans le cas 25 de la méthode d'invocation URL) ou RegisterDataService(TY1, http://communicationservice/number, « Createcall() ») (dans le cas de la méthode d'invocation Callback Javascript). Dans ce mode particulier de réalisation, le navigateur, en exécutant cet élément de code, enregistre dans la table TAB à l'étape E20 d'enregistrement le type de donnée d'invocation TY1 30 correspondant au type numéro de téléphone, et l'adresse réseau http://communicationservice/number pointant vers une page proposant par exemple la fonction d'appel du service S1. Elle peut en variante correspondre à l'adresse réseau pointant vers la page TAB1 proposant le service S1. 35 Dans un mode particulier de réalisation, lors de l'étape E40 de détection, la page pointée par l'adresse réseau http://communicationservice/number est chargée dans le navigateur NAV. Dans le cas particulier de la méthode URL, lors de l'étape E60 d'invocation, le navigateur NAV peut ajouter (ou concaténer) une donnée DN (dans cet exemple le numéro de téléphone du 3051932 13 restaurant +33122334455) détectée dans la première page TAB2 à l'adresse réseau URL http://communicationservice/number, pour construire par exemple une nouvelle adresse réseau http://communicationservice/number/+33122334455, pointant vers la troisième page TAB1' que le navigateur va ensuite charger. 5 La page TAB1' peut correspondre à une mise à jour de la page pointée par l'adresse http://communicationservice/number si cette page est déjà chargée dans le navigateur. En variante, la page pointée par l'adresse http://communicationservice/number n'est pas chargée initialement et le chargement de la page TAB1' est déclenché dans le navigateur NAV au moment de l'étape d'invocation et ne constitue donc pas une mise à jour. 10 Cette troisième page TAB1' exécute le service de téléphonie et est représentée à la figure 14. Dans le cas particulier de la méthode Callback Javascript, le navigateur enregistre en plus du type de donnée et de l'adresse réseau, la chaine de caractères « Createcall() » correspondant à une fonction en langage Javascript qui sera invoquée lors de l'invocation du service. 15 Dans ce mode de réalisation particulier, lors de l'étape E60 d'invocation, le navigateur NAV charge la page pointée par l'adresse réseau http://communicationservice/number puis invoque la fonction Javascript « Createcall() » , déclenchant le chargement de la troisième page TAB1' de la figure 14 exécutant le service. En variante, la page pointée par l'adresse réseau http://communicationservice/number est 20 chargée dans le navigateur lors de l'étape E40 de détection, et lors de l'étape E60 le navigateur NAV invoque la fonction « Createcall() » dans cette page sans la charger. Cette adresse réseau permet en d'autres termes d'indiquer au navigateur dans quelle page invoquer la fonction Javascript pour invoquer le service et donc pour charger la page TAB1' exécutant le service. 25 Dans un mode particulier de réalisation, l'élément de code comporte également des informations précisant si la troisième page chargée TAB1' doit être affichée en premier plan dans le navigateur ou si elle doit simplement être chargée, par exemple dans un onglet non affiché du navigateur NAV, comme c'est le cas à la figure 13. La fonction « Createcall() » pourrait être définie de la manière suivante (numéro de ligne 30 ajoutés) : 1 function CreateCall(number, displayZone) 2 3 35 4 initiateCall(number); 5 displayGUI(displayZone); 6 playTones(); 7 3051932 14 8 } Cette fonction prend comme arguments d'entrée une variable de type numéro de téléphone "number", et éventuellement une variable liée à une page du navigateur « displayZone ». 5 De manière avantageuse, la signature de cette fonction, c'est-à-dire le nombre d'arguments d'entrée et leurs types (chaine de caractère, nombre entier, etc.) peut faire l'objet d'une normalisation par les fournisseurs de service. Dans cet exemple particulier, la fonction « Createcall » comporte : - à la ligne 4, une fonction initiateCall(number) permettant d'initier un appel 10 téléphonique vers le numéro de téléphone « number » pris en argument ; - à la ligne 5, une fonction displayGUl(displayZone) permettant d'afficher un élément graphique, par exemple un encadré (ou « iframe » dans le langage HTML) dans la page définie par « displayZone », par exemple la première page chargée TAB2 ; 15 - à la ligne 6, une fonction playTones() permettant de jouer une alarme ; - etc... Cette fonction sera invoquée, dans le cas d'une méthode d'invocation Callback Javascript, lors de l'étape E60 d'invocation du service Si, et prendra en argument (pour la variable « number ») la donnée DN détectée correspondant dans ce mode de réalisation au numéro de 20 téléphone du restaurant. Son exécution permet dans ce mode de réalisation d'exécuter le service 51. La figure 6 représente un procédé d'invocation d'un service applicatif Si par le navigateur NAV, conforme à un mode réalisation particulier de l'invention. Ce procédé est mis en oeuvre par un terminal T, tel que représenté en références aux 25 figures 1 et 2. Ce procédé reprend les étapes générales E20, E40 et E60 précédemment décrites en référence aux figures 3 à 5. Dans ce mode de réalisation, le procédé comporte également une étape E50 de déclenchement de la fourniture d'une notification NOTIF indiquant l'accessibilité, dans la première 30 page chargée TAB2, du service Si. Dans un mode particulier de réalisation, lors de cette étape de déclenchement, c'est le navigateur NAV qui fournit la notification NOTIF et qui l'affiche dans la première page chargée TAB2. Par exemple, en référence à la figure 12, le navigateur NAV affiche, dans la page chargée 35 TAB2 du navigateur NAV, la notification NOTIF pointant le numéro de téléphone DN détecté à l'étape E40, cette notification NOTIF comportant une première ligne « Call with [HOME +33 234 567 890] ». 3051932 15 Cette première ligne indique l'accessibilité du service S1 de téléphonie dont la page TAB1 a été précédemment chargée au moins une fois. Elle permet également, dans ce mode de réalisation, d'invoquer le service S1 de téléphonie prenant en entrée la donnée DN, par exemple en cliquant sur la ligne « Call with [HOME 5 +33 234 567 890] »., et donc appeler le restaurant. Cette notification NOTIF peut également comporter une deuxième ligne « Call with [BUSINESS +33 235 678 901] » indiquant l'accessibilité d'un deuxième service S4 fourni par exemple par une page TAB4 telle que représentée à la figure 17. Ce deuxième service comporte également différentes fonctions accessibles par exemple en 10 cliquant sur les éléments graphiques BS2. Ces fonctions prennent également en entrée un numéro de téléphone correspondant à la donnée d'invocation DN, mais elles correspondent à un deuxième service de téléphonie, par exemple depuis un numéro de téléphone différent comme le numéro de téléphone professionnel de l'utilisateur. En variante, l'étape de déclenchement E50 comporte une étape d'envoi d'une commande 15 COMM vers un dispositif, cette envoi causant la fourniture de la notification NOTIF par ce dispositif. Dans un mode particulier de réalisation, ce dispositif est le terminal T mettant en oeuvre le procédé d'invocation, et la commande COMM permet par exemple d'appeler un logiciel préenregistré dans le terminal T, ce logiciel permettant la fourniture de la notification NOTIF par le terminal T. 20 Par exemple, le logiciel fournissant la notification NOTIF peut permettre d'afficher une fenêtre « pop-up » sur une interface du terminal T et donc d'indiquer à l'utilisateur du terminal T l'accessibilité du service. En variante, la commande COMM est envoyée vers un dispositif DIS externe au terminal T tel que représenté en référence à la figure 7. 25 Ce dispositif DIS peut consister en un deuxième terminal, un composant périphérique du terminal T, comme par exemple un haut-parleur, ou encore un objet connecté. Ce dispositif DIS recevant la commande COMM fournit alors la notification NOTIF à l'utilisateur indiquant l'accessibilité du service S1, par exemple sous forme d'un message contenant une donnée multimédia, par exemple un texte, une image ou une vidéo. 30 A noter par ailleurs que diverses formes de notification (graphique, audio etc.) sont possibles à l'étape E50 pour indiquer l'accessibilité, dans la première page chargée TAB2, du service Si. La figure 8 représente un procédé d'invocation d'un service applicatif S1 par un navigateur NAV conforme à un mode de réalisation particulier de l'invention. Ce procédé peut être mis en oeuvre par un terminal T tel que représenté en références aux 35 figures 1 ou 2. Ce procédé reprend les étapes générales E20, E40 et E60, précédemment décrites en référence aux figures 3 à 6. 3051932 16 Dans ce mode de réalisation, l'étape E40 de détection d'une donnée d'invocation DN dans une première page chargée TAB2 conforme au type de données d'invocation TY1 comporte deux sous-étapes E400 et E450. A l'étape E400, une ou plusieurs données d'invocation DN présentes dans la première page 5 chargée TAB2 sont identifiées. Par exemple, en référence à la figure 13, la donnée d'invocation DN correspondant au numéro de téléphone +33 122 334 455 du restaurant peut être identifiée par le navigateur NAV, par exemple dans la description HTML de cette page chargée TAB2. L'étape E400 est suivie d'une étape E450 de détermination pour déterminer, pour chaque 10 donnée identifiée DN identifiée, si cette donnée est conforme au type de données TY1. Dans un mode particulier de réalisation, ce type de donnée TY1 correspond à un numéro de téléphone, et peut être utilisé par un service S1 de téléphonie. Le navigateur détermine alors en étape E450, si la page chargée TAB2 comporte une donnée conforme au type de donnée « numéro de téléphone », par exemple en analysant la 15 description HTML associée à cette page TAB2 telle qu'elle a été détaillée précédemment. Dans un mode particulier de réalisation, lors de l'étape E400 d'identification, chaque donnée d'invocation DN est identifiée en réponse à une commande d'un utilisateur reçue par le navigateur NAV. Par exemple, l'utilisateur peut cliquer sur ou sélectionner cette donnée d'invocation DN avec 20 un pointeur (ou tout autre moyen approprié) pour commander au navigateur NAV de déterminer en étape E450, si cette donnée sélectionnée est conforme au type de donnée TY1. En variante, cette donnée d'invocation DN est identifiée automatiquement à l'étape E400, par exemple par analyse automatique de la description HTML de la page. Dans un mode particulier de réalisation, l'étape E40 de détection peut consister en une 25 étape d'analyse sémantique de la première page chargée TAB2. Dans ce mode de réalisation, le navigateur NAV peut par exemple parcourir la description HTML associée à la page chargée TAB2 et détecter un texte dont le format correspond à un certain type d'invocation. Dans la description HTML précédemment détaillée page 10 lignes 17 à 22, le navigateur NAV 30 peut détecter à la ligne 5 la donnée d'invocation DN « + 33 122 334 455 » en parcourant cette description HTML. Par exemple, le navigateur NAV peut détecter qu'une suite de caractères commençant par le caractère « + » puis suivie d'un ensemble de dix chiffres correspond à une donnée d'invocation DN conforme au type de donnée d'invocation correspondant à un numéro de téléphone. 35 En variante, l'étape E40 de détection correspond à une étape de détection d'un marqueur (ou « tag » en anglais) codé dans la première page chargée TAB2 en association avec la donnée d'invocation DN. 3051932 17 Dans un mode particulier de réalisation, ce marqueur codé peut correspondre à une ou plusieurs balises, dite « URL Request Identifier », insérées dans la description HTML associée à cette page chargée TAB2. Dans le mode de réalisation décrit ici, deux balises sont placées de part et d'autre d'une 5 donnée d'invocation pour marquer cette dernière comme étant d'un type prédéfini. Le contenu de cette balise indique ainsi un type de donnée d'invocation préalablement déclaré, par exemple tel que défini et normalisé sur le site Internet http://schema.org. Par exemple, dans le code HTML associé à la table TAB2 et précédemment détaillé, les balises et permettent d'indiquer que la donnée comprise entre ces balises 10 correspond à un numéro de téléphone. La figure 9 représente un procédé d'invocation d'un service applicatif S1 par un navigateur NAV selon un mode de réalisation particulier de l'invention. Ce procédé peut être mis en oeuvre par un terminal T tel que représenté aux figures 1 et 2. Ce procédé reprend les étapes générales E20, E40 et E60 telles que décrites en référence 15 aux figures 3 à 6 et également à la figure 8. Ce procédé comporte une étape E80 d'exécution du service S1 dans la troisième page TAB1'. Dans un mode de réalisation dans lequel la méthode d'invocation employée est la méthode Callback Javascript, l'exécution du service dans la page TAB1' peut être simultanée à l'affichage, dans la première page chargée TAB2, d'une unité de commande UNIT accessible par un utilisateur 20 pour contrôler le service invoqué Si. Ce mode de réalisation correspond à une méthode d'invocation Callback Javascript évoquée précédemment, bien que d'autres méthodes d'invocation soient possibles. Dans un mode particulier de réalisation, la navigateur NAV affiche lors de l'étape d'invocation E60, dans la page chargée TAB2, un encadré (ou « iframe » dans le langage HTML) 25 dont le contenu est défini par la fonction Javascript « function » comprise dans l'instruction INS1 invoquée, tel qu'expliqué précédemment. En référence à la figure 13, le navigateur NAV affiche dans la première page chargée TAB2 une unité de commande UNIT permettant de contrôler le service S1 de téléphonie prenant en entrée la donnée d'invocation DN correspondant à un numéro de téléphone. 30 Par exemple, un utilisateur peut, via cette unité de commande UNIT, agir sur la conversation téléphonique mise en oeuvre par le service S1 dans la page chargée TAB2, par exemple mettre en pause la conversation, l'enregistrer, raccrocher, etc. En variante, l'invocation du service S1 cause l'affichage en premier plan de la page TAB1' qui exécute à l'étape E80 le service S1 alors disponible pour l'utilisateur, sans afficher d'unité de 35 commande dans la page TAB2. Ce mode de réalisation correspond à une méthode d'invocation URL. Par exemple, dans ce mode de réalisation particulier et en référence à la figure 15, le navigateur NAV affiche une page chargée TAB2 correspondant à la page internet d'un restaurant, 3051932 18 comportant une donnée d'invocation DN2 correspondant à l'adresse du restaurant, ici « 42 rue des Palmiers 75000 PARIS ». A l'étape E40, le navigateur NAV détecte dans cette première page chargée TAB2 la donnée d'invocation DN2 conforme au type de donnée d'invocation « adresse » TY2. 5 Par exemple, le navigateur NAV détecte cette donnée dans la description HTML suivante permettant d'afficher l'adresse dans le navigateur : 42 rue des Palmiers 75000 PARIS . Le navigateur NAV peut détecter cette donnée par analyse sémantique en identifiant une chaine de caractères conforme à une adresse, ou encore en détectant un ou plusieurs marqueurs 10 codés représentatifs d'un type de donnée particulier, ici et . Ces marqueurs particuliers entre balises ont été standardisés et correspondent aux marqueurs présents sur le site Internet http://schema.org. En variante, d'autres marqueurs permettent de détecter la donnée d'invocation. Dans un mode particulier de réalisation, cette étape d'identification E40 est suivie de l'étape 15 E50 d'affichage d'une notification NOTIF2, ici représentant un globe terrestre et indiquant l'accessibilité d'un service S3, par exemple un service de taxi. En étape E60, l'utilisateur peut cliquer, directement sur l'adresse affichée si la notification NOTIF2 ne s'affiche pas, ou en variante sur cette notification NOTIF2, invoquant alors le service S3, et causant le chargement d'une troisième page TAB3' telle que représentée en référence à la 20 figure 16. Cette troisième page TAB3' propose un service S3 correspondant, dans cet exemple, à un service de taxi. Dans un autre mode de réalisation, l'élément graphique LINK représente un globe terrestre pointant vers un adresse URL. 25 Par exemple, cette adresse URL peut être sous la forme HTML suivante : href="http://location.map. test?42+rue+des+Palmiers+75000+PARIS+France&service=Jaer oiuyAZerbuiroezeru"> REVENDICATIONS1. Procédé d'invocation dans un terminal (T) d'au moins un service applicatif (S1, S3) par un navigateur (NAV), ledit procédé comportant : - une étape (E40) de détection, dans une première page chargée (TAB2) dans ledit navigateur (NAV), d'au moins une donnée d'invocation (DN, DN2) conforme à au moins un type de donnée d'invocation (TY1, TY2) enregistré pour ledit au moins un service (S1, S3) ; et - une étape (E60) d'invocation, dans ladite première page chargée (TAB2), dudit au moins un service (S1, S3) à partir de ladite au moins une donnée d'invocation (DN) détectée. 2. Procédé selon la revendication 1, comportant, préalablement à l'étape (E40) de détection, une étape (E20) d'enregistrement dudit au moins un type de donnée d'invocation (TY1, TY2). 3. Procédé selon la revendication 1 ou 2, comportant, préalablement à l'étape (E40) de détection, une étape (E10) de réception d'une première instruction (INS1) définissant au moins une deuxième page (TAB1, TAB3) fournissant ledit au moins un service (S1, S3), ladite première instruction (INS1) définissant ledit au moins un type de donnée d'invocation (TY1, TY2). 4. Procédé selon l'un quelconque des revendications 1 à 3, dans lequel ladite étape (E40) de détection comporte : - une étape (E400) d'identification d'au moins une donnée d'invocation (DN, DN2) présente dans ladite première page chargée (TAB2) ; et - une étape (E450) de détermination pour déterminer, pour au moins une dite donnée d'invocation identifiée (DN), si ladite donnée est conforme audit au moins un type de donnée (TY1, TY2). 5. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel ladite étape (E40) de détection comporte au moins l'une parmi : une étape d'analyse sémantique de ladite première page chargée (TAB2); et - une étape de détection d'un marqueur codé dans ladite première page (TAB2) en association avec ladite au moins une donnée d'invocation (DN, DN2). 6. Procédé selon l'une quelconque des revendications 3 à 5, dans lequel : 3051932 22 - ladite première instruction (INS1) définit au moins une adresse réseau pointant vers au moins une troisième page (TAB1', TAB3') ; et - ladite étape (E60) d'invocation comporte une étape de déclenchement du chargement de ladite au moins une troisième page (TAB1', TAB3') à partir de ladite au moins une 5 adresse ; ledit procédé comportant une étape (E80) d'exécution dudit au moins un service (Si, S3) dans ladite au moins une troisième page (TAB1', TAB3'). 7. Procédé selon la revendication 6 dans lequel, lors de ladite étape (E40) de détection, ladite 10 au moins une deuxième page (TAB1, TAB3) n'est pas chargée dans ledit navigateur (NAV). 8. Procédé selon l'une quelconque des revendications 6 à 7, dans lequel : - ladite première instruction (INS1) définit une fonction d'invocation dudit au moins un service (Si, S3) ; 15 - ladite étape (E60) d'invocation comporte une étape d'invocation de ladite fonction ; et - ladite étape (E80) d'exécution dudit au moins un service (S3) dans ladite troisième page (TAB3) comporte l'exécution de ladite fonction. 9. Procédé selon la revendication 8, dans lequel ladite exécution de ladite fonction cause 20 l'affichage, dans ladite première page chargée (TAB2), d'une unité de commande (UNIT) accessible par un utilisateur pour contrôler ledit au moins un service (S1, S3) lors de son exécution dans ladite troisième page (TAB1', TAB3'). 10. Procédé selon l'une quelconque des revendications 1 à 9, comportant une étape (E50) de 25 déclenchement de la fourniture d'au moins une notification (NOTIF) indiquant l'accessibilité, dans ladite première page chargée (TAB2), dudit au moins un service (Si, S3). 11. Procédé selon la revendication 10, dans lequel lors de ladite étape (E50) de 30 déclenchement, ledit navigateur (NAV) fournit ladite au moins une notification (NOTIF) et affiche cette notification (NOTIF) dans ladite première page chargée (TAB2). 12. Procédé selon la revendication 11, dans lequel ladite étape (E50) de déclenchement comporte une étape d'envoi d'une commande (COMM), vers au moins un dispositif, 35 causant ladite fourniture de ladite notification (NOTIF) par ledit dispositif. 3051932 23 13. Programme d'ordinateur (PG) comportant des instructions pour l'exécution des étapes d'un procédé d'invocation selon l'une quelconque des revendications 1 à 12 lorsque ces instructions sont exécutées par un ordinateur. 5 14. Support d'enregistrement (SUP) lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant les instructions pour l'exécution desdites étapes d'un procédé d'invocation selon l'une quelconque des revendications 1 à 12. 15. Terminal (T) permettant l'invocation d'au moins un service applicatif (S1, S3) par un 10 navigateur (NAV), ledit terminal comportant : - un module de détection (DET), dans une première page chargée (TAB2) dans ledit navigateur (NAV), d'au moins une donnée d'invocation (DN, DN2) conforme audit au moins un type de donnée (TY1, TY2) d'invocation enregistré pour ledit au moins un service applicatif (S1, S3) ; et 15 - un module d'invocation (INV), dans ladite première page chargée (TAB2), dudit au moins un service (S1, S3) à partir de ladite au moins une donnée d'invocation (DN, DN2) détectée. 20