EP2060084A1 - Architecture for accessing a data stream by means of a user terminal - Google Patents

Abstract

XML communication protocol between a user terminal, such as a radio alarm, and a services platform via the Internet network for accessing an audio file available from a data streaming server.

Description

 Architecture for accessing a data stream by means of a user terminal.

The subject of the invention is that of access, via a network, to an audio file available on a download server or to an audio stream available on a streaming server, and then to reading this file or stream through a terminal. ! user.

US 6,678,215 discloses, from a very general point of view, an audio terminal, such as a clock radio, connected to the Internet to receive audio data. The audio data received by the terminal, which is compressed in standard formats, are decompressed by software means and then played by means of sound reproduction means which is equipped with the clock radio.

The audio content in digital form currently available on the Internet come either from so-called internet radios that broadcast directly on the Internet for live listening; or FM / AM radios that convert their programs into audio files that are accessible via the FM / AM radio website; any other content provider providing free or paid access to an audio file such as an advertisement, a recorded program (for example of the "Podcast" type), a newspaper or news magazine read by a human being or a speech synthesis engine, a read book also called "audiobook", one or more tracks of music purchased on the site of a record company, etc.

The servers on which are stored or allowing access to these files or data streams are designed either for a complete download of the file on the user terminal, for a delayed playback of the audio file, or for a partial partial download of a file. audio file for a read-back, the size of the downloaded portion of the file being limited by the memory of the user equipment, either for a continuous transmission of the file data for immediate reading or very slightly delayed (implementation memory of a buffer of data to prevent any interruption in sound reproduction in case of network congestion). The first method of data transfer between the content server and the user terminal is referred to as "download". 2007/051870

meaning "download", the second method is called "progressive download", while the third method is called "streaming" (which is the English term for flow). It is to these latter two methods that the present invention relates exclusively. In what

3S means of sound reproduction such as loudspeakers allowing continuous data ", thus grouping the two methods of reading known as" streaming "and" progressive download ".

There is a need for a user terminal to listen to audio files, of different origins and formats, via the Internet but which is both lightweight, portable and mobile and this while having a reduced cost and many features in line with your expectations of users.

The invention relates to a user terminus comprising: storage means and calculation means; a human-machine interface having display means and input means; means for connecting to a TCP / IP network for accessing audio files available on streaming audio data stream servers, each audio file being located by a URL; means for decoding the data stream transmitted by said server; and, means for restoring the sound from said decoded data stream, characterized in that said storage means comprise a cache memory for storing the history of the use of the terminal, said cache memory being a volatile memory and being reduced in size, and in that said terminal further comprises means of communication with a service platform, said communication means being able to send HTTP GET requests to the platform and to receive requests in XML-Phoenix format from the platform.

The invention also relates to an architecture for accessing audio files available on streaming audio data stream servers, each audio file being located by a URL, characterized in that it comprises a terminal according to the foregoing and a service platform capable of collecting heterogeneous data relating to resources from third-party servers and converting them to Phoenix format, and in that when receiving a response in XML-Phoenix format from the platform, the terminal is able to connect to the feed server whose URL is contained in said response.

The invention also relates to a method of communication using the TCP / IP protocol between a user terminal and a service platform, said user terminal being able to access an audio file available on a streaming audio data stream server, said audio file being localized by a URL, characterized in that said method consists of: a step of authentication of the termina! user with the service platform; a step of updating the user terminal cache memory from the information saved on said platform; a request step in the HTTP GET format on the initiative of the user terminal towards the platform, said request including among others the links of an audio file; a response step in the Phoenix XML format from the platform to the user terminal, said response comprising inter alia the URL corresponding to said audio file, said terminal then connecting to the corresponding stream server to access the audio file associated with said URL.

It is by proposing a network architecture comprising an additional service platform, as well as a particular communication protocol between the platform and the user terminal that the invention allows the provision of a user terminal allowing the restitution of audio files. of diverse origins while having very few memory resources, and in particular very much of dead memory which we know is of a high cost.

The invention will be better understood and other objects, details, characteristics and advantages thereof will appear more clearly in the description of a particular embodiment of the invention given solely for illustrative and non-limiting purposes. in the attached drawing. On these drawings:

Figure 1 shows schematically the architecture implemented according to the invention; and,

FIG. 2 diagrammatically represents the service platform of the architecture of FIG. 1. Referring to FIG. 1, the architecture of the audio content streaming system according to the invention will be described in the embodiment currently being considered. In this embodiment, the user terminal takes the form of a clock radio 1, located for example at the home of the user. The clock radio 1, hereinafter referred to as IP radio, includes sound reproduction means such as loudspeakers making it possible to transform an input electrical signal into an acoustic wave; an HMI human-machine interface constituted by a screen, for example a liquid crystal screen, for presenting the user with readable information and a series of buttons and / or keys to enable the user to interact and to enter information: to circulate in a menu, electrical input signal into an acoustic wave

Buttons do / teughoo for pormottro to oo dΘFnior-d ~ ntoragtiP ^ - oαioir dos information --- "- circulate dano a monu, select a radio, increase the sound volume, change the state of Radio IP 1, etc. From a hardware point of view, the IP radio 1 comprises a processor and a memory for storing the value of certain parameters and the program instructions that can be executed by the processor The IP radio 1 comprises electronic cards and the input / output interfaces allowing, for some, the display, the use of the buttons, the management of the speakers etc., and for others, the communication with a network 3. From a software point of view the IP radio 1 includes digital music decoders for transforming data received from the network 3 with standard formats such as WMA, MP3, WAV or the equivalent, into an electrical input signal suitable for the loudspeakers. preferably these decoders are in form software but could be in the form of electronic cards. In the embodiment described, the IP Radio has three modes of use: a "Time" mode, for all that relates to the functions related to what the user expects of an alarm clock (display of the date and time, selection of an alarm, etc.); an "Audio" mode, for all that is related to listening to an audio file (selecting an audio file, listening to this file, etc.); and a "Configuration" mode, for all that is related to the setting of the IP radio 1 (sound level adjustment, screen adjustment, choice of language, setting of the WIFI connection, etc.)

The network 3 is a network supporting the exchanges according to the HTTP protocol based on the TCP / IP protocol. For example, network 3 is the Internet or a corporate network ("Intranet") or equivalent. The communication between the IP radio 1 and the network 3 can be done directly by a wired connection from the IP radio 1 to a server of an access provider, but it is preferable to make the connection to the network 3 by the intermediate of a residential gateway 2 connected to the server of an access provider via for example an ADSL link. The communication between the IP Radio 1 and the residential gateway 2 is then by means of a WIFI or BLUETOOTH type wireless link or the equivalent (for example, carrier current, WIMAX, but also 3G type WCDMA system). Of course, the IP radio 1 comprises the corresponding hardware and software means to allow such communications. The use of a wireless local connection has the advantage of allowing a movement of the IP radio 1 within the area covered by the residential gateway 2.

