Brevet FR2905488A1 — publié le 20080307

L'invention a pour domaine celui de l'accès, via un réseau, à un fichier audio disponible sur un serveur de téléchargement ou à un flux audio disponible sur un serveur de flux, puis de la lecture de ce fichier ou flux par un terminal utilisateur. Le document US 6 678 215 décrit, d'un point de vue très général, un terminal audio, tel qu'un radio-réveil, connecté au réseau Internet pour recevoir des données audio. Les données audio reçues par le terminal, qui sont compressées dans des formats standard, sont décompressées par des moyens logiciels, puis jouées par des moyens de restitution du son dont est équipé le radio-réveil. Les contenus audio sous forme digitale actuellement disponibles sur l'Internet proviennent soit de radios dites Internet qui émettent leurs émissions directement sur le réseau Internet pour une écoute en directe ; soit de radios FM/AM qui convertissent leurs programmes sous forme de fichiers audio qui sont accessibles via le site Internet de la radio FM/AM ; soit encore de tout autre fournisseur de contenu mettant en accès, libre ou payant, un fichier audio tel qu'une publicité, une émission enregistrée (par exemple du type Podcast ), un journal ou magazine d'information lu par un être humain ou un moteur de synthèse vocal, un livre lu appelé aussi livre audio , une ou plusieurs plages de musique achetées sur le site d'une maison de disques, etc. Les serveurs sur lesquels sont stockés ou autorisant l'accès à ces fichiers ou flux de données sont conçus soit pour un téléchargement complet du fichier sur le terminal utilisateur, pour une lecture différée du fichier audio, soit pour un téléchargement partiel en continu d'un fichier audio pour une lecture en léger différé, la taille de la portion téléchargée du fichier étant limitée par la mémoire de l'équipement utilisateur, soit pour une transmission en continue des données du fichier pour une lecture immédiate ou en très léger différé (mise en mémoire d'un volume tampon de données pour prévenir tout interruption dans la restitution sonore en cas d'engorgement du réseau). La première méthode de transfert de données entre le serveur de contenu et le terminal utilisateur est dénommée par le terme anglais de download signifiant téléchargement , la deuxième méthode est dénommée progressive download , alors que la troisième méthode est dénommée streaming (qui est le terme anglais pour flux). C'est à ces deux dernières méthodes que se rapporte exclusivement la présente invention. Dans ce qui suit, nous utiliserons de préférence le terme de flux de données en continu , 2905488 2 en regroupant ainsi les deux méthodes de lecture dite de streaming et de progressive download . Il y a un besoin pour un terminal utilisateur permettant l'écoute de fichiers audio, de différentes origines et formats, via l'Internet mais qui soit à la fois léger, 5 portatif et mobile et ceci tout en ayant un coût réduit et de nombreuses fonctionnalités en adéquations avec les attentes des utilisateurs. L'invention a pour objet un terminal utilisateur comportant : - des moyens de mémorisation et des moyens de calcul ; une interface Homme-Machine ayant des moyens d'affichage et des 10 moyens de saisie ; - des moyens de connexion à un réseau TCP/IP pour accéder à des fichiers audio disponibles sur des serveurs de flux de données audio en continu, chaque fichier audio étant localisé par une URL ; des moyens de décodage du flux de données transmis par ledit 15 serveur ; et, - des moyens de restitution du son à partir dudit flux de données décodé, caractérisé en ce que lesdits moyens de mémorisation comportent une mémoire cache pour sauvegarder l'historique de l'utilisation du terminal, ladite mémoire 20 cache étant une mémoire volatile et étant de taille réduite, et en ce que ledit terminal comporte, en outre, des moyens de communication avec une plateforme de services, lesdits moyens de communication étant aptes à émettre des requêtes HTTP GET vers la plateforme et à recevoir des requêtes au format XML-Phoenix depuis la plateforme. 25 L'invention a également pour objet une architecture pour accéder à des fichiers audio disponibles sur des serveurs de flux de données audio en continu, chaque fichier audio étant localisé par une URL, caractérisé en ce qu'elle comporte un terminal selon ce qui précède et une plateforme de services apte à recueillir auprès de serveur tiers des données hétérogènes relatives à des 30 ressources et à les convertir au format Phoenix, et en ce que lors de la réception d'une réponse au format XML-Phoenix depuis la plateforme, le terminal est apte à se connecter au serveur de flux dont l'URL est contenu dans ladite réponse. L'invention porte également sur un procédé de communication utilisant le protocole TCP/IP entre un terminal utilisateur et une plateforme de services, ledit 35 terminal utilisateur étant apte à accéder à un fichier audio disponible sur un 2905488 3 serveur de flux de données audio en continu, ledit fichier audio étant localisé par une URL, caractérisé en ce que ledit procédé consiste en : - une étape d'authentification du terminal utilisateur auprès de la 5 plateforme de services ; - une étape de mise à jour de la mémoire cache du terminal utilisateur à partir des informations sauvegardées sur ladite plateforme ; - une étape de requête au format HTTP GET à l'initiative du terminal utilisateur vers la plateforme, ladite requête comportant entre autre l'alias d'un 10 fichier audio ; - une étape de réponse au format XML Phoenix de la plateforme vers le terminal utilisateur, ladite réponse comportant entre autre l'URL correspondant audit fichier audio, ledit terminal se connectant alors au serveur de flux correspondant pour accéder au fichier audio associé à ladite URL. 15 C'est en proposant une architecture réseau comportant une plateforme de services additionnelle, ainsi qu'un protocole de communication particulier entre la plateforme et le terminal utilisateur que l'invention permet la mise à disposition d'un terminal utilisateur permettant le restitution de fichiers audio d'origines diverses tout en ayant très peu de ressources mémoire, et en particulier très peut 20 de mémoire morte dont on sait qu'elle est d'un coût élevé. L'invention sera mieux comprise et d'autres buts, détails, caractéristiques et avantages de celle-ci apparaîtront plus clairement au cours de la description d'un mode de réalisation particulier de l'invention donné uniquement à titre illustratif et non limitatif en référence au dessin annexé. Sur ces dessins : 25 La figure 1 représente schématiquement l'architecture mise en oeuvre selon l'invention ; et, - La figure 2 représente schématiquement la plateforme de services de l'architecture de la figure 1. En se référant à la figure 1, l'architecture du système de diffusion de flux de 30 contenu audio selon l'invention va être décrite dans le mode de réalisation actuellement envisagé. Dans ce mode de réalisation, le terminal utilisateur prend la forme d'un radio réveil 1, situé par exemple au domicile de l'utilisateur. Le radio réveil 1, dénommé dans ce qui suit radio IP, comporte des moyens de restitution du son tels que des haut-parleurs permettant de transformer un signal 35 électrique d'entrée en une onde acoustique ; une interface homme-machine IHM 2905488 4 constituée par un écran, par exemple à cristaux liquides, pour présenter à l'utilisateur des informations lisibles et une série de boutons et/ou de touches pour permettre à ce dernier d'interagir et de saisir des informations : circuler dans un menu, sélectionner une radio, augmenter le volume sonore, modifier l'état de la 5 Radio IP 1, etc. D'un point de vue matériel la radio 1P 1 comporte un processeur et une mémoire pour stocker la valeur de certains paramètres et les instructions de programmes aptes à être exécutés par le processeur. La radio IP 1 comporte des cartes électroniques et les interfaces entrées/sorties permettant, pour certaines, 10 l'affichage, l'utilisation des boutons, la gestion des haut-parleurs etc., et pour d'autres, la communication avec un réseau 3. D'un point de vue logiciel la radio IP 1 comporte, des décodeurs de musique numérique permettant de transformer les données reçues depuis le réseau 3 avec des formats standard tels que WMA, MP3, WAV ou l'équivalent, en 15 un signal électrique d'entrée convenant aux haut-parleurs. De préférence ces décodeurs sont sous forme de logiciels mais pourraient être sous forme de cartes électroniques. Dans le mode de réalisation décrit, la Radio IP présente trois modes d'utilisation : un mode Time , pour tout ce qui est relatif aux fonctions liées à ce 20 que l'utilisateur attend d'un réveil (affichage de la date et de l'heure, sélection d'une alarme, etc.) ; un mode Audio , pour tout ce qui est relatif à l'écoute d'un fichier audio (sélection d'un fichier audio, écoute de ce fichier, etc.) ; et un mode Configuration , pour tout ce qui est relatif au paramétrage de la radio IP 1 (réglage du niveau sonore, réglage de l'écran, choix de la langue, paramétrage de 25 la connexion WIFI, etc.) Le réseau 3 est un réseau supportant les échanges selon le protocole HTTP fondé sur le protocole TCP/IP. Par exemple, le réseau 3 est le réseau Internet ou un réseau d'entreprise ( Intranet ) ou l'équivalent. La communication entre la radio IP 1 et le réseau 3 peut se faire 30 directement par une connexion filaire depuis la radio IP 1 jusqu'à un serveur d'un fournisseur d'accès, mais il est préférable de réaliser la connexion au réseau 3 par l'intermédiaire d'une passerelle résidentielle 2 connectée au serveur d'un fournisseur d'accès par l'intermédiaire par exemple d'une liaison ADSL. La communication entre la Radio IP 1 et la passerelle résidentielle 2 se fait alors au 35 moyen d'une liaison sans fil du type WIFI ou BLUETOOTH ou l'équivalent (par 2905488 5 exemple, courant porteur, WIMAX, mais également système WCDMA de type 3G). Bien évidemment, la radio IP 1 comporte les moyens matériels et logiciels correspondants pour permettre de telles communications. L'utilisation d'une connexion locale sans fil présente l'avantage d'autoriser un déplacement de la 5 radio IP 1 à l'intérieur de la zone couverte par la passerelle résidentielle 2. Le système selon l'invention comporte également une plateforme de service 4 connecté au réseau 3. La plateforme 4 va maintenant être décrite en détail. Cette plateforme a pour fonction essentielle de collecter les informations relatives aux ressources à partir de serveurs tiers. Ces informations ayant des 10 formats propriétaires très hétérogènes, il s'agit de mettre en forme ces informations sous un format commun, en l'occurrence le format PHOENIX, pour pouvoir les proposer à l'utilisateur via la radio IP 1. La plateforme 4 se subdivise en une partie en ligne 41 et une partie hors ligne 42. La partie en ligne 41 ( front office en anglais) va maintenant être 15 décrite en détail. Elle comporte une première interface 43 constituant une vitrine virtuelle supportant toutes les transactions avec l'utilisateur, que celui utilise sa radio IP ou un ordinateur personnel pour se connecter, via le réseau Internet, à la plateforme de services 4. La vitrine virtuelle 43 permet de répondre aux requêtes émises par l'utilisateur en allant chercher des informations dans une base de 20 données 45. Pour des tâches plus complexes, la vitrine virtuelle 43 communique avec un module appelé moteur de transactions 46. Le moteur de transaction 46 associe un identifiant à la tâche que lui demande la vitrine virtuelle 43. Il effectue cette tâche complexe en faisant les différentes requêtes adaptées sur la base de données 45. II stocke le résultat de 25 ce processus jusqu'à ce que la vitrine virtuelle 43 réémette une requête de résultat avec l'identifiant associé. Le moteur de transaction répond alors en transmettant le résultat. La vitrine virtuelle 46 communique également avec un module de paiement 44. Le module de paiement 44, qui est en fait un moteur similaire au moteur de transaction 46, communique avec un serveur tiers 50 pour tout ce qui 30 est échange d'informations confidentielles sur le paiement. Il est intéressant d'exécuter les transactions liées au paiement sur un module séparé, car les communications avec les serveurs tiers de paiement 50 sont souvent lentes et il convient d'avoir un module dédié pour répartir la charge entre les différents modules de la partie en ligne 41. Enfin, la plateforme 4 comporte un module 35 d'application dit de livraison 47. Le module de livraison 47 est une application qui 2905488 6 reçoit des messages du moteur de transactions 46 et réalise le transfert de données entre une base de données de contenu et une base de données de livraison. Le module de livraison 47 contient, de plus, un serveur http pouvant recevoir des requêtes du dispositif utilisateur pour le transfert de données. Le 5 module de livraison 47 interroge directement la base de données de livraison pour extraire les informations permettant de répondre à cette requête de l'utilisateur. La base de données 45 de la partie en ligne 41 va maintenant être détaillée. Cette base de données comporte plusieurs volumes affectés à des applications différentes. La base de données 45 comporte une base de données 10 de transactions 45a qui regroupent les informations sur les opérations complexes qui sont en train d'être réalisées ou qui ont été exécutées récemment par le moteur de transaction 46 ; une base de donnée utilisateur 45b regroupant les informations sur le compte utilisateur. Il s'agit des informations de base, notamment d'identification de l'utilisateur, et éventuellement des informations 15 d'identification permettant de se connecter, au nom de l'utilisateur, vers des serveurs tiers pour charger des contenus spécifiques auxquels l'utilisateur est abonné ; une base de donnée de profil 45c des appareils regroupant par exemple l'adresse MAC de la radio IP, la version du logiciel exécuté sur cette radio, etc. ; une base de données maître 45d ou catalogue général contenant les références 20 de toutes les ressources accessibles ; une base de données composée des catalogues utilisateurs 45e, chacun correspondant à une extraction du catalogue général. La partie en ligne 11 est également équipée de modules 40 dont la fonction sera décrite plus loin ; et la base de livraison 45f décrite précédemment. La partie hors ligne 42 de la plateforme 4 va maintenant être décrite en 25 détail. Elle comporte une base de données 45' qui est une copie de la base de données 45 de la partie en ligne 41. Cette copie qui a été réalisée à un instant T précédent, est ensuite enrichie de contenus et d'informations, soit par des procédés automatisés, soit directement par l'administrateur de la plateforme, etc. Puis, avec une fréquence d'environ une heure, une étape de synchronisation 30 permet de mettre à jour la base de données 45, les données de la base de données 45' venant se substituer à celui de la base de données 45. Plusieurs modules sont exécutés sur la partie hors ligne et fonctionnent avec la base de données images 45'. Par exemple, un module de test 48 permet, juste avant de synchroniser le contenu des bases de données 45 et 45', de 35 procéder à un ensemble de tests permettant de s'assurer que le contenu de la 2905488 base 45' est cohérent. On est là dans une démarche de qualité du fonctionnement de l'installation. Un module de statistiques 49 permet de réaliser toute sorte de calcul, comme de noter les sources audio les plus demandées, de suivre l'utilisation faite d'une radio IP particulière, etc. Des modules de contrôle 39 5 comportant par exemple des journaux stockant des informations sur les erreurs de fonctionnement de la plateforme 4 et des mécanismes d'alerte permettant l'émission d'alarme en cas de panne sévère. Mais la partie hors ligne 42 de la plateforme 4 comporte surtout un module de gestion de contenu 38 qui permet de créer et de mettre à jour le catalogue 10 général, et par conséquent les catalogues particuliers, de la base de données 45' en ajoutant de nouvelles références à des contenus, en enrichissant les méta données associées à ces contenus (prix d'un disque), etc. Pour cela le module de gestion de contenu 38 se connecte régulièrement à des serveurs tiers 51 comportant des catalogues propriétaires. Ces serveurs tiers 15 51 communiquent les informations relatives à une source particulière sous un format propriétaire associé, que le module 38 convertit automatique pour les mettre au format PHOENIX et les stocker dans le catalogue général de la base de données 45'. Le contenu de cette base de données est ensuite synchronisé avec celui de la base de données 45 pour mettre ces nouveaux contenus à la 20 disposition de l'utilisateur. Les informations distribuées par les serveurs tiers 51' qui sont destinés à avoir une durée de vie plus courte que la période de synchronisation, par exemple d'une heure, sont extraites et converties au format PHOENIX directement au niveau de la partie en ligne 41 par le module 38'. Par exemple, des informations 25 sur la météo ou des brèves, disponibles sur un serveur tiers 51' sous un format XML propriétaire (un équivalent du format RSS), sont converties puis stockées dans la base de données 45 pour être directement disponible. Enfin, l'architecture selon l'invention comporte des serveurs de contenu audio 6 aptes à émettre sur le réseau Internet 3 un flux en continu. De préférence, 30 il s'agit de serveurs Internet permettant de réaliser un streaming dynamique en fonction de la nature du terminal destinataire. L'URL de la ressource (l' Universal Ressource Locator est un pointeur vers un fichier unique de contenu audio) contenue dans la base de données 45 correspond à l'adresse IP du serveur et au chemin d'accès au fichier audio correspondant depuis le site de cette machine. Il y 35 a en général une seule URL pour chaque fichier audio accessible. Il est possible 2905488 8 d'avoir plusieurs URL pour adresser un serveur de streaming. S'il y a un échec sur la première URL, l'équipement utilisateur décide de se connecter au moyen de la 2ème URL, et ainsi de suite. D'une façon générale, lorsque l'utilisateur de la radio IP 1 souhaite écouter 5 une radio, il sélectionne le mode AUDIO . II se déplace ensuite, au moyen d'un sélecteur du type levier de commande, à travers une arborescence qui lui est proposée. A chaque niveau hiérarchique, différents menus sont accessibles. Le menu de niveau le plus bas propose une liste d'alias de ressources audio disponibles. 10 Lorsque l'utilisateur sélectionne l'alias RADIO , en appuyant par exemple sur un bouton ECOUTE , une requête au format HTTP, ayant comme paramètre l'alias RADIO , est émise en direction de la plateforme 4 via le réseau Internet 3. Après avoir extrait, de la base de données 45, l' URL_RADIO 15 correspondant à l'alias RADIO , la plateforme de services 4 répond en adressant une réponse au format XML vers la radio IP 1. Le fichier XML de la réponse comporte entre autre, comme cela sera décrit en détail ci-après, l' URL_RADIO de la radio sélectionnée. A la réception de cette réponse, la radio IP 1 se connecte à l' URL_RADIO qui lui a été indiquée et qui correspond à un 20 fichier audio qui se trouve sur le serveur 6. II y a donc émission en direction du serveur 6 d'une requête pour que soit délivrée un certain contenu correspondant à celui de URL_RADIO . Finalement, en réponse, le serveur 6 émet en continu le contenu du fichier requis vers la radio IP 1 à travers le réseau Internet 3. Avantageusement, en plus du flux de données audio, le serveur 6 peut 25 envoyer des données supplémentaires ou META DATA vers le terminal utilisateur pour que s'affiche sur l'écran des informations sur le morceau en train d'être écouté. Il peut s'agir du titre, de la durée, de l'auteur ou toute autre information directement liée au fichier audio Lors de son utilisation, la radio IP 1 offre une série de fonctionnalités. 30 La fonctionnalité du choix de la source permet, à un premier niveau hiérarchique de choisir par exemple parmi trois sources possibles de données audio : Radios en direct, Radios à la demande ou lecture du contenu d'une clé USB. On notera que la Radio IP 1 détecte l'insertion d'une clé USB et affiche automatiquement le contenu de la clé USB. Seuls les fichiers de la clé USB 35 d'extension WMA, MP3 ou WAV sont proposés dans le menu Ma clé USB . 2905488 9 L'utilisateur choisit sa source en navigant dans les menus et sous-menus. Par exemple les radios en direct sont affichées par genre, il peut choisir de les afficher par pays. Cette fonctionnalité est accessible durant l'écoute d'une source. L'utilisateur peut ainsi faire défiler les sources de la liste précédemment affichée et 5 choisir une nouvelle source. Quand l'utilisateur positionne la radio IP en mode Audio , la source précédemment écoutée est à nouveau jouée. L'écoute d'une source se poursuit tant que l'utilisateur n'a pas décidé d'arrêter ou de mettre en pause l'écoute, n'a pas choisi une autre source, ou n'est 10 pas passé en mode Configuration . L'écoute depuis une clef USB s'effectue en passant au morceau suivant quand le morceau actuel est fini. A la fin du répertoire on retourne au début. Cette boucle s'effectue sur le répertoire courant et non sur l'ensemble des fichiers de la clef USB. La fonctionnalité d'écoute d'une source qui peut d'ailleurs être activée 15 lorsque la radio IP est en mode Audio , mais également en mode Time lors du déclenchement d'une alarme, intervient lorsque l'utilisateur après avoir utilisé les flèches haut et bas du levier de navigation pour passer d'une source audio à une autre sélectionne la source actuellement dans la zone de sélection, par exemple en appuyant sur la touche Ecoute . Bien évidemment, la radio IP doit 20 être en communication avec la plateforme de services 4 via la passerelle WIFI lorsque l'utilisateur sélectionne une source puis lorsque le serveur permettant d'accéder à cette source délivre le flux continu de données. L'activation de la fonctionnalité de présélection permet, dés qu'une source est jouée, à l'utilisateur d'affecter la source à une touche Preset . Un message 25 graphique ou sonore confirme à l'utilisateur la réussite de la fonction. La plateforme de services est informée de la nouvelle présélection. La source est ainsi affectée au bouton Preset sélectionné. Au moyen de la fonctionnalité d'écoute d'une présélection, l'utilisateur peut écouter cette source directement en appuyant sur le bouton Preset , lorsque la 30 radio IP est en mode Time ou en mode Audio, sans avoir à circuler dans les menus et les sous-menu de l'interface. On notera que l'utilisateur ne peut pas affecter à une touche Preset , un fichier de sa clé USB. On notera que si la source est sur la clé USB, celle-ci doit être connectée à la radio IP et que si la source est une source Internet, la radio IP doit être en communication avec la 35 plateforme de services via la passerelle WIFI. 2905488 10 La radio IP dans le mode de réalisation actuellement envisagé comporte également une fonctionnalité de réglage du volume qui est activée par l'utilisateur quelque soit le mode dans lequel la radio IP se trouve. L'utilisateur modifie le volume sonore de la radio IP avec le ou les boutons correspondants de 0% à 5 100%. Une fonctionnalité d'égaliseur permet à l'utilisateur, lorsqu'une source audio est jouée, de modifier le niveau de basses et/ou le niveau d'aigus. Il peut valider ou abandonner les modifications faites. En conséquence, les niveaux d'aigus et/ou de basses sont immédiatement mis en conformité avec les réglages choisis par 10 l'utilisateur. Les niveaux d'aigus et de basses sont sauvegardés dans la base utilisateur lorsque la radio IP est mise hors tension et peuvent être spécifiques à chaque source audio. L'utilisateur peut choisir de rajouter le titre actuellement écouté dans une liste de coups de coeur . Si le nombre de coups de coeur de la liste a atteint un 15 nombre maximum, par exemple 100, le coup de coeur le moins récent est supprimé. Un message affiché pendant 5 secondes, confirme à l'utilisateur l'ajout du titre au coup de coeur. Le titre est donc ajouté dans la liste de coups de coeur et les informations suivantes sont enregistrées dans la radio IP puis transmises à la plateforme de services : meta-data ; nom de la radio ; date et heure de 20 l'enregistrement en tant que coup de coeur ; musique achetée : oui/non (non par défaut) ; code d'achat (pas de code par defaut). Pour cette fonctionnalité, la radio IP doit être en communication avec la plateforme de services L'utilisateur peut également choisir de supprimer un coup de coeur. Pour cela l'utilisateur active cette fonctionnalité après avoir sélectionné un coup de 25 coeur dans la liste des coups de coeur en mode Audio . Le titre correspondant est supprimé de la liste. La plateforme de services est informée de cette mise à jour de la liste des coups de coeur et la réplication de la liste des coups de coeur dans la base de données utilisateur est synchronisée. La radio IP doit être en communication avec la plateforme de services via la passerelle WIFI. 30 En variante, l'utilisateur peut choisir de supprimer tous les coups de coeur de la liste. Un utilisateur qui allume son poste ou sélectionne une nouvelle radio s'attend à ce qu'un contenu soit immédiatement diffusé. L'utilisateur a le sentiment d'un dysfonctionnement au-delà d'une seconde d'attente. 2905488 11 Avantageusement la radio IP met en oeuvre une ou plusieurs des stratégies suivantes pour diffuser immédiatement un contenu. Lorsque l'utilisateur navigue dans le menu, la radio IP se connecte aux X meilleures sources, c'est-à-dire par exemple les X sources les plus souvent 5 écoutées par cet utilisateur particulier. En tâche de fond, la radio IP effectue la lecture des sources correspondantes. Lorsque l'utilisateur sélectionne en effet une radio x, la lecture de la source correspondante se poursuit avec la diffusion du programme correspondant, alors que les X-1 autres tâches de lecture de flux de données sont suspendues. En fonction de la bande passante disponible à 10 l'instant considéré et du taux de compression des données lues depuis les diverses sources, le nombre X est recalculé à chaque fois et peut donc varier. En variante, les premières secondes des X sources sont enregistrées sur la plateforme de services. Lors de la sélection d'une source particulière, ce fichier de quelques secondes est transféré depuis la plateforme vers la radio IP pour une 15 lecture immédiate. Ces quelques secondes donnent le temps à la radio IP d'accéder au serveur de la ressource et à celui-ci de débuter l'émission du contenu audio. Dès la réception des premières données en provenance du serveur, la radio IP bascule de la lecture du fichier initial à celle du flux de données. Le basculement peut être à l'origine d'une microcoupure dans l'audition 20 du contenu. Dans cette variante de réalisation, la bande passante depuis le serveur doit être importante et ce dernier doit être apte à supporter une charge plus volumineuse. La radio IP peut également permettre de rediriger le flux de données audio vers, par exemple, un téléphone portable. Chaque radiolP est identifiée par un 25 numéro de téléphone VoIP. Le téléphone portable effectue un appel vers ce numéro et reçoit le flux joué sur la radiolP au moment où il se connecte, la radio IP redirigeant, en temps réel, le flux de données sous un format codé satisfaisant au protocole de voix sur IP. La radio IP peut décoder l'appui sur les touches du téléphone portable (dtmf) de façon à ce que l'utilisateur du téléphone puisse 30 naviguer à distance à l'intérieur du menu de la radio IP pour modifier,par exemple, la source audio écoutée. La radiolP peut également être équipée d'un microphone. Le signal sonore capté par ce microphone est transmis via le réseau Internet (voix sur IP) vers la plateforme de service. Celle-ci redirige le flux d'information vers l'application ou le 35 service adapté. Par exemple, un serveur vocal intégrant un moteur de 2905488 12 reconnaissance vocal, construit à partir d'informations extraites de la base de données de catalogue une réponse donnant l'adresse d'une ressource audio demandée par l'utilisateur. Le catalogue général et le catalogue personnel d'un utilisateur contiennent 5 des informations dites de classement éditorial qui sont associées à chaque source accédée. Par exemple, on peut calculer un indice de popularité d'une source du catalogue général en faisant le rapport de la durée totale d'écoute de cette source sur la durée totale d'écoute de l'ensemble des sources de la même catégorie ou du même type pendant par exemple un mois. Un autre exemple 10 d'indicateur général peut être une note technique sur la qualité du serveur de contenu. A chaque fois qu'un utilisateur échoue à lire un contenu en provenance d'un serveur, la radio IP envoie une notification à la plateforme de services. La plateforme détermine alors une note technique en comptabilisant le nombre de notifications concernant un même serveur durant une période de temps donnée. 15 Une note technique trop faible permettra à l'administrateur de la plateforme d'éliminer de la base de données les sources correspondantes et d'avertir l'administrateur du serveur tiers défaillant. Des indicateurs personnels peuvent également être déterminés tels qu'une note de satisfaction donnée par l'utilisateur lors de l'écoute d'une source, ou une 20 information sur la fréquence d'accès à une source particulière par rapport au différentes ressources du catalogue personnel de l'utilisateur accédées durant une période prédéterminée. Ces informations personnelles sur le comportement de l'utilisateur autorisent une gestion automatique du catalogue personnel, cette gestion automatique venant en plus de la gestion directe par l'utilisateur via une 25 interface Internet de son catalogue personnel. Ainsi, si les sources d'une même catégorie sont bien notées, on peut proposer à l'utilisateur des sources similaires qui ont reçu une bonne note de la part d'autres utilisateurs. Si une source a une note trop faible durant une période de temps supérieure à trois mois, la source correspondante peut être automatiquement supprimée. Elle est éventuellement 30 remplacée par la source du catalogue générale ayant une bonne notation selon les mêmes critères. Le cas échéant, lorsque toutes les sources d'une catégorie sont mal notées, l'ensemble de la catégorie peut être automatiquement supprimée du catalogue personnel de l'utilisateur. Elle ne sera donc plus présentée sur le menu de la radio IP. Cette fonctionnalité est par exemple intéressante pour faire 35 évoluer le menu et en particulier faire évoluer le menu initial présenté sur la radio 2905488 13 IP juste après qu'un nouvel utilisateur se soit identifié. Au fur et à mesure de l'utilisation de la radio IP, des catégories que cet utilisateur n'apprécie pas seront supprimées de façon à simplifier la navigation à travers le menu. En variante, le menu peut être modifié de manière dynamique en présentant d'abord les 5 catégories ou les ressources les mieux notées. Nous allons maintenant détailler les formats des échanges entre la radio IP 1 et la plateforme de services 4. L'adresse DNS de la plateforme 4 est RadiolP.phoenix.net. Cette adresse est un exemple et doit être remplacé par l'adresse DNS réelle de la plateforme utilisée. 10 En-tête HTTP Toutes les requêtes émises par la Radio IP 1 vers la plateforme 4 sont de type HTTP GET avec la présence systématique d'un en-tête HTTP qui est détaillé dans le tableau I ci-dessous. Tableau I Nom: Format Description exemple_contenu HTTP_USER AGENT: Spécifique : "Iiveradio/" User-Agent spécifique à la Radio IP Iiveradio/1.0 suivi du numéro de version du logiciel de la Radio IP HTTP_MAC_ADDRESS: String(12)[0-9][A-F] Adresse MAC de la Radio IP 0123456789AB HTTP_LOCATION: fr String(2) Langue configurée sur la Radio IP : fr = français / en = anglais /sp = espagnol / etc. HTTP_TIME: +01:00 String(5)[+][0-9][:][0-9] Fuseau horaire configuré sur la Radio IP : décalage par rapport à l'heure GMT en heures:minutes HTTP_RADIO String(32)[0-91[A-F] Mot de passe de synchronisation calculé à IP_PASSWORD: partir du jeton affecté à la Radio IP par la 00112233445566778899AABB plateforme 4 lors de son enregistrement. CCDDEEFF HTTP_RADIO IP_SALT: 1234 String(1..16)[0-9] Sel utilisé dans le calcul du mot de passe de syncronisation. Ce sel doit toujours être incrémenté d'au moins une unité entre 2 appels à la plateforme 4 par la Radio IP HTTP_RADIO IP_MENUIDS: String(0..8096)[0-9][,] Liste d'identifiants de menus (Menu/D) 0,1,10,101 séparés par des virgules auquels la Radio IP a accédé et affiché à l'utilisateur sur l'écran de la Radio IP. Les requêtes faites en background pour la mise à jour du cache ne sont pas ajoutées à cet en-tête. 15 Demandes d'informations Le format des paramètres GET dépend du type de requête réalisé. Mise à jour automatique de la date et heure : 2905488 14 //Radio IP ù phoeni,.net/SvoRac T_p.php:WRequest=C Time La plateforme 4 envoie en réponse un document XML selon la grammaire Phoenix 1.0.0 (XML-P) contenant l'élément comme cela sera détaillé ci-après. 5 Récupération du contenu d'un menu : http:/,Radio IF. hhonix. nt SvcPadio IP.Php?WPéquest-Menu&WMenuLD La plateforme 4 envoie en réponse un document XML-P contenant l'élément où _M_ est remplacé dans la requête et la 10 réponse par l'identifiant unique du menu souhaité. La valeur _M_ = 0 est utilisée pour désigner le menu principal, noeud de départ de l'ensemble des menus. Récupération de la liste de présélections de la Radio IP hthp:' Padic IP.phooni._.,i IF-pip?uR l ,t=PrPs La plateforme 4 envoie en réponse un document XML-P contenant 15 l'élément . Récupération de la liste de coups de coeur de la Radio IP Y.ttp: i /Radio IP.ph_éni n. t!>vçP h IF.ph hT -qu =P.DUT' La plateforme 4 envoie en réponse un document XML-P contenant l'élément . 20 Récupération de la liste du flux d'informations Titi p: /, Fedit IP.p1 oeni t, ;cRadio TP.ph ,?WRequest=Infus La plateforme 4 envoie en réponse un document XML- P contenant l'élément . Regénération du cache de la Radio IP http:/;Patio IP.phoeni.nIP.php?WRequest=Cache J La plateforme 4 envoie en réponse un document XML-P contenant l'élément . Cette requête permet à la Radio IP de demander à la plateforme 4 les N derniers menus accédés pour régénérer sa mémoire cache après un redémarrage. Dans le mode de réalisation préféré, N est égal à 100. Modifications des données personnalisées de la Radio IP Modification d'une présélection de la Radio IP http!/Padio IP.phoeni n cPa dio .php?WRequést SetPreset&FButton B &WM nuID= M 35 _B_ et _M_ représentent respectivement l'identifiant du bouton de la Radio IP (1 à 8) et l'identifiant unique du menu (défini par la plateforme de services). La plateforme 4 envoie en réponse un document XML-P contenant l'élément . Ajout d'un coup de coeur de la Radio IP 25 30 2905488 http:/Radio IP.phoenix.net/â Ih.php?WRequest AâdFavDurite&t'I[1ennI15 c Radio &WMetaDat _M_ et TEXT_ représentent respectivement l'identifiant unique du menu dans lequel la radio sélectionnée en tant que coup de coeur a été présentée à 5 l'utilisateur et le contenu de la meta-data associée au coup de coeur. La plateforme 4 envoie en réponse un document XML-P contenant l'élément . Suppression d'un coup de coeur de la Radio IP http:i'P dio IP.phoeni ..n t, ,T.rcl . Suppression de tous les coups de coeur de la Radio IP 15 hi p://Pedro IP.phoeni _.n t/ ,cRidic .php?W e i est=DelA11F i -oüri tes La plateforme 4 envoie en réponse un document XML-P contenant l'élément . 20 Réception de la réponse HTTP au format XML Si la réponse HTTP est le code 200, toute réponse faite par la plateforme 4 auprès de la Radio IP 1 est au format XML-P décrite dans ce document. Sinon, seul le code erreur HTTP est transmis selon le protocole HTTP habituel. 25 la grammaire XML Phoenix 1.0.0 La grammaire XML Phoenix XML-P va maintenant être décrite en détail. Elément principal Exemple au format XML 30 Ph nih érsion="1.0.0 Phoenix Fonctions Elément principal de la grammaire Phoenix. Sa présence est systématique 35 quelque soit le type de requête fait par la Radio IP. En cas de succès, il doit contenir l'authentification un élément de type Cache, et éventuellement un élément de type Menu ou Presets ou Favourites ou Infos ou DateTime. 5 10 2905488 16 En cas d'erreur, il doit contenir un unique élément Authentication. Description du contenu Noeud Champ A/E Format Nb Description Version A String(5) 1 Version de la grammaire = 1.0.0 Authentication E Conteneur 0 / 1 Informations d'authentification. Sa présence indique soit une erreur, soit une demande de resynchronisation du mot passe par la plateforme de services. Cache E Conteneur 0 / 1 Gestion du cache. Indique que le cache doit être mis à jour. Menu E Conteneur 0 / 1 Browsing Audio. Retourné dans le cas d'une requête de Browsing Audio. Mutuellement exclusif avec les éléments Presets, Favourites, Infos et DateTime. Phoenix Presets E Conteneur 0 11 Gestion des présélections. Retourné dans le cas d'une requête de listage ou modification de présélections de radios. Mutuellement exclusif avec les éléments Menu, Favourites, Infos et DateTime. Favourites E Conteneur 0 / 1 Gestion des coups de coeur. Retourné dans le cas d'une requête de listage, ajout ou suppression des coups de coeur. Mutuellement exclusif avec les éléments Menu, Presets, Infos et DateTime. Infos E Conteneur 0 / 1 Gestion du flux d'informations. Retourné dans le cas d'une requête de lecture du flux d'information. Mutuellement exclusif avec les éléments Menu, Presets, Favourites et DateTime. DateTime E Vide 0 / 1 Gestion de la date et l'heure. Retourné dans le cas d'une requête de mise à jour de la date et heure. Mutuellement exclusif avec les éléments Menu, Presets, Favourites et Infos. Elément Exemples au format XML Resynchronisation TextLine Position=>demandée rrc>r Co~1~=rr2'ir, _ t11ne os' tlnn=rr-trr-..,: ief1_1_r ,'TextT,Tiç Jrror Autl- enti~ati n> 'Pho n~ Fonctions Elément retourné à la suite d'une erreur d'authentification ou d'une demande de resynchronisation de la part de la plateforme quelque soit la requête 20 faite par la Radio IP. Description du contenu Noeud Champ E/A Format Nb Description Authentication Error E Conteneur 1 Décrit l'erreur d'authentification. Synchronization E Conteneur o i 1 Conteneur des informations de resynchronisation. Est présent si Error.Code vaut 1. Error Code A Entier 1 Code erreur défini par la plateforme 4suite à un signé problème d'authentification. 32bits La valeur 1 est réservée à la demande de resynchronisation. Dans ce cas, l'élément Synchronization doit être présent. TextLine E String(1 à 1 à 4 Décrit l'erreur d'authentification. 63) Le nombre de caractères maximum d'une ligne dépend de la taille variable des caractères de la police. Une ligne peut au minimum afficher 20 caractères et au maximum 63 (ligne alors composée de 63 caractères 'i'). TextLine Position A Entier 1 Position de la ligne de texte statique à afficher sur non signé l'écran de la Radio IP. 8bits Les valeurs autorisées sont 1, 2, 3 et 4. 5 10 15 5 10 15 2905488 18 Noeud Champ E/A Format Nb Description Synchronization DefaultRadio E String(32) 1 Mot de passe par défaut de la Radio IP utilisé en IP Password sortie d'usine. II vaut: HashMD5(AdresseMAC + secret partagé). Le secret partagé n'est pas écrit dans ce document pour des raisons de sécurité. Ce mot de passe est nécessaire pour s'assurer que c'est bien la plateforme 4qui demande une resynchronisation. SetNewRadio E String(32) 1 Nouveau Token à utiliser par la Radio IP pour le IPToken calcul du mot de passe de synchronisation. Ce mot de passe vaut: HashMD5(AdresseMAC + secret partagé + Radio IPToken + HTTP_RADIO IP_SALT) Elément Exemples au format XML 12 34 35 ( ) 20 Fonctions 25 Cet élément est retourné quelque soit la requête faite par la Radio IP à partir du moment où l'authentification est réussie. II permet de maintenir à jour le cache de la Radio IP de façon optimisée. Le décompte du délai de validité de chaque type d'éléments (attributs ValidityMenus, ValidityPresets et ValidityFavourites) est remis à zéro dès qu'une réponse XML avec un élément 30 Cache est reçu. La liste des MenulD retournés pour la mise à jour est la liste des identifiants des menus modifiés sur la plateforme 4 entre la dernière requête de la Radio IP et 10 15 2905488 19 la requête actuelle. A charge à la Radio IP de vérifier si ces MenulD sont définis dans son cache et d'effectuer les requêtes de récupération des menus en tâche de fond pour leur mise à jour. Description du contenu Noeud Champ E/A Format Nb Description Entier Délai en secondes pendant lequel le cache des ValidityMenus A signé 1 menus reste valide. Passé ce délai, il faudra 32bits s'assurer de la mise à jour du cache en faisant une requête de récupération de menu. Délai en secondes pendant lequel le cache des Entier présélections reste valide. Passé ce délai, il ValidityPresets A signé 1 faudra s'assurer de la mise à jour du cache en 32bits faisant une requête de récupération de la liste des présélections. Cache Validity Délai en secondes pendant lequel le cache des coups de coeur reste valide. Passé ce délai, il Favourites A Entier 1 faudra s'assurer de la mise à jour du cache en signé faisant une requête de récupération de la liste 32bits des coups de coeur. MustUpdate E Conteneur 0 1 Indique que le cache de certains menus doit être / Menus mis à jour sur la Radio IP. MustUpdate E Vide 0 / 1 Indique que le cache de la liste de présélections Presets doit être mis à jour sur la Radio IP. MustUpdate E Vide 0 / 1 Indique que le cache de la liste des coups de Favourites coeur doit être mis à jour sur la Radio P. Entier MustUpdate Menu ID E 1 à Identifiant unique du menu à mettre à jour dans Menus signé n le cache de la Radio IP 32bits 5 Elément Exemples au format XML SPI ' nix Version ="1.0.0 ~he Ta] iditMenus=" a]_idlt .: Prc set. aliditPa~icari t as "2O" / Menu MenulD "10" Tit1e="Genre Ica r Bac'_Men,iID= MenuItem Nenulb "12" Titl~ dio IconID= -Nenultern MenulD 34 Ttt] "Radio 2" IconID="G' 'Ph' eni3 ':Phoeni O" ~Iali dit äPrese 2905488 20 Fonctions Cet élément est retourné lors d'une requête d'informations de contenu d'un menu que ce soit lors du premier accès à ce menu ou lors de la mise à jour du cache. 30 Un menu est identifié de manière unique par un attribut Menu1D défini sur la plateforme de services. Description du contenu Noeud Champ E/A Format Nb Description Menu Entier Identifiant unique du menu défini par la Menu ID A non signé 1 plateforme de services. 32bits i La valeur 0 indique le premier menu visible. String(1 à Titre du menu. Le nombre de caractères maximum dépend Title A 63) 1 de la taille variable des caractères de la police. Une ligne peut au minimum afficher 20 caractères et au maximum 63 (ligne alors composée de 63 caractères 'i'). Entier Type d'icône associé au menu: IconlD A non signé 1 0 = pas d'icône 32bits 1 = icône dossier 2 = icône note de musique MenülD="35" Title="Radie IconÏD="2" B r_MenrulD='rle treamDe.script?n TextLine trëamUC.L Ho_f="re stréam.net~r ILUU e ="1 .2, .4'! Port /redite . StreIn. neti tY _ amUPL.'' Stre rnUP.L Hos t "r-idio3. , trea l.. OITT" IPUJ egPort= radio 3. re-rn corn/ ra4i~, i;tream[1nL l >MP Pori-Ela 17P tr' Tbenne _ts '2 P/Channel s > amp eR.a1 e>44100'~~ / ~,rnplRat -_Dureti on-180 / Phoenix> idit Favottrite Exemples au format XML ,Ph enix Vers ion="1..0"> Il 2905488 23 Cache alidit enlise 90' Validit a.=durite Fonctions Cet élément est retourné lors d'une requête d'informations de contenu de la liste de présélections ou de modification d'une présélection. 25 A chaque présélection de la Radio IP est associé un MenulD correspondant à la description d'un flux de contenu audio. Description du contenu Noeud Champ E/A Format Nb Description Presets Preset E Vide 8 Présélection de flux de streaming audio. Preset Button A Entier 1 Identifiant du bouton de présélection de la non signé Radio IP. 8bits Valeurs autorisées: 1, 2, 3, 4, 5, 6, 7 et 8 Menu ID A Entier 1 Identifiant unique du menu défini par la non signé plateforme de services. 32bits Title A String(1 à 1 Titre du menu présélectionné. 255) Le nombre de caractères maximum pouvant être affiché sur une ligne dépend de la taille variable des caractères de la police. Une ligne peut au minimum afficher 20 caractères et au maximum 63 (ligne alors composée de 63 caractères 'i'). Si tous les caractères ne peuvent pas être affichés, la ligne sera scrollée lorsqu'elle sera sélectionnée. 10 15 Preset Puttri[1eni~IF="4 Titl ='Pn4io Fr` 5 2905488 24 Noeud Champ E/A Format Nb Description IconlD A Entier 1 Type d'icône associé au menu présélectionné: non signé 0 = pas d'icône 32bits 1 = icône dossier 2 = icône note de musique Elément Exemples au format XML _Pheeni Ve sion=rrl rrr: F ti /curit F _I iour~ eTri=i'1^ Titl "Autenr 1 1îan. Cr-, ?:"> T 3{f L1ne Po1f in =rr1rr rrAuteur 1 r~73Ii.son 10 'TetLin etLine sit i_on ".% écoilt 2X)06': ,'Te tLi 15 TeetLine P 'iti.on =rr rr ,e 10h?, 'Te tLine Tet tLine P~ s tirse i P i W7 Ter Line'> F rourite> ~.3`7C?11r1~e C .-ouriteI>=rr1 Jrr T7 1 .c' "Aut"ur 1 nsen i rr 2006e/Tri-_ni n rr ' 7 L> n,- Fosttlon_ - ~ ,.uteur r}iansor: n .2 n T iPr;sit? on _~'~_ltn 7 ~ Ci3 fé;-ri_er 20 25 30 Tee Lin'' nr 1l_1UII " rr il '% T :;tL1no eTe, tU_ 1 F sit en- l' ur Pet tF T tLinn 'F-1-nürit -F 3vourl t ~ci'TOuaJ tcI ï`.1' Title- sur 3 - CLe: n Té? Liner Pos.iti I1=Tri" sur F:?nse Inter 2006 "/Te-_tLi n Fa 5 10 15 20 2905488 Description du contenu Noeud Champ E/A Format Nb Description Favourites Favourite E Conteneur 1 à n Coup de coeur de la Radio IP. FavouritelD A Entier 1 Identifiant unique du coup de coeur défini par la non signé plateforme de services. 32bits Favourite Title A String(1 à 255) 1 Titre du coup de coeur. Le nombre de caractères maximum pouvant être affiché sur une ligne dépend de la taille variable des caractères de la police. Une ligne peut au minimum afficher 20 caractères et au maximum 63 (ligne alors composée de 63 caractères i). Si tous les caractères ne peuvent pas être affichés, la ligne sera scrollée lorsqu'elle sera sélectionnée. TextLine E String(1 à 255) 4 Lignes de texte à afficher sur l'écran de la Radio IP pour qualifier le coup de coeur. La première ligne est scrollée si tous les caractères ne peuvent pas être affichés. Les 3 autres lignes sont statiques. Le nombre de caractères maximum d'une ligne dépend de la taille variable des caractères de la police. Une ligne peut au minimum afficher 20 caractères et au maximum 63 (ligne alors composée de 63 caractères 'i . Entier Position de la ligne de texte statique à afficher sur TextLine Position A non signé 1 l'écran de la Radio P. 8bits Les valeurs autorisées sont 1, 2, 3 et 4. Elément Exemples au format XML Exemples au format XML Phoenix ersion="1.0 ache al lity Menu 5 Val' F Durite- '2 Fonctions Cet élément est retourné lors d'une requête demise à jour automatique de 10 l'heure et de la date. Description du contenu Noeud Champ E/A Format Nb Description DateTime Date A Date jj/mm/aaaa 1 Date à mettre à jour. GMTTime A Heure 1 Heure à mettre à jour. hh:mm:ss Gestion du cache de la radio IP Le cache ou mémoire cache est un volume mémoire de taille restreinte 15 permettant de stocker sur la radio IP 1 des éléments sur l'historique de son utilisation. II a pour but de réduire le temps de latence lors de la navigation dans les menus de la Radio IP 1, de permettre un fonctionnement même si la plateforme n'est pas disponible (par exemple en assurant un service minimum vers les serveurs de radios dont l'adresse a été mise en cache), et de réduire la 20 charge de la plateforme de services en limitant le nombre de connexions. Dimensionnement du cache La taille mémoire SDRAM réservée au cache de la Radio IP 1 est de 500Ko ce qui doit permettre, en estimant une moyenne de 5Ko par élément mis en cache, de sauvegarder en mémoire de 100 éléments. II existera beaucoup plus de 25 100 éléments possibles à mettre en cache, cependant après une phase de 2905488 28 découverte de la Radio IP, on peut estimer que l'utilisateur écoutera toujours le même type de contenu audio et qu'il parcourra de manière quotidienne moins de 100 menus. Le cache n'est pas sauvegardé dans la mémoire FLASH de la Radio IP 1 5 ce qui permet d'optimiser la taille de la mémoire FLASH nécessaire et d'augmenter le temps de vie de cette mémoire dont on sait que le nombre d'écritures est limité à 100000 environ. Elément mise en cache Le cache de la radio IP selon l'invention comporte trois types d'éléments : 10 le contenu des menus récupérés sur la plateforme 4 lors de la navigation de l'utilisateur: chaque menu mémorisé est indexé dans le cache par son identifiant unique Menu1D défini par la plateforme. Le cache stocke le contenu de l'élément XML .; On rappelle que le répertoire le plus bas de l'arborescence est une liste nom plus de menus mais d'alias de fichiers audio 15 accessibles. Cette liste est considérée comme un menu ; le contenu de la liste des présélections de la Radio IP : la liste des présélections de la Radio IP est stockée dans le cache de manière globale (correspondant à l'élément XML et est remplacée entièrement dès que cela est nécessaire ; 20 le contenu de la liste des coups de coeur de la Radio IP : la liste des coups de coeur de la Radio IP est stockée dans le cache de manière globale (correspondant à l'élément XML ) et est remplacée entièrement dès que cela est nécessaire ; En revanche, l'élément XML 25 qui décrit le flux d'informations n'entre pas en considération dans la gestion du cache de la Radio IP car sa mise à jour est systématique et est réglée périodiquement en fonction de l'attribut _TIME . Information de mise à jour du cache L'élément XML est systématiquement retourné par la plateforme 30 de services quelque soit la requête faite par la Radio IP, à partir du moment où l'authentification est réussie. Cela permet de maintenir à jour le cache de la Radio IP de façon optimisée. Comme indiqué ci-dessus, l'élément XML comporte les attributs ValidityMenus, VaildityPresets ou ValidityFavourites qui indiquent le délai de validité de chaque type d'élément du cache. Le délai de 2905488 29 validité est remis à zéro dès qu'une réponse XML contenant un type d'élément à mettre à jour est reçue. Comme indiqué ci-dessus, le cache n'est pas sauvegardé lorsque la Radio IP est mise hors tension. La plateforme de services sauvegarde chaque accès à 5 un menu depuis la Radio IP. A chaque remise sous tension, la Radio IP émet une requête de régénération du cache pour connaître la liste de éléments à remettre dans son cache. La plateforme répond en donnant, par exemple, la liste des MenulD nécessaires pour générer à nouveau le cache. La Radio IP émet ensuite le nombre de requêtes nécessaires auprès de la plateforme de services pour 10 récupérer chaque élément. Dans le cas particulier de la première mise sous tension de la Radio IP en sortie d'usine, le cache de la Radio IP est vide. Après enregistrement de la Radio IP auprès de la plateforme de services, et après la première requête HTTP GET de régénération du cache, l'élément XML est renvoyé pour indiquer la 15 mise à jour de la liste des coups de coeur, la liste des présélections ainsi que le menu dont le MenulD est égal à 0 : il s'agit du menu de base ou racine de la navigation audio. Cela permet à la Radio IP de récupérer immédiatement des données personnalisées dont les valeurs initiales correspondent à un profil par défaut. 0 !LienulD. MZistUj dateMenus> t,7ue ript Pres'e}s,' 1ustUI_d.atere qui 5 indique que d'autres éléments doivent être mis à jour en tâche de fond sans que l'utilisateur n'ait à s'en préoccuper. Si la réponse est obtenue en plus de 1 seconde, le résultat est affiché à l'écran à partir du cache. Lorsque la réponse arrive en tâche de fond, elle est traitée normalement pour la mise à jour du cache mais on ne modifie pas l'affichage sur l'écran pour ne pas perturber l'utilisateur. Si 10 une nouvelle requête est émise avant l'arrivée de la réponse en tâche de fond, elle suivra le principe du délai expiré. Si, en revanche, le délai de validité du type d'élément n'est pas expiré, le résultat est affiché à l'écran à partir du cache. Aucune requête n'est émise vers la plateforme. Le gestionnaire de cache sauvegarde l'information que tel menu a été 15 accédé pour en informer la plateforme lors de la prochaine requête avec un délai expiré. Le délai de validité est un paramètre dont la valeur est décidée sur la plateforme et est attribuée par type d'élément : menus, présélections et coups de coeur. Si la Radio IP utilise un profil par défaut, ce délai de validité peut être 20 augmenté en le portant d'une minute à une dizaine de minutes voir à une heure, car seul l'administrateur de la plateforme peut modifier le contenu des menus. La Radio IP est forcément à l'initiative de modifications des présélections et coups de coeur : elle peut donc les prendre en compte sans faire de requête supplémentaire. Si la Radio IP utilise un profil utilisateur pouvant être modifié par 25 l'utilisateur sur la plateforme (en accédant à la plateforme par un ordinateur personnel connecté au site utilisateur de la plateforme), même en gardant un délai court, le principe reste intéressant sur le plan de la charge de la plateforme. De plus, lorsque l'utilisateur est connecté via son ordinateur personnel au site utilisateur de la plateforme pour modifier son profil Radio IP, la plateforme peut 30 attribuer un délai de validité nul aux prochaines requête tant que l'utilisateur n'a pas fermé sa session sur le site utilisateur. Cela permet d'assurer que toute modification faite par l'utilisateur sur son profil Radio IP est prise en compte immédiatement sur sa Radio IP. 2905488 31 Modifications intervenues sur la plateforme II se peut par exemple que l'administrateur de la plateforme modifie les menus. Dans ce cas, une liste des identifiants MenulD des menus modifiés sur la plateforme de services entre la dernière requête de la Radio IP et la requête 5 actuelle est retournée par la plateforme en vue d'une mise à jour. La Radio IP ignorera l'information de mise à jour pour les menus auxquels elle n'a pas accédé et émettra des requêtes de récupération du contenu des menus uniquement pour ceux qui étaient dans son cache. Pour remplir correctement cette liste des identifiants MenulD des menus modifiés, la plateforme de services doit 10 sauvegarder la date et l'heure de la dernière modification de chaque menu et la date et l'heure de la dernière requête faite par la Radio IP. Elle ne renvoie ainsi à la Radio IP qu'une seule fois la liste des éléments modifiés. Gestion des statistiques d'accès aux menus Si certains éléments du cache doivent être mis à jour suite à la réception 15 d'un élément dans une réponse XML, le gestionnaire de cache de la Radio IP émet des requêtes en tâche de fond sans en informer l'utilisateur. Dans ce cas particulier, l'en-tête HTTP_RADIO IP_MENUIDS n'est pas émis. Dans tous les autres cas, l'en-tête HTTP_RADIO IP_MENUIDS est émis avec la liste des menus accédés à partir du cache depuis la dernière requête 20 HTTP émise par la Radio IP. Si c'est une requête de récupération de menus qui est émise, le MenulD de ce menu est inclus en dernier élément de la liste de l'en-tête HTTP RADIO IP MENUIDS. L'utilisation de la Radio IP est donc la suivante : l'utilisateur qui souhaite écouter une radio, la met en mode audio. II lance directement une présélection ou 25 navigue dans les menus préférés pour sélectionner une radio. La durée de cette sélection peut être estimée à quelques dizaines de secondes. II essaye quelques radios puis décide d'en écouter une pendant quelques minutes ou plus. Même avec un délai de validité court, par exemple d'environ 90 s, la charge de la plateforme de services est réduite car seul le premier accès (éventuellement 30 inutile) est réalisé suivi de quelques accès utiles pour regénérer le cache de la Radio IP. Si on considère que l'utilisateur parcourt régulièrement 10 genres et teste au plus 20 radios lors de sa sélection, le système de cache permet à la Radio IP 2905488 32 de n'effectuer qu'une seule requête auprès de la plateforme de services au lieu des 30 systématiques. En conséquence de cette gestion particulière de la mémoire cache, la charge de la plateforme de service est avantageusement fortement diminuée. 5 Par ailleurs, quelque soit la requête faite par la Radio IP auprès de la plateforme de services, la réponse XML peut contenir un élément . Ceci permet de mettre à jour rapidement des éléments présents dans le cache de la Radio IP même si l'utilisateur n'y a pas encore accédé. Ce mécanisme permet en outre de ne pas faire de connexions périodiques systématiques mais de profiter 10 des connexions utiles pour gérer le contenu du cache. En conclusion, la requête de régénération du cache de la Radio IP permet d'une part d'optimiser la taille mémoire nécessaire sur la Radio IP ainsi que sa durée de vie s'il s'agit d'une mémoire du type FLASH, et d'autre part de ne perdre aucune information utilisateur si la Radio IP est réinitialisée selon les paramètres 15 par défaut d'usine. Exemple d'utilisation Les étapes suivantes s'enchaînent chronologiquement. Régénération du cache lors de la mise sous tension de la Radio IP _ I ht tç /Radio IP phoeni net/.DvcRadio IP. php?Deque$t=Cache 20 http:!/Radio IP.phoenix.net/SvcRadio lP.php?WRequest=Menu&WMenuID=O ,.Phc ni Version 1.0 Menu MenuID="0" Title "Ménu" Iton ID "0" F~ MenuItemMonuÎD Title="Radies Liie 'Menultem MenulDù" " II l ù"Radies a la ersion1.0.0 Cache J .iditLLtlemu ="`00 alidit1c- a1rdit P urates="20 L1ustUpdateMeni 0 "; Meeulp> l ./MenUI > NÎenuIL V fl "/Men,~ID MenulD>101_/MenulD /MustUpdalteP1enus i1ustrlphatePreS ,t_, MustUpdatéPa-.rorit /Cache> Phoeniy> phDerni T 25 30 35 40 90 pl sets ?o. ckhccnul D "C IcbnÏD= carte". 5 10 2905488 33 ïMenulteIll. l`lenulD='r J'r T1t1 "Ser 1ces ~)Yan http:/!Radio IP.phoenix.nét,'O i0o IF ph _WRé~Iuest Menu&WMénulD-= /Phoeni 15 Ment 'MenuIem P"euulf10 Titlu enre 1" Tc ;n1D=rr P'Ierlulturi 'I nll!.r rr J Jirr Tille= ,i,n IC rT_D= ,Ilénul}ém IIéniïlP "3C," Tui le Tenr. IconID=.'~ ,k MlenoID 20 25 30 35 40 50 http://Radio IF.phoehl _.het F I:? p?UReouest=Menu&UMenuIF Ir Phoenix 'ersion act:é `Iall^ tl~n~.Is alidit Fi uriteo="10" ~'. Q -Iénu MennID10" Title=PInti" Ir nÎD="1." F ,~1P"enu?P 1 rra ~MenûIté n Mc nuiC, "100" IL Je= P dio 1 ci I -IlérluÏtem tieni.IlD="101" Titl = P_;ci , 1_" I P="; /> MenuItum MenuOID='Iâ2" T-rl e F-idlo 1" I irlD= /> Menin http:/ alio IF.phoenix.net SvcPîdio ?l'?R.-quest Menuc IIeIIuÏ0=101 Caca; y,.1iditvPa ourites 0ä I'len~ NenuÏD="loi Ti Clé="P 'II o 1 " Ïi cnID= P. a MenulD="10" treamDéscriptioi IP.p ;oca htt /radios.stream. 1 trealaType om rida 1 StreaMbR.L:> lidit . Fr set-="20" 2905488 5 34 Arecs. /Ace "Format > 1P_ /Forma _1 c0iP1 127 ? /Chann l s5 SainpleP.at 44100' aMpleRate treamDescriptione 10 15 20 25 30 Radio IP.phc ni , IconID le nnlf= " le>nID= "2" I 'cr1ID="2" IconlD2ä Ir> Tp-n2" b conlD="2" Ico IL '2" http Pr> t Drltton="4" M:riulD "101 Ttle=="F. ,.~ir Fréset Bu ton= ilenuIP "101 Til? "R l io Ti et Blltton=C•1C' iliID n1." TI_t1 "Rdd10 iPre'; Butt-;,r.,="7" t' 1 naID -ir101" TIC] "F dio I" P1, set Button-MenuID "ll" T1/t1 "Fâdio tri reset Buttons M 'rIuID="l01 at ton= "2" MeIluID'="101 T1`_i C="R dio C1,="P o 35 I ttp://Radio IF.pi eni~ .ritt,'S~-^Ra.lio IP.F h}??WReu _'t=F'âvourites Pr /Phoenix. 40 45 ~'Prnënir_ Vérsi~:n-"1.0.0"? esche Validitvtlenus="90" 71di_ttiPrerets "2 I" iVal1d_trFaJourites "hO" /.' F3CrouritCs> Fâ rourite Fat-o urit-IDTitic_=nt un l c nanson Farourite> t' Ter:tLin, tr n PLs' t rami_2.stream.i,olt/radio2 http:/radio s . stréam. corrn'r dio2 P rearTyp >1 A P_cce 44100~ _u =Pat treamné^nriptian 'menu., Pt ceux= L'utilisateur parcourt les menus 10, 102, 10, 101, 10 et 100 avec sa Radio IP 1 après que le délai de validité arrive à échéance (ici: plus de 90s après la dernière requête). hoeni}r Vesion10 0rr orne '`, ta1idlt`JI`'1Pnue "~L>r' P 1idltre _t,,=rr-~.~~~~rr or, /, nu_lD="'1lrr Titl(-="Monu " le nID "1" Bacl-HenülD="l"> 1 0 101,102 http://Radio IP.phoénia.i, t 2 dR.aPis IP.php WRe pie.t Menu Pi4enulD 10 MTTP RADIO IP MPNUIDS 10 2905488 36 Ménul 100 101 I tt d%;'Radio IP.phoenix.ne IF.php' ?Reduest Clenu,dTIiennID 100 HTTP R DIC IP PÉNUIDS: 102,1 '2rsic L 1 . ah~ Vali litvM.nt s= Valïcalt /Falunite =' 20 / .- Menu Ilén>10=00" Ti Ba } dern l ' t C) cRadi 101,10,100 areDe criptioht T :tLn T-.;0I inr P j i 'Té_rtBin es tr ~n~r'PLs> ion="1" Radio Ors/TextLine> amL>1 ttp,:, adj O.sLre-irL.n )L _L rr.UPL> Stream[1PL>httpcaLa ette.,m. re L. 'Ln'a:TLL> StreamURLi> trnarnT>n '0 ç ecce 2 /Accr ss 'Codes :..>liF t /1 C le r 44100 rp 1_R.at eamDescrip Pion> To. ohlD= IconID= I ,ar.ID= 90'tt7alidityPr-sets="î0" 5 10 15 20 25 30 35 40 45 50 L'administrateur modifie l'URL de Radio 1 . L'utilisateur parcourt les menus 10, 102 avec sa Radio IP 1 après que le délai de validité soit arrivé à échéance (ici : plus de 90s après la dernière requête). http: //Radio IP.phoenix. ri t /5 rcR0>?o IF phu.iJReqüast=Menu WMenu ID 10 HTTP RADÎC ÎP MENUID 10 Y 7'ërsion'="1.0.0"` Carhe Validit}%Menus "90 LNli i PrP Lc=" 0" "alidit Fariour tes="20'7 'MustllpdateM~nüs> 1at hlehu h,~eni ="Radie 1" LënID="2 /> 2905488 37 Pendant ce temps, en tâche de fond sur la Radio P : http: /Radio IP.phceni . php?E,rP quest=Menu &WP-1enuIh =T 5 L'utilisateur se connecte sur les sites utilisateur de la plateforme pour modifier son profil Radio IP 1. Il accède au menu 10 sur sa Radio IP après que le 35 délai de validité soit arrivé à échéance (ici : plus de 90 s après la dernière requête). http:i/Radio IP.phoeni_ IF' pPp?hReçuest=henu~^IMenuID=1n HTTP RADIO IP MEHUIDS: ln 40 Version="1. 0 ache `Jali lit 1henus "ça Val dIt 0-de Validit nrites Menu PenuID="101 Title="Ra_1io 1" IcL,-J Ba '}_PlenulD="~ r n n rcnarDescr_i_ptior1> Strr am[JFLs> rilion="1'> .di tLirné> amURL:->htt adi _ 1 . tream. ri _'.i :.,l a str. arnr7PL:_. StrearURL >http: radios . streani co:ni r_adiol ;?f =an-OR ,> Sf_r eamURL >tre-rmT_' pe 1/ tr IT, AccPss>n Format>MP3~ rdnat> Codes, >MP` de BitRate>12 -P`tR3t0 00I1iiehS /('r nnn r pleRate 44100 5trearnDe ripti n> Phoenix ersion="1 0.0"> ache ValidityMenl_ ValidityFaourites "0" /> enü> li_lit , Pré:: ets-"~ Phein 10 15 20 25 30 45 2905488 38 L'utilisateur se déconnecte du site utilisateur de la plateforme de services. Il accède au menu 1 sur sa Radio IP après que le délai de validité soit arrivé à échéance (ici : immédiatement puisque 0 s après la dernière requête). http: //Radiu IP.phceniunet/S'vcPadio IP.phr??i4Requust-MenucWHeni HTTP RADIO IP MENOIDS: MenulD="10" Titi "Gdn_r_é 1" IconID /> MernlD0 T; ti e " anr 0n- 1T- 1, > tIei,ulD "20" T r7 p= Genre T[ /> 'MenuI tem MenuItem [ enuItem Menu> avec un code erreur valorisé à 1 et un sousélément qui permet d'affecter à la Radio IP un nouveau jeton Radio IP Token qui sera utilisé dans les prochains échanges. On donne ci-après un exemple de réponse en cas de succès : Phoenix mension="1.0.0"> ',uthenticati.on> -Errci Cod-_"1 T-> tLine rositiori-"1">Enregistreme c xtILn> T->:tLine Pasition="L Radio.. DTD: IP nohron]zation= tietIJewPadio IPTokan 0134 56789ABCDEFFEDCP,_oP?E54?210 etnewPadio TPT'A et nchrcnizr-itiori Hathenticaticr /Pho= 20 25 30 35 40 et un exemple de réponse en cas de mot de passe invalide : Phoenix version 1.0.0 F.uthentication 20 /-_uth nti ati ri) /Phoniro Resynchronisation du mot de passe Si la Radio IP est réinitialisée avec les paramètres d'usine, le mot de passe de la Radio IP redevient le mot de passe initial sortie d'usine. Le jeton associé à la 25 Radio IP n'est alors plus le même sur la plateforme et sur la Radio IP. Dans ce cas, le résultat de l'authentification sera négatif quel que soit la requête HTTP émise par la Radio IP. Pour traiter ce problème, la plateforme doit offrir soit à l'administrateur soit, éventuellement, à l'utilisateur via la personnalisation de son profil Radio IP la 30 possibilité de réinitialiser le jeton associé à la Radio IP. Si une resynchronisation du mot de passe est initiée par la plateforme de services, alors quelque soit la nature de la requête HTTP suivante émise par la Radio IP, le mot de passe envoyé par la Radio IP sera accepté par la plateforme. En conséquence, la réponse XML de la plateforme contiendra un élément 35 avec un code erreur valorisé à 1 et un sous-élément . On retrouve un processus similaire à celui de l'enregistrement de la Radio IP en sortie d'usine. 2905488 42 Le champ DefaultRadio IPPassword doit correspondre au mot de passe initial sortie d'usine de la Radio IP. Pour pouvoir effectuer cette vérification, la Radio IP sauvegarde la valeur initiale du jeton qui est commune à toutes les Radio IP. Si ce champ ne correspond pas, la Radio IP n'accepte pas le nouveau jeton. 5 Suite à une resynchronisation du mot de passe, la prochaine valeur de Radio_IP_Sait transmise par la Radio IP sera égale à 0. On donne ci-après, un exemple de réponse faite à la suite d'une demande de resynchronisation du mot de passe : `:TextLine Posit7-:1n=P. clin T-tLi-le> /Error> r oh oni ation> [PfultRadi9 I.PO _,._. ord ')Q11 341 C077O Q + ABBCCDDLEFF FefaultRadi o IPPassword> e tJ wRadio IPTok_ee 01-74 F~89ABCDEFFEDCPA987( S 3210 trdenR.adioIPToken> yncllronizatien uth-ntication> z/'Phoeni' On notera qu'une réponse avec échec d'authentification est impossible si une demande de resynchronisation du mot de passe a été initiée sur la plateforme pour la Radio IP. 30 Bien que l'invention ait été décrite en référence à un mode de réalisation particulier, elle n'est nullement limitée à ce mode de réalisation. Elle comprend tous les équivalents techniques des moyens décrits ainsi que leurs combinaisons qui entrent dans le cadre de l'invention. 15 20 25 REVENDICATIONS 1. Terminal utilisateur comportant : des moyens de mémorisation et des moyens de calcul ; une interface Homme-Machine ayant des moyens d'affichage et des moyens de saisie ; - des moyens de connexion à un réseau TCP/IP pour accéder à des fichiers audio disponibles sur des serveurs de flux de données audio en continu, chaque fichier audio étant localisé par une URL ; des moyens de décodage du flux de données transmis par ledit serveur ; et, - des moyens de restitution du son à partir dudit flux de données décodé, caractérisé en ce que lesdits moyens de mémorisation comportent une 15 mémoire cache pour sauvegarder l'historique de l'utilisation du terminal, ladite mémoire cache étant une mémoire volatile et étant de taille réduite, et en ce que ledit terminal comporte, en outre, des moyens de communication avec une plateforme de services, lesdits moyens de communication étant aptes à émettre des requêtes HTTP GET vers la plateforme 20 et à recevoir des requêtes au format XMLPhoenix depuis la plateforme. 2. Terminal selon la revendication 1, caractérisé en ce que ladite mémoire cache comporte, entre autre, le contenu des derniers menus accédés 25 par l'utilisateur, une liste de fichiers audio présélectionnés, une liste de fichiers audio préférés. 3. Architecture pour accéder à des fichiers audio disponibles sur des serveurs de flux de données audio en continu, chaque fichier audio étant localisé 30 par une URL, caractérisé en ce qu'elle comporte un terminal selon la revendication 1 ou la revendication 2, et une plateforme de services apte à recueillir auprès de serveur tiers des données hétérogènes relatives à des ressources et à les convertir au format Phoenix, et en ce que lors de la réception d'une réponse au format XML-Phoenix depuis la plateforme, le terminal est apte à 35 se connecter au serveur de flux dont l'URL est contenu dans ladite réponse. 10 2905488 44 4. Architecture selon la revendication 3, caractérisée en ce que ladite plateforme comporte : - une partie en ligne comportant une interface de vitrine virtuelle 5 gérant les échanges avec le terminal utilisateur ; un moteur de transactions ; une base de données comportant un catalogue général, un catalogue utilisateur, des profils utilisateurs et matériels ; - une partie hors ligne comportant une copie de ladite base de données ; et un module de recueil et de conversion de données hétérogènes relatives à des ressources apte à communiquer avec des serveurs tiers et à enregistrer les données converties dans ladite copie de la base de donnée ; - un moyen de synchronisation du contenu de la copie de la base de données de la partie hors ligne avec la base de données de la partie en ligne. 5. Procédé de communication utilisant le protocole TCP/IP entre un terminal utilisateur et une plateforme de services, ledit terminal utilisateur étant apte à accéder à un fichier audio disponible sur un serveur de flux de données audio en continu, ledit fichier audio étant localisé par une URL, caractérisé en ce que ledit procédé consiste en : -une étape d'authentification du terminal utilisateur auprès de la plateforme de services ; - une étape de mise à jour de la mémoire cache du terminal utilisateur à partir des informations sauvegardées sur ladite plateforme ; - une étape de requête au format HTTP GET à l'initiative du terminal utilisateur vers la plateforme, ladite requête comportant entre autre l'alias d'un fichier audio ; - une étape de réponse au format XML Phoenix de la plateforme vers le terminal utilisateur, ladite réponse comportant entre autre l'URL correspondant audit fichier audio, ledit terminal se connectant alors au serveur de flux correspondant pour accéder au fichier audio associé à ladite URL. 6. Procédé selon la revendication 5, caractérisé en ce que ladite étape de mise à jour de la mémoire cache est réalisée une première fois lors de la mise sous tension du terminal utilisateur, et que ladite première étape de mise à jour comporte : 2905488 45 l'émission d'une première requête au format HTTP GET pour demander une liste des éléments du cache à remettre à jour ; - la réception d'une réponse au format XML Phoenix comportant la liste des éléments à mettre à jour, ladite liste étant mémorisée dans ladite 5 mémoire cache 7. Procédé selon la revendication 5 ou la revendication 6, caractérisé en ce que chaque élément du cache comporte un attribut définissant sa durée de validité, et en ce que ladite étape de mise à jour du cache est exécutée à 10 l'expiration de cette durée de validité pour la mise à jour de l'élément correspondant. 8. Procédé selon l'une des revendications 5 à 7, caractérisé en ce que la mise à jour d'un élément consiste en l'émission d'une requête HTTP GET 15 demandant à la plateforme de services le contenu de l'élément à mette à jour, suivi de la réponse au format XML-Phoenix de la plateforme donnant le contenu de l'élément à mettre à jour, cet transaction requête-réponse pouvant s'effectuer en tâche de fond. 20 9. Procédé selon la revendication 5, caractérisé en ce que ladite étape d'authentification comporte une étape de synchronisation du mot de passe consistant en l'émission par le terminal utilisateur d'une requête HTTP GET avec un mot de passe initial, puis une réponse au format XML-Phoenix de la plateforme avec une valeur d'un paramètre de jeton, le terminal utilisateur sauvegardant 25 ladite valeur de jeton dans une mémoire morte et construisant un nouveau mot de passe pour les requêtes ultérieure à partir, entre autre, de la valeur dudit jeton. 10. Procédé selon la revendication 9, caractérisé en ce que le mot de passe associé à la Radio IP est le résultat de l'application d'un algorithme MD5 30 sur la concaténation des chaînes de caractères comportant au moins l'adresse MAC du terminal utilisateur, la valeur du jeton de la dernière étape de synchronisation ou à défaut de la valeur sortie d'usine, et la valeur d'un compteur du nombre de transactions requête-réponse entre le terminal utilisateur et la plateforme depuis la dernière étape de synchronisation.