Brevet FR2945704A1 — publié le 20101119

La présente invention se rapporte aux applications pour des téléphones intelligents ou Smartphone, notamment aux applications pour les téléphones sous la marque déposée iPhone de la société Apple. En particulier, la présente invention se rapporte à un réseau de télécommunication comportant au moins un téléphone portable intelligent (Smartphone), au moins un serveur web, notamment du type http ou ftt, comportant une base de données principales dont les données varient au cours du temps, et un système central formant interface applicative de traitement des données, ou API pour interface de programmation applicative, la liaison dans le réseau entre l'API et le ou les serveurs web se faisant par un réseau filaire, notamment à haut débit, tandis que la liaison entre l'API et le ou les Smartphone se fait par un réseau Hertzien, notamment 3G. La présente invention se rapporte également à une API d'un réseau de ce genre. On connaît déjà des réseaux de télécommunication, dans lesquels la liaison par l'intermédiaire du réseau Hertzien, notamment 3G, est beaucoup moins fiable que celle par le réseau filaire à haut débit, notamment par ADSL ou fibre optique. Ainsi, lorsqu'un utilisateur d'un Smartphone souhaite se connecter à un serveur web pour obtenir des informations qui varient au cours du temps, cette connexion qui se fait par le réseau Hertzien est lente et peu fiable. En outre, lorsqu'il veut extraire des informations de ce serveur web, ces extractions prennent également beaucoup de temps. Il en résulte une durée nécessaire, pour effectuer la connexion et obtenir les informations recherchées qui varient au cours du temps, qui est longue. En outre, l'utilisateur doit appuyer sur des touches du Smartphone qui sont de petites dimensions alors même qu'il est en mouvement, ce qui rend la connexion et l'obtention des informations souhaitées peu pratiques. La présente invention vise à surmonter les inconvénients des systèmes et réseaux de l'art antérieur en proposant un réseau de télécommunication et une API qui permettent à un utilisateur d'un téléphone intelligent d'effectuer une connexion avec un serveur web ayant une base de données dont les données varient au cours du temps et obtenir les informations souhaitées de manière beaucoup plus simple et beaucoup plus rapide. Suivant l'invention, le ou chaque Smartphone est relié au système central API par l'intermédiaire du réseau Hertzien, notamment 3G, tandis que le central API est relié au serveur web par un réseau filaire, notamment à haut débit, le central API comportant des moyens destinés à recevoir une requête du Smartphone pour obtenir des données du serveur web, des moyens pour se connecter au serveur web et pour recevoir des données du serveur web, les données reçues par le central API du serveur web ayant une partie fixe ne variant pas au cours du temps et une partie variable au cours du temps, le central API comportant, en outre, des moyens destinés à séparer la partie fixe et la partie variable au cours du temps et des moyens pour transmettre uniquement la partie de données variable au cours du temps au téléphone intelligent par l'intermédiaire du réseau Hertzien, notamment 3G. De préférence, la partie fixe des données ou des données équivalentes à cette partie fixe du serveur web, notamment le chemin d'accès aux données fixes et variables, ayant été mémorisées à l'avance dans le téléphone intelligent et le téléphone intelligent comportant des moyens pour traiter les données variables au cours du temps reçues de l'API pour, avec les données fixes mémorisées à l'avance, fournir à l'utilisateur des données identiques ou équivalentes à celles du serveur web, notamment en supprimant les données fixes inutiles (présentation, etc...) pour ne laisser passer que les données variables utiles. Ainsi, suivant l'invention, on ne transmet par le réseau Hertzien, notamment 3G, que des informations de très petite taille, uniquement les variations au cours du temps des données, tandis que le plus gros du volume des données n'est transmis qu'entre l'API et le serveur web par l'intermédiaire du réseau filaire à haut débit. Ceci permet d'accélérer notablement le temps d'attente nécessaire pour obtenir les informations pour l'utilisateur dans un rapport pouvant aller jusqu'à dix fois plus vite, de sorte que les données reçues par l'utilisateur sont presque en temps réel par rapport à celles disponibles sur le serveur web, avec un petit décalage de quelques secondes seulement. Suivant un mode de réalisation préféré de l'invention, la base de données est divisée en n classes principales correspondant chacune à un emplacement donné dans l'espace, par exemple des gares ferroviaires, chaque classe principale comportant des sous-classes correspondant à des évènements ayant lieu dans une classe principale, par exemple les destinations, les heures théoriques de départ ou d'arrivée des trains dans la gare en question, des données variables au cours du temps étant affectées à chaque sous-classe, notamment les horaires réels, et les requêtes d'information concernant une classe donnée de la base de données du serveur web sont réalisées par l'envoi d'un code URL préenregistré dans le téléphone intelligent et dans le central API. Suivant un mode de réalisation préféré de l'invention, le Smartphone comporte des moyens destinés à le géolocaliser, et le Smartphone comporte des moyens pour envoyer automatiquement le code correspondant à la classé dont l'emplacement est le plus proche de l'endroit où se trouve le Smartphone. Suivant un mode ae réalisation particulièrement préféré, les classes correspondent à des gares ferroviaires sur un territoire donné, par exemple la France ou l'Europe, les sous-classes correspondant aux trains en partance et à l'arrivée de la gare ainsi que leurs horaires théoriques de départ et/ou d'arrivée et les données qui varient au cours du temps sont l'état des informations concernant les horaires réels de départ et/ou d'arrivée de chaque train. La présente invention se rapporte également à un 20 système central formant API destiné à être utilisé dans un réseau suivant l'invention. On décrit maintenant un mode de réalisation préféré de l'invention en se rapportant au dessin, dans lequel la Figure 1 représente de manière schématique un réseau 25 suivant l'invention ; et La Figure 2 est un schéma synoptique d'un système central formant API suivant l'invention. A la Figure 1, est représenté un réseau suivant l'invention pour une application se rapportant aux 30 horaires des trains. Le réseau de télécommunication comporte une pluralité de Smartphone 1 qui sont reliés entre eux et avec le réseau internet par l'intermédiaire d'un réseau Hertzien 3G. Un système central formant API est relié avec l'ensemble des Smartphone 1 par l'intermédiaire du réseau Hertzien 3G. Le central 2 API est relié à un serveur web 3 comportant une base de données. Cette base de données comporte n classes, chaque classe correspondant à une gare ferroviaire en Europe. A chaque classe de gare sont affectées des sous-classes correspondant aux trains en partance et à l'arrivée, ainsi que les horaires théoriques de ces trains au départ et à l'arrivée. Les données sont fixes et ne varient sensiblement pas au cours du temps, notamment d'un jour à l'autre, ou d'un mois à l'autre, voire même d'une année à l'autre. De temps à autre, de manière ponctuelle une notification de la programmation des trains à lieu, mais de manière générale ces données ne varient pas. A chaque sous-classe correspond également des données temporelles qui varient avec le temps et qui correspondent aux horaires réels des trains. Il peut s'agir de l'état du trafic tel que, "A l'heure" ou "En retard" avec indication du temps de retard. Le central API est relié au serveur 3 par l'intermédiaire d'une liaison filaire à haut débit du type ADSL ou fibre optique. La base de données comportent ainsi un ensemble de données fixes qui ne varient pas au cours du temps et de données variables qui varient au cours du temps. Les données fixes consistent en l'ensemble des gares et des trains en partance et à l'arrivée ainsi que des horaires théoriques prévus à l'avance. L'ensemble de ces données fixes ou des données équivalentes à ces données fixes ont été préalablement introduites dans le Smartphone 1 par programmation dans des moyens de mémorisation classiques. En outre, le Smartphone 1 comporte une application de géolocalisation également bien connue dans le domaine, par exemple l'application CLL location classe dans la Core Location Framework du Iphone de Apple. A chaque classe, c'est-à-dire à chaque gare en Europe, il est affecté dans le Smartphone 1 un code URL donné. Lorsque l'utilisateur souhaite obtenir des informations concernant une gare, il actionne une touche gare ou équivalente sur son téléphone permettant d'actionner l'application API. Une géolocalisation est alors effectuée et la gare la plus proche est déterminée. Le code URL de cette gare la plus proche est envoyé au central API. Cette transmission se fait par l'intermédiaire du réseau 3G. Le volume des données est très petit, de sorte que cette transmission se fait très rapidement. Sur la base de ce code reçu, le central de traitement API se connecte au serveur 3 et obtient l'ensemble des données fixes et variables se rapportant à la classe principale (gare) en question. La connexion pour obtenir les données (étape 3 et 4 au schéma) se fait par l'intermédiaire de la liaison internet filaire à haut débit ADSL ou fibre optique de sorte que le temps de connexion est également très court. Une fois l'ensemble des informations et des données fixes et variables au cours du temps reçues en retour par le central 2 API, celui-ci effectue une sélection par des moyens de sélection appropriés, bien connus dans le domaine, et ne conserve que les données variables au cours du temps. Ces données variables sont envoyées sous la forme d'informations brutes en XML au Smartphone 1 par l'intermédiaire du réseau Hertzien 3G. Ces informations variables représentent un volume total très petit par rapport au volume des données fixes et variables. Ainsi, elles représentent par exemple 10 à 20 fois moins de volume de sorte que la transmission entre le central 2 de traitement API et le smartphone 1, bien qu'effectuée par le réseau 3G, se fait également très rapidement. Lorsque le Smartphone 1 reçoit les informations brutes par des moyens de réception appropriés, il les transmet à des moyens de mise en page des données au format local du Smartphone 2 qui les traite en les fusionnant avec des données fixes qui ont été préalablement introduites dans le Smartphone 2 et fournit ainsi les informations souhaitées par l'utilisateur. Celui-ci a alors à disposition pour la gare la plus proche l'ensemble des trains au départ et à l'arrivée, les horaires théoriques ainsi que le retard éventuel de chacun d'entre eux. Les données préalablement enregistrées correspondent sensiblement aux données fixes et sont mises à jour au fur et à mesure de leurs variations rares au cours du temps (de l'ordre du mois ou de l'année). Bien évidemment, la géolocalisation est un avantage qui permet d'accélérer le temps de traitement de la requête. Cependant, si l'utilisateur souhaite avoir les trains au départ d'une gare qui n'est pas la gare la plus proche il peut également le faire en choisissant la gare en question et le code envoyé à l'étape 2 sera le code de cette gare. L'effet de l'invention qui consiste à permettre l'obtention des données très rapidement sera également réalisé, même si cela sera dans une moindre mesure (dans ce cas, il n'y a pas le gain de temps lié à la géolocalisation). A la figure 2, il est représenté un schéma synoptique du central 2 API. Celui-ci comporte des moyens destinés à recevoir un code URL donné correspondant à une classe donnée. Il est également prévu des moyens pour se connecter au serveur 3 en fonction du code obtenu pour effectuer la traduction de ce code en la classe souhaitée. Le central API comporte des moyens de réception destinés à recevoir les informations de la classe correspondant au code donné ; des moyens de traitement destiné à traiter les informations reçues et à diviser cette information en les données fixes et les données variables au cours du temps ; des moyens de mises au format ; des moyens XML d'envoi des données XML au Smartphone 1. Celui-ci va ensuite fusionner par des moyens appropriés ces données XML avec des données préalablement enregistrées correspondant sensiblement aux données fixes qui ont été reçues par le central 2 à l'étape 4 mais qui n'ont pas été transmises par la suite. On obtient ainsi un gain de temps et une simplification de l'obtention des informations. Le temps de réponse d'une requête est de quelques secondes contre presque 1 mn si l'utilisateur se connecte par l'intermédiaire du réseau 3G au serveur, sans passer par le central API. En outre l'accès à l'information se fait en une seule opération voire deux maximums ce qui est très utile compte tenu de l'ergonomie des Smartphone qui ont des petites touches. Dans certaines applications de ce genre, on obtient ainsi les données en temps quasi réel. REVENDICATIONS1. Réseau de télécommunication comportant au moins un téléphone portable intelligent (Smartphone), au moins un serveur web, notamment du type http ou ftt, comportant une base de données principales dont les données varient au cours du temps, et un système central formant interface applicative de traitement des données, ou API pour interface de programmation applicative, la liaison dans le réseau entre l'API et le ou les serveurs web se faisant par un réseau filaire, notamment à haut débit, tandis que la liaison entre l'API et le ou les Smartphone se fait par un réseau Hertzien, notamment 3G, caractérisé en ce que le central API comporte des moyens destinés à recevoir une requête du Smartphone pour obtenir des données du serveur web ; des moyens pour se connecter au serveur web et pour recevoir les données du serveur web, les données reçues par le central API du serveur web ayant une partie fixe ne variant pas au cours du temps et une partie variable au cours du temps, l'API comportant, en outre, des moyens destinés à séparer les données fixes et les données variables au cours du temps et des moyens pour transmettre uniquement la partie variable au cours du temps au téléphone intelligent par l'intermédiaire du réseau Hertzien, notamment 3G. 2. Réseau suivant la revendication 1, caractérisé en ce que la partie fixe du serveur web ou des données équivalentes à cette partie fixe a été mémorisée à l'avance dans le téléphone intelligent et le téléphone intelligent comporte des moyens pour traiter les données variables au cours du temps reçues de l'API pour, avec les données fixes mémorisées à l'avance, fournir àl'utilisateur des données identiques ou équivalentes à celles du serveur web. 3. Réseau suivant la revendication 1 ou 2, caractérisé en ce que les requêtes d'information concernant une classe donnée de la base de données du serveur web sont réalisées par l'envoi d'un code URL préenregistré dans le téléphone intelligent et dans le central API. 4. Réseau suivant l'une des revendications 1 à 3, caractérisé en ce que le Smartphone comporte des moyens destinés à le géolocaliser, et le Smartphone comporte des moyens pour envoyer automatiquement le code correspondant à la classe la plus proche de l'endroit où se trouve le Smartphone. 5. Réseau suivant l'une des revendications 1 à 4, caractérisé en ce que les classes correspondent à des gares ferroviaires sur un territoire donné, par exemple la France ou l'Europe, les sous-classes correspondant aux trains en partance et à l'arrivée de la gare ainsi que leurs horaires théoriques de départ et/ou d'arrivée et les données qui varient au cours du temps sont l'état des informations concernant les horaires réels de départ et/ou d'arrivée de chaque train. 6. API destinée à être utilisée dans un réseau suivant l'une des revendications précédentes.30