The system according to the invention also comprises a service platform 4 connected to the network 3. The platform 4 will now be described in detail. The main function of this platform is to collect resource information from third-party servers. As this information has very heterogeneous proprietary formats, it is a question of formatting this information in a common format, in this case the PHOENIX format, in order to be able to propose them to the user via the IP 1 radio. divides into an online part 41 and an offline part 42. The online part 41 ("front office" in English) will now be described in detail. It comprises a first interface 43 constituting a virtual window supporting all transactions with the user, whether using his IP radio or a personal computer to connect via the Internet to the service platform 4. The virtual showcase 43 allows respond to queries issued by the user by searching information in a database 45. For more complex tasks, the virtual showcase 43 communicates with a module called transaction engine 46. The transaction engine 46 associates an identifier with the task that the virtual showcase 43 asks him to do. He performs this complex task by making the different queries adapted to the database 45. He stores the result of this process until the virtual showcase 43 re-sends a request for result with the associated identifier. The transaction engine then responds by transmitting the result. The virtual showcase 46 also communicates with a payment module 44. The payment module 44, which is in fact a motor similar to the transaction engine 46, communicates with a third party server 50 for all that is exchange of confidential information on the payment. It is interesting to run the payment-related transactions on a separate module because the communications with the third-party payment servers 50 are often slow and it is appropriate to have a dedicated module for distributing the load between the various modules of the online part 41. Finally, the platform 4 includes a so-called delivery application module 47. The delivery module 47 is an application which receives messages from the transaction engine 46 and performs the data transfer between a content database and a delivery database. The delivery module 47 also contains an http server that can receive requests from the user device for data transfer. The delivery module 47 directly queries the delivery database to extract the information that makes it possible to respond to this request from the user.

The database 45 of the online part 41 will now be detailed. This database has multiple volumes assigned to different applications. The database 45 includes a transaction database 45a that includes information on the complex operations that are being performed or that have been recently performed by the transaction engine 46; a user database 45b gathering the information on the user account. This is basic information, including user identification, and possibly credentials to log on behalf of the user to third-party servers to load specific content to which the user is a subscriber a device database 45c of the devices grouping for example the MAC address of Ea IP radio, the version of the software executed on this radio, etc. ; a master database 45d or general catalog containing the references of all accessible resources; a database composed of 45th user catalogs, each corresponding to an extraction from the general catalog. The online part 11 is also equipped with modules 40 whose function will be described later; and the delivery base 45f described above. The offline portion 42 of platform 4 will now be described in detail. It comprises a database 45 'which is a copy of the database 45 of the online part 41. This copy which was made at a previous instant T, is then enriched with contents and information, either by automated processes, either directly by the platform administrator, etc. Then, with a frequency of approximately one hour, a synchronization step makes it possible to update the database 45, the data database 45 'replacing that of the database 45.

Several modules are run on the offline part and work with the image database 45 '. For example, a test module 48 allows, just before synchronizing the contents of the databases 45 and 45 ', to perform a set of tests to ensure that the content of the base 45' is consistent. We are here in a process of quality of operation of the installation. A statistics module 49 makes it possible to perform any kind of calculation, such as noting the most requested audio sources, monitoring the use made of a particular IP radio, etc. Control modules 39 comprising, for example, logs storing information on platform 4 operating errors and warning mechanisms enabling the alarm to be issued in the event of a severe failure. But the offline part 42 of the platform 4 mainly comprises a content management module 38 which makes it possible to create and update the general catalog, and therefore the particular catalogs, of the database 45 'by adding new ones. references to content, enriching the metadata associated with these contents (price of a disk), etc. For this, the content management module 38 regularly connects to third-party servers 51 having proprietary catalogs. These third-party servers 51 communicate the information relating to a particular source in an associated proprietary format, which the module 38 converts automatically to format them in PHOENIX format and store them in the general catalog of the database 45 '. The content of this database is then synchronized with that of the database 45 to make these new contents available to the user.

The information distributed by the third servers 51 'which are intended to have a shorter lifetime than the synchronization period, for example one hour, are extracted and converted to the PHOENIX format directly at the online part 41 by the module 38 '. For example, weather information or news items, available on a third party server 51 'in a proprietary XML format (an equivalent of the RSS format), are converted and then stored in the database 45 to be directly available. Finally, the architecture according to the invention comprises audio content servers 6 able to transmit on the Internet network 3 a streaming stream. Preferably, these are Internet servers for performing a dynamic "streaming" depending on the nature of the destination terminal. The URL of the resource (the "Universal Resource Locator" is a pointer to a single file of audio content) contained in the database 45 corresponds to the IP address of the server and the path to the corresponding audio file. from the site of this machine. There is usually only one URL for each accessible audio file. It is possible to have multiple URLs to address a streaming server. If there is a failure on the first URL, the user equipment decides to connect using the ^2nd URL, and so on. In general, when the user of the IP radio 1 wishes to listen to a radio, he selects the "AUDIO" mode. it then moves, by means of a selector of the control lever type, through a tree structure which is proposed to it. At each hierarchical level, different menus are accessible. The lowest level menu provides a list of aliases of available audio resources.

When the user selects the "RADIO" alias, for example by pressing a "LISTEN" button, a request in the HTTP format, having as a parameter the alias "RADIO", is sent towards the platform 4 via the network internet 3.

After extracting, from the database 45, the "URL_RAD! O" corresponding to the alias "RADIO", the service platform 4 responds by addressing a response in XML format to the IP radio 1. The XML file the response comprises, among other things, as will be described in detail below, the "RADIO_URL" of the selected radio. On receipt of this response, the IP radio 1 connects to the "URL_RADIO" which Eui has been indicated and which corresponds to an audio file that is on the server 6. There is therefore broadcast to the server 6 d a request for the delivery of certain content corresponding to that of "URL RADIO". Finally, in response, the server 6 continuously transmits the content of the required file to the IP radio 1 through the Internet network 3.

Advantageously, in addition to the audio data stream, the server 6 can send additional data or "META_DATA" to the user terminal so that information about the piece in the display is displayed on the screen. being listened to. This can be title, duration, author or any other information directly related to the audio file. When in use, IP Radio 1 offers a range of features. The source selection feature allows, at a first hierarchical level, to choose for example from among three possible sources of audio data: live radio, on-demand radios or reading the contents of a USB key. It should be noted that the IP Radio 1 detects the insertion of a USB key and automatically displays the contents of the USB key. Only WMA, MP3 or WAV extension USB key files are available in the "My USB Key" menu. The user chooses his source by navigating through the menus and submenus. For example live radios are displayed by genre, it can choose to display them by country. This feature is available while listening to a source. The user can scroll through the sources of the previously displayed list and choose a new source. When the user positions the IP radio in "Audio" mode, the previously listened source is played again.

Playback of a source continues until the user has decided to stop or pause the playback, has not chosen another source, or has not switched to "Setup" mode. ". Listening from a USB key is performed by switching to the next song when the current song is finished. At the end of the directory we go back to the beginning. This loop is performed on the current directory and not on all the files of the USB key. The listening feature of a source that can be activated when the IP radio is in "Audio" mode, but also in "Time" mode when an alarm is triggered, occurs when the user after using the up and down arrows of the navigation lever to switch from one audio source to another selects the source currently in the selection area, for example by pressing the "Listen" key. Of course, the IP radio must be in communication with the service platform 4 via the WIFI gateway when the user selects a source and then when the server to access this source delivers the continuous stream of data. Activation of the preset feature allows, as soon as a source is played, the user to assign the source to a "Preset" key. A graphic or audible message confirms to the user the success of the function. The service platform is informed of the new preselection. The source is thus assigned to the selected "Preset" button.

Using the Preset listening feature, the user can listen to this source directly by pressing the "Preset" button, when the IP radio is in Time mode or in Audio mode, without having to go through the menus. and the submenu of the interface. It should be noted that the user can not assign to a "Preset" key a file of his USB key. Note that if the source is on the USB key, it must be connected to the IP radio and if the source is an Internet source, the IP radio must be in communication with the service platform via the WIFI gateway.

The IP radio in the presently envisaged embodiment also includes a volume adjustment feature that is enabled by the user regardless of the mode in which the IP radio is located. The user changes the volume of the IP radio with the corresponding button (s) from 0% to 100%.

An equalizer feature allows the user, when an audio source is played, to change the bass level and / or the treble level, it can validate or abandon the modifications made. As a result, the treble and / or bass levels are immediately brought into compliance with the settings chosen by the user. The treble and bass levels are saved in the user base when the IP radio is turned off and can be specific to each audio source.

The user can choose to add the title currently listened to in a list of "favorites". If the number of favorites of the list has reached a maximum number, for example 100, the least favorite is deleted. A message displayed for 5 seconds, confirms to the user the addition of the title to the crush. The title is added to the list of favorites and the following information is recorded in the IP radio and then transmitted to the service platform: meta-data; name of the radio; date and time of registration as a favorite; purchased music: yes / no (not by default); purchase code (no default code). For this feature, the IP radio must be in communication with the service platform The user can also choose to delete a favorite. For this the user activates this feature after selecting a favorite in the list of favorites in "Audio" mode. The corresponding title is removed from the list. The service platform is informed of this update of the list of favorites and the replication of the list of favorites in the user database is synchronized. The IP radio must be in communication with the service platform via the WiFI gateway. Alternatively, the user can choose to remove all favorites from the list.

A user who turns on his radio or selects a new radio expects that content will be broadcast immediately. The user has the feeling of a malfunction beyond a second of waiting. Advantageously IP radio implements one or more of the following strategies to immediately broadcast content.

When the user navigates the menu, the IP radio connects to the X best sources, that is to say for example the X sources most often listened to by this particular user. In the background, the IP radio reads the corresponding sources. When the user selects a radio x, the reading of the corresponding source continues with the broadcast of the corresponding program, while the X-1 other data flow reading tasks are suspended. Depending on the bandwidth available at the instant and the compression ratio of the data read from the various sources, the number X is recalculated each time and can therefore vary. As a variant, the first seconds of the X sources are recorded on the service platform. When selecting a particular source, this file of a few seconds is transferred from the platform to the IP radio for immediate reading. These few seconds give the IP radio time to access the server of the resource and this one to start the transmission of the audio content. Upon receiving the first data from the server, the IP radio switches from reading the initial file to that of the data stream. Tipping can cause a microburst in the hearing of the content. In this embodiment, the bandwidth from the server must be large and the latter must be able to support a larger load. IP radio can also be used to redirect the flow of audio data to, for example, a mobile phone. Each radiolP is identified by a VoIP phone number. The mobile phone makes a call to this number and receives the stream played on the radiolP at the time it connects, the IP radio redirecting, in real time, the data stream in a coded format satisfying the voice over IP protocol. The IP radio can decode the pressing of the mobile phone keys (dtmf) so that the user of the phone can navigate remotely within the IP radio menu to change, for example, the audio source heard.

The radiolP can also be equipped with a microphone. The sound signal picked up by this microphone is transmitted over the Internet (voice over IP) to the service platform. This redirects the flow of information to the application or the adapted service. For example, a voice server incorporating a voice recognition engine, built from information extracted from the catalog database a response giving the address of a user requested audio resource. The general catalog and the personal catalog of a user contain information called "editorial ranking" which is associated with each source accessed. For example, a popularity index of a source in the general catalog can be calculated by reporting the total playing time of that source on the total playing time of all sources in the same category or same type for example a month. Another example of a general indicator may be a technical note on the quality of the content server. Whenever a user fails to read content from a server, the IP radio sends a notification to the service platform. The platform then determines a technical score by counting the number of notifications concerning the same server during a given period of time. A technical score that is too low will allow the platform administrator to remove the corresponding sources from the database and to notify the administrator of the failing third party server. Personal indicators can also be determined such as a user satisfaction score when listening to a source, or information on the frequency of access to a particular source relative to the various resources of the personal catalog. of the user accessed during a predetermined period. This personal information on the behavior of the user allows automatic management of the personal catalog, this automatic management in addition to the direct management by the user via an Internet interface of his personal catalog. So, if the sources of the same category are well noted, the user can be offered similar sources that have received a good rating from other users. If a source has too low a rating for a period of time greater than three months, the corresponding source may be automatically deleted. It is eventually replaced by the source of the general catalog having a good rating according to the same criteria. In this case, when all the sources of a category are badly rated, the whole category can be automatically deleted from the user's personal catalog. It will no longer be shown on the IP radio menu. This feature is for example interesting to change the menu and in particular to evolve the initial menu presented on Ea IP radio just after a new user has identified. As you use IP Radio, categories that this user does not like will be removed to simplify navigation through the menu. Alternatively, the menu can be changed dynamically by first presenting the categories or the best rated resources. We will now detail the formats of the exchanges between the radio IP 1 and the platform of services 4. The DNS address of the platform 4 is RadiolP.phoenix.net. This address is an example and should be replaced by the actual DNS address of the platform used. HTTP header

All the requests sent by the IP Radio 1 to the platform 4 are of type HTTP GET with the systematic presence of an HTTP header which is detailed in table I below. Table I

Requests for information

The format of the GET parameters depends on the type of request made. Automatic update of the date and time:

| http: // Radio IP.phoenix.net/SvcRadio IP.php? WRequest = DateTime

Platform 4 sends in response an XML document according to the Phoenix 1.0.0 grammar (XML-P) containing the <DateTime> element as will be detailed hereinafter.

Retrieving the contents of a menu:

| http: // Radio IP.phoenix..net / SvcRadio IP.php? WRequest = Menu & WMenulD = _M_ |

Platform 4 sends in response an XML-P document containing the element <Menu MenulD = "_ M _"> where _M_ is replaced in the request and the response by the unique identifier of the desired menu. The value _M_ = 0 is used to designate the main menu, the starting node of all the menus. Retrieving the list of presets from IP Radio http: // Radio IP.phoenix.net/SvcRadio IP.php? WRequest = Presets

Platform 4 sends in response an XML-P document containing the element

<Presets>.

Retrieving IP Radio's Favorites List http: // Radio IP.phoenix.net/SvGRadio IP.php? WRequest = Favorites Platform 4 sends in response an XML-P document containing the element

<Favorites>.

Retrieving the information flow list

[http: // IP Radio, phoenix.net / SvcRadio IP, php? WReguest-Info |

Platform 4 sends in response an XML-P document containing the <lnfos> element.

Regeneration of IP Radio Cache http://Rad.io IP.phoenix.net/SvcRadio IE.php? WRequest = Cache |

Platform 4 sends in response an XML-P document containing the <Cache> element. This request allows IP Radio to request platform 4 the last N menus accesses to regenerate its cache after a reboot. In the preferred embodiment, N is 100.

IP Radio Custom Data Changes Changing an IP Radio Preset

_B_ and _M_ represent respectively the identifier of the button of the IP Radio

(1 to 8) and the unique identifier of the menu (defined by the service platform). Platform 4 sends in response an XML-P document containing the element

<Presets>.

Adding a favorite of the IP Radio _M_ and _TEXT_ respectively represent the unique identifier of the menu in which the radio selected as favorite has been presented to the user and the content of the meta-data associated with the favorite. Platform 4 sends in response an XML-P document containing the element

<Favorites>. Deleting a favorite of Radio IP

_F_ represents the unique identifier of the favorite of the radio to be deleted. Platform 4 sends in response an XML-P document containing the <Favorites> element.

Deleting all favorites from IP Radio http: // IP Radio .phoenix .net / SvcRadio IP .php? WRequest = DelΑUFavourites

Platform 4 sends in response an XML-P document containing the <Favorites> element.

Receive the HTTP response in XML format

If the HTTP response is the code 200, any answer made by the platform 4 to the IP Radio 1 is in XML-P format described in this document. Otherwise, only the HTTP error code is transmitted according to the usual HTTP protocol.

the Phoenix XML 1.0.0 grammar

The XML XML XML-P grammar will now be described in detail. Main element <Phoenix>

Example in XML format

<Phoenix Version = "l .0.0">

| </ Phoenix>

functions

Main element of the Phoenix grammar. Its presence is systematic whatever the type of request made by the IP Radio. If successful, it must contain the authentication of an element of type Cache, and possibly an element of type Menu or Presets or Favorites or Info or DateTime.

In case of error, it must contain a unique Authentication element. Description of the content

<Authentication> element

Examples in XML format

<Phoenix Version = "1 .0. 0">

<Authentication> kError Code = "2">

KTextLlne Position = "l"> Access denied </ TextLine>

</ Error>

</ Aythentication>

</Ph.oenix>

functions

Element returned as a result of an authentication error or a resynchronization request from the platform whatever the request made by IP Radio.

Description of the content

<Cache> element

Examples in XML format <Phoenix Version = "1. G.0">

<Cache ValidityMenus = "90" ValidityPresets = "20" ValidityFavourites = "20">

<MustUpdatePresets />

</ Cache> (...)

</ Phoenix>

functions

This element is returned regardless of the request made by the IP Radio from the moment the authentication is successful. It keeps the IP Radio cache up to date in an optimized way. The validity period count for each element type {ValidityMenus, ValidityPresets, and ValidityFavourites attributes) is reset when an XML response with a "Cache" element is received. The list of MenulDs returned for the update is the list of menu identifiers changed on platform 4 between the last IP Radio request and the current request. It is up to the IP Radio to check if these MenulD are defined in its cache and to perform the menu recovery requests in the background for their update. Description of the content

<Menu> element

Examples in XML format

<Phoenix V <arsion = "l.0.0">

<ValidityMeirus Cache = "9Q" ValidityPresets ™ "20"

ValidityFavourites = "2Q ' ^r />

<Menu MenuID = "10" Title = "Genre XY" IconID = "l"

BackMenuID = "l">

<MenuItem MermID _" =" 12 "Title =" Radio 1 "ICOΠΓD =" 2 "/><MeπuItem MenuID =" 34 "Title =" Radio 2 "IconID =" 2 "/><MenuIteiπ MenuID =" 35 "ïitle = "Radio 3" IconID = "2"/>

</ Merra>

</ Phoeniκ>

[</ Menu>

</ Phoenix>

functions

This element is returned when requesting content information from a menu either during the first access to this menu or when updating the cache.

A menu is uniquely identified by a MenulD attribute defined on the service platform.

Description of the content

Element <Presets>

Examples in XML format

functions

This element is returned when requesting content information from the list of presets or modification of a preset.

Each preselection of the IP Radio is associated with a MenulD corresponding to the description of a stream of audio content.

Description of the content

Element <Favorites>

Examples in XML format

2006 </ TextLine>

<TextLine Position = "3"> at 10:30 am </ TextLine>

<TextLine Position = "4"> on WXC Radio </ TextLine>

</ Favαurite>

<Favorite Favor ™ ™ 123 "Title =" Author 2 - Song

Y ">

<TextLine Position = "l"> "Author 2 - Song

Y "</ TextLine>

<TextLine February 03

20Q6 </ textLine>

<TextLine Position = "3"> at 8:30 pm </ TextLine>

<TextLine Position = "4"> on Radio AZE </ TextLine>

</ Favoτirite>

<Favorite FavoriteID = "321" Title = "Author 3 - Song

Z ">

<TextLine Position ^ "!. ¹ ^" Author 3 - Song

Z "</ TextLine>

<TextLine Position = "2"> listened on February 04

2006 </! TextLine>

<TextLine Position = ⁿ 3 "> at 8:42 am </ TextLine>

<TextLine Position = "4"> on France Inter </ TextLine>

[</ Favoτ3rite>

</ Favorites>

| </ Phoenix> Features

This element is returned during a request: content information from the list of favorites; to add a crush; removal of a crush; removal of all the favorites.

Every favorite of the Radio IP is associated a unique identifier

FavouritelD.

Description of the content

<Lnfos> element

Examples in XML format </ Info>

</ Info>

</ Phoenix>

functions

This element is returned during a content request of the information flow. The Info.GMTTimeOfNextRequest field indicates the time (to the nearest second) of the next request to be made by the IP Radio. This allows the platform 4 to optimize the load induced by the HTTP requests of all the IP Radio to retrieve the next flow of information. Description of the content

<DateTime> element

Examples in XML format

functions

This element is returned during a request to update the time and date automatically. Description of the content

IP radio cache management

The cache or cache is a small memory volume for storing on the IP radio 1 elements on the history of its use. It aims to reduce the latency when navigating the menus of the IP Radio 1, to allow operation even if the platform is not available (for example by ensuring a minimum service to the radio servers of which the address has been cached), and reduce the load of the service platform by limiting the number of connections.

Cache sizing

The SDRAM memory size reserved for the IP Radio 1 cache is 500K, which should allow, by estimating an average of 5K per cached element, to store 100 elements in memory. There will be many more than 100 possible elements to cache, however after a discovery phase of the IP Radio, we can estimate that the user will always listen to the same type of audio content and that he will travel less than 100 daily. menus. The cache is not saved in the FLASH memory of IP Radio 1, which optimizes the size of the required FLASH memory and to increase the life time of this memory which is known that the number of writings is limited to about 100,000.

Cached item

The cache of the IP radio according to the invention comprises three types of elements: the contents of the menus retrieved on the platform 4 during the navigation of the user: each stored menu is indexed in the cache by its unique identifier MenulD defined by the platform. The cache stores the contents of the XML element <Menu MenulD = "_ M _"> .; Remember that the lowest directory of the tree is a list name more menus but aliases of accessible audio files. This list is considered a menu; the contents of the list of IP Radio presets: the list of Presets of the IP Radio is stored in the cache globally (corresponding to the XML element <Presets> and is completely replaced as soon as it is necessary; IP Radio favorites list: IP Radio favorites list is stored in the cache globally (corresponding to the <Favorites> XML element) and is completely replaced as soon as necessary On the other hand, the XML element <lnfos GMTTimeOfNextRequest = "_ TIME _"> which describes the flow of information does not enter into the management of the cache of the IP Radio because its update is systematic and is periodically regulated by function of the _TIME_ attribute.

Cache update information

The <Cache> XML element is always returned by the service platform regardless of the request made by the IP Radio, as long as the authentication is successful. This keeps the cache of the

IP radio in an optimized way. As stated above, the XML element

<Cache> has ValidityMenus, ValidityPresets, or

ValidityFavourites that indicate the validity period for each type of cache element. The validity period is reset as soon as an XML response containing an element type to be updated is received.

As noted above, the cache is not backed up when the IP Radio is turned off. The service platform saves every access to a menu from IP Radio. At each power-up, the IP Radio transmits a request for regeneration of the cache to know the list of elements to put in its cache. The platform responds by giving, for example, the list of MenulD needed to generate the cache again. The IP Radio then issues the number of requests needed from the service platform to retrieve each item.

In the particular case of the first power on of the IP Radio at the factory, the cache of the IP Radio is empty. After registering the IP Radio with the service platform, and after the first HTTP GET cache refresh request, the <Cache> XML element is returned to indicate the update of the list of favorites, the list presets as well as the menu whose MenulD is equal to 0: this is the basic or root menu of the audio navigation. This allows the IP Radio to immediately retrieve custom data whose initial values correspond to a default profile.

Request to retrieve an item

During normal operation, if the IP Radio attempts to access an item not present in the cache, the IP Radio waits for the service platform response to display the result on the screen and then caches this response. If IP Radio tries to access an item in the cache, two cases are possible:

If the validity period of the corresponding element type has expired, a request is sent to the platform to retrieve the corresponding element. The HTTP headers of this request contain the list of menus accessed by the IP Radio directly from the cache while the delay was not expired. If the answer is obtained in less than 1 second (waiting time considered acceptable by the user), the result is displayed on the screen and the cache is set updated if necessary. The response may contain a <Cache> element that indicates that other elements need to be updated in the background without the user having to worry about them. If the response is obtained in more than 1 second, the result is displayed on the screen from the cache. When the answer arrives in the background, it is processed normally for updating the cache but we do not change the display on the screen to not disturb the user. If a new request is issued before the reply arrives in the background, it will follow the principle of the expired time. If, on the other hand, the validity period of the element type is not expired, the result is displayed on the screen from the cache. No requests are sent to the platform. The cache manager saves the information that such menu has been accessed to inform the platform during the next request with an expired time. The validity period is a parameter whose value is decided on the platform and is assigned by type of element: menus, presets and favorites. If the IP Radio uses a default profile, this validity period can be increased by increasing it from one minute to ten minutes or one hour, because only the administrator of the platform can modify the contents of the menus. IP Radio is necessarily at the initiative of changes presets and favorites: it can take them into account without making additional requests. If the IP Radio uses a user profile that can be modified by the user on the platform (by accessing the platform by a personal computer connected to the user site of the platform), even with a short delay, the principle remains interesting on the load plan of the platform. In addition, when the user is connected via his personal computer to the platform's user site to modify his IP Radio profile, the platform can assign a null validity period to the next requests as long as the user has not logged off. on the user site. This ensures that any changes made by the user on his IP Radio profile are taken into account immediately on his IP Radio.

Changes made on the platform

For example, the administrator of the platform may modify the menus. In this case, a list of MenulD identifiers of the modified menus on the service platform between the last request of the IP Radio and the request current is returned by the platform for update. IP Radio will ignore update information for menus it has not accessed, and will issue retrieval requests only for those in its cache. To correctly fill in this list of MenulD IDs of the modified menus, the service platform must save the date and time of the last modification of each menu and the date and time of the last request made by IP Radio. Elie thus returns to the IP Radio only once the list of modified elements. Manage menu access statistics

If some elements of the cache need to be updated after receiving a <Cache> element in an XML response, the IP Radio cache manager issues queries in the background without informing the user. In this particular case, the HTTP_RAD1O IP_MENUIDS header is not sent. In all other cases, the HTTP_RADIO 1P_MENUIDS header is issued with the list of menus accessed from the cache since the last HTTP request issued by IP Radio. If a menu retrieval request is issued, the MenulD of this menu is included as the last item in the list of the HTTP_RADIO IPJVIENUIDS header. The use of IP Radio is therefore the following: the user who wants to listen to a radio, puts it in audio mode. It starts a preset directly or navigates through the favorite menus to select a radio. The duration of this selection can be estimated at a few tens of seconds, he tries some radios then decides to listen to one for a few minutes or more.

Even with a short period of validity, for example of about 90 seconds, the load of the service platform is reduced because only the first access (possibly unnecessary) is achieved followed by some useful access to regenerate the cache of the IP Radio. If we consider that the user regularly browses 10 genres and tests at most 20 radios during its selection, the cache system allows the IP Radio to make only one request to the service platform instead of the 30 systematic. As a consequence of this particular management of the cache memory, the load of the service platform is advantageously greatly reduced. Moreover, whatever the request made by the IP Radio to the service platform, the XML response can contain a <Cache> element. This makes it possible to quickly update elements present in the cache of the IP Radio even if the user has not yet accessed it. This mechanism also makes it possible not to make systematic periodic connections but to take advantage of useful connections to manage the contents of the cache. In conclusion, the request for regeneration of the IP Radio cache makes it possible on the one hand to optimize the necessary memory size on the IP Radio as well as its lifetime if it is a memory of the FLASH type, and On the other hand, do not lose any user information if the IP Radio is reset to the factory default settings. Example of use The following steps are linked chronologically.

Regenerating the cache when powering on the IP Radio http: // Radio IP.phoenix.net/SvcRadio IP .php? WRequesfc = Cache

| <Phoenix Version = "l.Q.Q">

<Caσhe ValidityMenus = "90" ValidityPr $ sets = "20" ValidityFavoorites = "20">

<MustUpdateMemαs>

<MenuID> 0 </ MenuID> <MenuID> K / MenuID> <MenuID> 10 </ MenuID> <MenuID> 101 </ MenuID>

</ MustUpdateMenus> <MustUpdatePresets /> <MustUpdateFavourites />

</ Cache>

| </ Phoenix>

http: // Radio lP.phoenix.net/SvcRadio IP.php? WRequest = Menu & WMenu! D = Q

KPhoenix Version ™ "! .0.0">

<Cache ValidityMerras = "90" ValidityPresets = "2Q"

ValidityFavourites = "20" />

<Menu MenuID = "0" Title = "Memi" IconIE> = "0" BackMenuID = "O">

<MenuItem MerraID = "l" Title = "Live Radios" IcOnID = ¹¹ I "/><MenuItem M <≥nταID =" 2 "Title =" Radios à la carte "IconID =" l "/>

| httρ: // Radio IP .phoenix. net / SvcRadio IP. php? menu = & WRequest WMenuID = l

KFhoenix Version = "l. 0. 0">

<Cache ValidityMenus = "90" ValidityFresets = "20"

ValidityFavourites = "2Q" />

<Menu MerruID = "l" Title = "Live Radios" IcOnID = ¹¹ I ¹

BackMenulD = "Q">

<MenuItem MenuID = "10 ^IT Title =" Genre 1 "IconID =" l "/><MenuItem MenuID =" 2Û "Title =" Genrβ 2 "IconID =" l "/><MenuItem MenulD =" 30 "Title =" Genre 3 "IconID =" l "/>

</ Menu>

</ Phoenix>

http: // Radio IP.phoenix.net/SvcRadio IP.php? WRequest = Menu & WMenuID = 10

http: // Radio IP.phoenix.net/SvcRadio IP .php? WRequest = Menu & WMenuId = l01

P <Phoenix Version = "1.0.0">

<Cache ValidityMenυs = "90" ValidityPresets = "20"

ValidityFavourites = "20" />

<Menu MenuID = "101" Title = "Radio 1" IconID = "2"

BackMenuID = "10">

<StreamDescription>

<TextLines>

KTextLine Position = "l"> Radio K / TextLine>

</ TextLines> <StreamURLs>

<StreamURL> http: // radiol. stream.net/radiol </ StreamURL> <StreamURL> http: // radios. stream.com/radiol </ StreamURL>

</StreamURI.s>

<StreamType> K / streamType>

<Acσess> 2 </ Access> <For.mat> MP3 </ Format><Codec> MP3 </ Codec><BitRate> 128 </ BitRate><Channels> 2 </ Channels><SampleRate> 441QQ </ SamρleRate>

| </ StreamDescriρtiσn>

</ Menu>

</ Phoeniχ>

[http: // Radio IP.phoenix.net/SvcRacLio IP.phr? WReguest = Pxesets

| httρ: // Radio IP.phoenix.net/SvcRadio IP.php? MRequest = Favorite5

Y ^TI >

<TextLine Position = l> "Author 2 - Song y" </ TextLlne>

<TextLine Position = 2> listened to 03 February

2006 </ TextLine>

<TextLine Position = 3> at 20:30 </ TextLine>

<TextLine Fosition = 4> on Radio K / TextLine>

</ Favorite>

</ Favorites>

</ Phoenix>

The user browses menus 0, 1, 10, 101 and 102 with his IP Radio 1 before the validity period expires (here: less than 90 seconds after power-up). http: // Radio IP.phoenix.net/SvcRadio IP .php? WRequest = Menu & WMenuID = l02 HTTP RADIO IP MENUIDS: 0,1,10,101,102

<Phαenix Version = "1.0.0">

<Cache ValidityMenus = "90" ValidityPresets = "20 ^π ValidityFavourites =" 20 "/><Menu MenuID =" 102 "Title =" Radio 2 "IconID =" 2 "Tray] cMenuID =" 10 ">

<StreamDescription>

<TextLines>

| <TextLine Position = "l"> Radio 2 </ TextLine>

</ TextLines> <StreamORLs>

<StreamURL> http: // radio2. stream.net/radio2 </ SteamURL> <StraitureURL> http: // radios. stream.coin / radio2 </ StreamURL>

</ StreamURLs> <StreamType> l </ StreamType> <Access> 2 </ Access> <Format> MP3 </ Format> <Codec> MP3 </ Codec> <BitRate> 128 </ BitRate> <Channels> 2 </ Channels> <SamρleRate> 44100 </ SarapleRate>

</ StreamDescriρtion>

</ Memα>

</ Phoenix> The user browses menus 10, 102, 10, 101, 10 and 100 with his IP Radio 1 after the validity period expires (here: more than 90s after the last request). http: // Radio IP.phoenix.net/SvcRadio IP.php? WRequest = MenutWMenuID = 10 HTTP RADIO IP MENQIDS: 10

<Phoenix Version≈ "! .0.0">

| <Cache ValidityMerms = "90" ValidityPresets = "2Û"

http://Rad.io IP.phoenix.net/SvcRadio IP.phr? WRequest = Menu & WMenuID = 100 HTTP RADIO IP MENUIDS: 102,10,101,10,100

<phoenix Version = * 'l .0.0 ">

<Cache ValidityMenus = "90" ValiditγPresets = ⁿ 20 "ValidityFavourites =" 20 "/><Menu MenuID =" 100 "Title =" Radio 2 "IconID =" 2 "BackMenuID =" 10 ^IT >

<ΞtreamDescription>

<TextLines>

<TextLine PositiQn = "l"> Radio 0 </ TextLine>

</ TextLines> <StreamϋRljΞ>

<ΞtreamϋRL> http: // radioO. stream.net/radioO </ StreamURL> <StreamURL> http: // radios. stream.com/radioO </ StreamURL>

</St.reamURL5> <StreamType> K / StreamType> <Access> 2 </ Access> <Format> MP3 </ Foxmat> <Codec> MP3 </ Codec> <BitRate> 128 </ BitRate> <Chaπnels> 2 < / Charmels> <SampleRate> 44l00 </ SampleRate>

I </ StreamDescription>

</ Men ">

</ Phoenix>

The administrator modifies the URL of "Radio 1". The user browses the menus 10, 102 with his IP Radio 1 after the validity period has expired (here: more than 90s after the last request). http: // Radio IP.phoenix.net/SvcRa4io IP.ρhp? WRequest = Menu & WMenuID = 10 HTTP RADIO IP MENUIDS: 10

<Pho & nix Version = "l .0.0">

<Cache ValidityMenus = "90" ValidityPresets = "20" ValidityFavourites = "20">

<MustUpdateMenυs>

<MenuID> 10K / MenuID>

</ MustUpdateMenus>

</ Cache><Meim MenuID = "10" Txtle = "Menu" IconID = "l" BackMenuID = "l"> <MenuItem MenuID = "100" Title = "Radio 0" IconîD = "2"/><MenuItem MenuID = "101" Title = "Radio 1" IconID = "2"/><MenuItem MenuID = "102" τitle = " Rad-.o 2 "lconID =" 2 "/>

</ Menu> | </ Phoenix>

Meanwhile, in the background on the IP Radio http: // Radio IP.phQenix.net/SvcRadio IP. php? menu = & WRequest WMenuID IOL =

<Phoenix Version = "l.Q.0">

<Cache ValidityMenus = "90" ValidityPresets = "20" validityFavourites = "20" /> <Menu MenUID = "101" Title = "Radio 1" IconID ^ "2" BackMenuID = "10">

<StreamDescriρtion>

<TextLines>

<TextLine PositiQn = "l"> Rad.io K / TextLine>

</ TextLines> <StreamURLs>

<StreamURL> http: //radiol.stxeam.net/radiol_a </ StreamURL> <StreamϋRL> http: // radios. stxeam.com/radiol_a </ StreamURL>

</ StreamURLε> <StreamTyρe> l </ StreamType> <AcceSS> 2 </ Access> <Format> MP3 </ Format> <Codec> MP3 </ Codec> <BitRate> 128 </ BitRate> <Channels> 2 </ Channels> <SampleRate> 44100 </ SampleRate>

</ StreamDescription>

</ Menu>

</ Phoenix>

The user connects to the user sites of the platform to modify his profile IP Radio 1. He accesses the menu 10 on his IP Radio after the validity period has expired (here: more than 90 s after the last request ). http: // Radio IP.phoenix.net/SvcRadio IP.php? WRequest = Menu & WMenuID = 10 HTTP RADIO IP MENUIDS: 102,10

The user disconnects from the user site of the service platform. He accesses Menu 1 on his IP Radio after the validity period has expired (here: immediately since 0 s after the last request). http: // Radio IP.phoenix.net/SvcRadio IP.php? WRequest = Menu & WMenuID = l

HTTP RADIO IP MENUIDS: 1

Password synchronization

A minimum authentication mechanism must be provided between IP Radio and the service platform to prevent, among other things, any terminal or software other than IP Radio from connecting to platform 4 and recovering information reserved for IP Radios, or information relating to a particular IP radio and therefore to its user. But we must allow any IP Radio factory out to register on the service platform.

It is obviously necessary that the process chosen be simple and inexpensive in verification calculation time, and allow a transition to industrial scale. IE must also offer the possibility to resynchronize the password of IP Radio at any time at the initiative of the user (via its IP Radio profile) or that of the administrator.

Making the choice of an unencrypted transmission of information, it is then necessary to provide a mechanism prohibiting the re-play of a password so that an authentication password of the IP Radio can be used only one time. one time. We protect ourselves from sniffing programs. Operating principle of password synchronization

The cryptographic algorithm used is only made up of the MD5 hashing algorithm. The latter makes it possible to chop a variable size content and output 16-byte binary data that will be transformed into a result string of 32 hexadecimal characters (format "Striπg (32) [0-9] [A-F]").

The result string is the password. Thus any password will consist of 32 hexadecimal characters. And no symmetric or asymmetric encryption algorithm is used in the implemented solution.

The password is calculated from the elements described in the table below:

The password associated with the IP Radio is the result of the application of the MD5 algorithm on the concatenation of the strings MAC address, shared secret, Rad io IPToken and Radio IPSa It

Password = MD5 (MAC address + shared secret 4 Radio IPToken +

Radio IPSaIt)

Initial state leaving the factory

The initial password of the IP Radio after leaving the factory is calculated from the default values defined in the previous paragraph. The MAC address is different for each IP Radio, the initial password result of the MD5 algorithm is completely different from one IP Radio to another. IP Radio Recording

During the first HTTP request sent by IP Radio to the service platform, which can be either a time-setting request or a cache regeneration, the initial password is sent from the factory HTTP header as the value of the "HTTP-RADIO IP_PASSWORD" parameter. The header parameter "HTTP_RADIO_IP__SALT" is set to 0. The header parameter "HTTP_MAC_ADDRESS" contains the IP address of the IP Radio. The platform 4 verifies the validity of this initial password and transmits, in its XML response, an <Authentication> element with an error code valued at 1 and a <Synchronization> sub-element which makes it possible to assign to the IP Radio a new Token "Radio IP Token" which will be used in future exchanges. The following is an example of an answer if successful:

<Phoenix Version = "l .0.0">

<Authentication>

<Error Code = "l">

<TextLine Position = "l"> Recording </ TextLine> <TextLine Position = "2"> Radio ÏP </ TextLine>

</ Error> <Synchronization>

<DefaultRadio IPPassword> 00112233445566778899AABBCCDDEEFF </ DefaultRad ± o lPPassword> OettfewRadio IPToken> 0123456789ABCDEFFEDCBA9876543210 </ SetNewRadio IPToken>

</ Synchronization>

</ Authentication> | </ Phoenix> and an example of an answer in case of invalid password:

[<Phoenix Version = "1. Q 'Q' ^τ >

<Authentication>

<Error Code = "2">

<TextLine Position = "l"> Access denied </ TextLine>

</ Error>

</ Authentication> </ Phαenix>

IP Radio Requests

For each HTTP request transmitted by the IP Radio to the service platform, the password calculated with the token received when IP Radio is registered is passed as the value of the header parameter "HTTP_RADIO IP_PASSWORD" . The header parameter

"HTTP-RAD I O_IP_S ALT" is evaluated with the value used in the previous request incremented by one unit, or with the value 0 if a password resynchronization message has just been received by the IP Radio. The header parameter "HTTP_MAC_ADDRESS" always contains the IP address of the IP Radio.

The platform has all the information to verify this password and thus accept or not the request. An example of a response in the case of a valid password is shown below but with a value of the header parameter "HTTP_RADIO_IP_SALT" already used (this is the implementation of a protection aimed at avoiding the re-game):

<Phoenix Version = "1.0.0">

<Authenticatiαn>

KError Code = "3">

<TextLine Position = "l"> Access denied </ TextLine>

</ Error>

I </Au.thentication> | </ Phoenix>

Resynchronization of the password

If the IP Radio is reset to factory settings, the IP Radio password returns to the factory default password. The token associated with the IP Radio is then no longer the same on the platform and on the IP Radio. In this case, the result of the authentication will be negative regardless of the HTTP request sent by the IP Radio. To deal with this problem, the platform must offer the administrator or, possibly, the user via the customization of his IP Radio profile the possibility of resetting the token associated with the IP Radio. If a resynchronization of the password is initiated by the platform of services, then whatever the nature of the following HTTP request emitted by the Radio IP, the password sent by the Radio IP will be accepted by the platform. As a result, the XML response of the platform will contain an <Authentication> element with an error code valued at 1 and a <Synchronization> sub-element. There is a similar process to the recording of IP Radio at the factory.

The "DefaultRadio IPPassword" field must match the original IP Radio factory default password. To be able to perform this check, the IP Radio backup Ea initial value of the token that is common to all IP Radio. If this field does not match, the IP Radio does not accept the new token.

Following a resynchronization of the password, the next value of

"Radio_IP_Salt" transmitted by the IP Radio will be equal to 0.

An example of an answer given following a request to resynchronize the password is given below:

<Phoenix Version = "l .0.0">

<Authentication>

<Error Code = "l">

<TextLine Position = ' ^τ l ^ττ > ReSynchronization </ TfextLine> >

</ Error> <Synchronization>

<DefaυXtRadio IPPassword> 0Û112233445566778899AABBCCDDEEFF </ DefaultRadio IPPassword> <SetNewRadio IPToken> 012345678ÔABCDEFFEDCBA9876543210 </ SetNewRadio IPToken>

</ Synchronization>

</ Authentication>

</ Phoenix>

It should be noted that an answer with authentication failure is impossible if a request for resynchronization of the password has been initiated on the platform for the IP Radio. Although the invention has been described with reference to a particular embodiment, it is not limited to this embodiment. It includes all the technical equivalents of the means described as well as their combinations which come within the scope of the invention.

Claims

1. User terminal comprising: storage means and calculation means; a human-machine interface having display means and input means; means for connecting to a TCP / IP network for accessing audio files available on streaming audio data stream servers, each audio file being located by a URL; means for decoding the data stream transmitted by said server; and, means for restoring the sound from said decoded data stream, characterized in that said storage means comprise a cache memory for saving the history of the use of the terminal, said cache memory being a volatile memory and being reduced size, and in that said terminal further comprises means of communication with a service platform, said communication means being able to issue HTTP GET requests to the platform and to receive requests in XML-Phoenix format since the platform.

2. Terminal according to claim 1, characterized in that said cache memory comprises, among other things, the content of the last menus accessed by the user, a list of preselected audio files, a list of favorite audio files.

3. Architecture for accessing audio files available on streaming audio data stream servers, each audio file being located by a URL, characterized in that it comprises a terminal according to claim 1 or claim 2, and a a service platform capable of collecting heterogeneous resource data from third-party servers and converting them to Phoenix format, and in that when receiving a response in XML-Phoenix format from the platform, the terminal is capable of to connect to the feed server whose URL is contained in said response.

4. Architecture according to claim 3, characterized in that said platform comprises: an online part comprising a virtual window interface managing the exchanges with the user terminal; a transaction engine; a database comprising a general catalog, a user catalog, user and material profiles; an offline portion including a copy of said database; and a module for collecting and converting heterogeneous data relating to resources able to communicate with third-party servers and to record the converted data in said copy of the database; means for synchronizing the content of the copy of the database of the offline part with the database of the online part.

A communication method using the TCP / IP protocol between a user terminal and a service platform, said user terminal being able to access an audio file available on a streaming audio data stream server, said audio file being located by a URL, characterized in that said method consists of: a step of authenticating the user terminal with the service platform; a step of updating the user terminal cache memory from the information saved on said platform; an HTTP GET request step on the initiative of the user terminal to the platform, said request including among others the alias of an audio file; a response step in the Phoenix XML format from the platform to the user terminal, said response comprising inter alia the URL corresponding to said audio file, said terminal then connecting to the corresponding stream server to access the audio file associated with said URL.

6. Method according to claim 5, characterized in that said step of updating the cache memory is performed a first time during power-up of the user terminal, and said first update step comprises: issuing a first request in the HTTP GET format to request a list of the elements of the cache to be updated; the receipt of a response in Phoenix XML format comprising the list of elements to be updated, said list being stored in said cache memory

7. Method according to claim 5 or claim 6, characterized in that each element of the cache has an attribute defining its validity period, and in that said step of updating the cache is executed at the expiration of this duration. validity for updating the corresponding element.

8. Method according to one of claims 5 to 7, characterized in that the update of an element consists in the issuing of an HTTP GET request requesting the service platform the content of the element to be up to date, followed by the XML-Phoenix response of the platform giving the content of the element to be updated, this request-response transaction can be done in the background.

9. Method according to claim 5, characterized in that said authentication step comprises a step of synchronization of the password consisting of the transmission by the user terminal of an HTTP request GET with an initial password, then a XML-Phoenix format response of the platform with a value of a token parameter, the user terminal saving said token value in a read-only memory and constructing a new password for subsequent requests from, among others, the value of said token.

10. Method according to claim 9, characterized in that the password associated with the IP Radio is the result of the application of an algorithm MD5 on the concatenation of character strings comprising at least the MAC address of the user terminal. , the value of the token of the last synchronization step or the factory default value, and the value of a counter of the number of request-response transactions between the user terminal and the platform since the last synchronization step.