WO2008047015A1 - Architecture d'acces a un flux de donnees au moyen d'un terminal utilisateur - Google Patents

Architecture d'acces a un flux de donnees au moyen d'un terminal utilisateur Download PDF

Info

Publication number
WO2008047015A1
WO2008047015A1 PCT/FR2007/051870 FR2007051870W WO2008047015A1 WO 2008047015 A1 WO2008047015 A1 WO 2008047015A1 FR 2007051870 W FR2007051870 W FR 2007051870W WO 2008047015 A1 WO2008047015 A1 WO 2008047015A1
Authority
WO
WIPO (PCT)
Prior art keywords
radio
platform
user
phoenix
user terminal
Prior art date
Application number
PCT/FR2007/051870
Other languages
English (en)
Inventor
Thomas Serval
Olivier Giroud
Original Assignee
Baracoda
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Baracoda filed Critical Baracoda
Priority to US12/439,889 priority Critical patent/US20100036893A1/en
Priority to EP07823767A priority patent/EP2060084A1/fr
Publication of WO2008047015A1 publication Critical patent/WO2008047015A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles

Definitions

  • 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
  • 3S means of sound reproduction such as loudspeakers allowing continuous data ", thus grouping the two methods of reading known as” streaming "and” progressive download ".
  • 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!
  • FIG 1 shows schematically the architecture implemented according to the invention.
  • FIG. 2 diagrammatically represents the service platform of the architecture of FIG. 1.
  • 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
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 '.
  • 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.
  • the architecture according to the invention comprises audio content servers 6 able to transmit on the Internet network 3 a streaming stream.
  • 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.
  • the service platform 4 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.
  • the IP radio 1 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • IP radio implements one or more of the following strategies to immediately broadcast content.
  • the IP radio 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.
  • 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.
  • 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.
  • 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.
  • the IP radio sends a notification to the service platform.
  • the platform 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.
  • 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.
  • the menu can be changed dynamically by first presenting the categories or the best rated resources.
  • 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 is an example and should be replaced by the actual DNS address of the platform used.
  • the format of the GET parameters depends on the type of request made. Automatic update of the date and time:
  • 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.
  • XML-P Phoenix 1.0.0 grammar
  • Platform 4 sends in response an XML-P document containing the element
  • Platform 4 sends in response an XML-P document containing the ⁇ lnfos> element.
  • 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.
  • N is 100.
  • _B_ and _M_ represent respectively the identifier of the button of the IP Radio
  • Platform 4 sends in response an XML-P document containing the element
  • 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
  • Platform 4 sends in response an XML-P document containing the ⁇ Favorites> element.
  • Platform 4 sends in response an XML-P document containing the ⁇ Favorites> element.
  • 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.
  • 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
  • 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.
  • 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.
  • 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
  • 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
  • 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.
  • 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.
  • the cache of the IP radio 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 lowest directory of the tree is a list name more menus but aliases of accessible audio files.
  • 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
  • ⁇ 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.
  • 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.
  • 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.
  • the cache of the IP Radio is empty.
  • 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.
  • IP Radio 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:
  • 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.
  • 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.
  • the administrator of the platform may modify the menus.
  • 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.
  • 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.
  • IP Radio cache manager issues queries in the background without informing the user.
  • the HTTP_RAD1O IP_MENUIDS header is not sent.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • IP Radio 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.
  • 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.
  • any password will consist of 32 hexadecimal characters.
  • 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
  • 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.
  • 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:
  • 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_RADIO IP_PASSWORD"
  • 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):
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Protocole de communication XML entre un terminal utilisateur, tel qu'un radio réveil, et une plateforme de services via le réseau Internet pour l'accès à un fichier audio disponible depuis un serveur de flux de données en continu.

Description

Architecture d'accès à un flux de données au moyen d'un terminal utilisateur.
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 termina! 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» 2007/051870
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
Figure imgf000003_0001
3S moyens de restitution du son tels que des haut-parieurs permettant de" données en continu », 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, portatif et mobile et ceci tout en ayant un coût réduit et de nombreuses fonctionnalités en adéquations avec tes attentes des utilisateurs.
L'invention a pour objet un terminaï 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 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 et à recevoir des requêtes au format XML-Phoenix depuis la plateforme.
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 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 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 termina! 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'aîias 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.
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 ie restitution de fichiers audio d'origines diverses tout en ayant très peu de ressources mémoire, et en particulier très peut 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 :
La figure 1 représente schématiquement l'architecture mise en œuvre 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 contenu audio selon l'invention va être décrite dans le mode de réalisation actuellement envisagé. Dans ce mode de réalisation, ie 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 électrique d'entrée en une onde acoustique ; une interface homme-machine IHM 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, signal électrique d'entrée en une onde acoustic
Figure imgf000006_0001
boutons ot/eu do-teughoo pour pormottro à oo dΘFnior-d^ntoragtiP^de-- oαioir dos informations---"- circuler dano un monu, sélectionner une radio, augmenter le volume sonore, modifier l'état de la Radio IP 1 , etc. D'un point de vue matériel la radio IP 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, 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 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 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 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 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 moyen d'une liaison sans fil du type WIFI ou BLUETOOTH ou l'équivalent (par 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 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 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 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 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. Il stocke le résultat de 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 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 ia partie en ligne 41. Enfin, la plateforme 4 comporte un module d'application dit de livraison 47. Le module de livraison 47 est une application qui 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 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 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 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 Ea 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 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 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 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 procéder à un ensemble de tests permettant de s'assurer que le contenu de la 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 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 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 meta 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 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 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 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 audïo 6 aptes à émettre sur le réseau Internet 3 un flux en continu. De préférence, 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 a en général une seule URL pour chaque fichier audio accessible. Il est possible 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 2eme URL, et ainsi de suite. D'une façon générale, lorsque l'utilisateur de la radio IP 1 souhaite écouter une radio, il sélectionne le mode « AUDIO ». il 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.
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, I'«URL_RAD!O» 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, I'«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 Eui a été indiquée et qui correspond à un 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 ie réseau Internet 3.
Avantageusement, en plus du flux de données audio, le serveur 6 peut envoyer des données supplémentaires ou « META_DATA » vers le terminal utilisateur pour que s'affiche sur l'écran des informations sur Ie 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. 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 d'extension WMA, MP3 ou WAV sont proposés dans le menu « Ma clé USB ». 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 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 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 lorsque la radio IP est en mode « Audio », mais également en mode « Time » lors du déclanchement 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 ê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 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 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 plateforme de services via la passerelle WIFI.
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% à 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 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 cœur ». Si le nombre de coups de coeur de la liste a atteint un 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 cœur 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 l'enregistrement en tant que coup de cœur ; musique achetée : oui/non (non par défaut) ; code d'achat (pas de code par défaut). 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 cœur. Pour cela l'utilisateur active cette fonctionnalité après avoir sélectionné un coup de 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 cœur et la réplication de la liste des coups de cœur 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. 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. Avantageusement la radio IP met en œuvre 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 é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 à l'instant considéré et du taux de compression des données lues depuis les diverses sources, !e 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 lecture immédiate. Ces quelques secondes donnent le temps à la radio IP d'accéder au serveur de Ia 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 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 numéro de téléphone VoIP. Le téléphone portable effectue un appel vers ce numéro et reçoit ie 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 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 service adapté. Par exemple, un serveur vocal intégrant un moteur de 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 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 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. 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 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 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 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 évoluer le menu et en particulier faire évoluer le menu initial présenté sur Ea radio 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 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. 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
Figure imgf000015_0001
Figure imgf000016_0001
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 :
|http: //Radio IP.phoenix.net/SvcRadio IP.php?WRequest=DateTime
La plateforme 4 envoie en réponse un document XML selon la grammaire Phoenix 1.0.0 (XML-P) contenant l'élément <DateTime> comme cela sera détaillé ci-après.
Récupération du contenu d'un menu :
|http: //Radio IP.phoenix..net/SvcRadio IP.php?WRequest=Menu&WMenulD=_M_ |
La plateforme 4 envoie en réponse un document XML-P contenant l'élément <Menu MenulD="_M_"> où _M_ est remplacé dans la requête et la 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 http://Radio IP.phoenix.net/SvcRadio IP.php?WRequest=Presets
La plateforme 4 envoie en réponse un document XML-P contenant l'élément
<Presets>.
Récupération de la liste de coups de coeur de la Radio IP http: //Radio IP.phoenix.net/SvGRadio IP.php?WRequest=Favourites La plateforme 4 envoie en réponse un document XML-P contenant l'élément
<Favourites>.
Récupération de la liste du flux d'informations
[http: //Radio IP,phoenix.net/SvcRadio IP,phρ?WReguest-Infos |
La plateforme 4 envoie en réponse un document XML-P contenant l'élément <lnfos>.
Regénération du cache de la Radio IP http://Rad.io IP.phoenix.net/SvcRadio IE.php?WRequest=Cache |
La plateforme 4 envoie en réponse un document XML-P contenant l'élément <Cache>. Cette requête permet à la Radio IP de demander à la plateforme 4 les N derniers menus accèdes 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
Figure imgf000017_0001
_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
<Presets>.
Ajout d'un coup de coeur de la Radio IP
Figure imgf000017_0002
_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 à 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
<Favourites>. Suppression d'un coup de coeur de la Radio IP
Figure imgf000017_0003
_F_ représente l'identifiant unique du coup de coeur de la radio à supprimer. La plateforme 4 envoie en réponse un document XML-P contenant l'élément <Favourites>.
Suppression de tous les coups de coeur de la Radio IP http: //Radio IP .phoenix .net/SvcRadio IP .php?WRequest=DelΑUFavourites
La plateforme 4 envoie en réponse un document XML-P contenant l'élément <Favourites>.
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.
la grammaire XML Phoenix 1.0.0
La grammaire XML Phoenix XML-P va maintenant être décrite en détail. Elément principal <Phoenix>
Exemple au format XML
<Phoenix Version="l .0.0">
|</Phoenix>
Fonctions
Elément principal de la grammaire Phoenix. Sa présence est systématique quelque soit le type de requête fait par la Radio IP. En cas de succès, il doit contenir î'authentification un élément de type Cache, et éventuellement un élément de type Menu ou Presets ou Favourites ou Infos ou DateTime.
En cas d'erreur, il doit contenir un unique élément Authentication. Description du contenu
Figure imgf000018_0001
Figure imgf000019_0002
Elément <Authentication>
Exemples au format XML
Figure imgf000019_0001
<Phoenix Version="1 .0. 0">
<Authentication> kError Code="2">
KTextLlne Position="l">Accès refusé</TextLine>
</Error>
</Aythentication>
</Ph.oenix>
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 faite par la Radio IP.
Description du contenu
Figure imgf000019_0003
Figure imgf000020_0002
Elément <Cache>
Exemples au format XML
Figure imgf000020_0001
<Phoenix Version="l . G.0">
<Cache ValidityMenus="90" ValidityPresets="20" ValidityFavourites="20">
<MustUpdatePresets />
</Cache> (...)
</Phoenix>
Fonctions
Cet élément est retourné quelque soit la requête faite par la Radio IP à partir du moment où l'authentification est réussie. Il permet de maintenir à jour ie 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 « 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 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
Figure imgf000021_0001
Figure imgf000022_0002
Elément <Menu>
Exemples au format XML
<Phoenix V<arsion="l.0.0">
<Cache ValidityMeirus="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κ>
Figure imgf000022_0001
[</Menu>
</Phoenix>
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.
Un menu est identifié de manière unique par un attribut MenulD défini sur la plateforme de services.
Description du contenu
Figure imgf000023_0001
Figure imgf000024_0001
Figure imgf000025_0002
Elément <Presets>
Exemples au format XML
Figure imgf000025_0001
Figure imgf000026_0001
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.
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
Figure imgf000026_0003
Elément <Favourites>
Exemples au format XML
Figure imgf000026_0002
2006</TextLine>
<TextLine Position="3">à 10h30</TextLine>
<TextLine Position="4">sur Radio WXC</TextLine>
</Favαurite>
<Favourite FavouriterD™"123" Title="Auteur 2 - Chanson
Y">
<TextLine Position="l">"Auteur 2 - Chanson
Y"</TextLine>
<TextLine
Figure imgf000027_0001
le 03 février
20Q6</Textline>
<TextLine Position="3">à 20h30</TextLine>
<TextLine Position="4">sur Radio AZE</TextLine>
</Favoτirite>
<Favourite FavouriteID="321" Title="Auteur 3 - Chanson
Z">
<TextLine Position^"!.1^"Auteur 3 - Chanson
Z"</TextLine>
<TextLine Position="2">écouté le 04 février
2006</!TextLine>
<TextLine Position=n3">à 08h42</TextLine>
<TextLine Position="4">sur France Inter</TextLine>
[</Favoτ3rite>
</Favourites>
|</Phoenix> Fonctions
Cet élément est retourné lors d'une requête : d'informations de contenu de la liste de coups de cœur ; d'ajout d'un coup de cœur ; suppression d'un coup de cœur ; suppression de tous les coups de coeur.
A chaque coup de coeur de la Radio IP est associé un identifiant unique
FavouritelD.
Description du contenu
Figure imgf000027_0002
Figure imgf000028_0002
Elément <lnfos>
Exemples au format XML
Figure imgf000028_0001
</Info>
</Infos>
</Phoenix>
Fonctions
Cet élément est retourné lors d'une requête de contenu du flux d'informations. Le champ Infos.GMTTimeOfNextRequest indique l'heure (à la seconde près) de la prochaine requête à réaliser par la Radio IP. Cela permet à la plateforme 4 d'optimiser la charge induite par les requêtes HTTP de toutes les Radio IP pour récupérer le prochain flux d'informations. Description du contenu
Figure imgf000029_0001
Elément <DateTime>
Exemples au format XML
Figure imgf000030_0001
Fonctions
Cet élément est retourné lors d'une requête de mise à jour automatique de l'heure et de la date. Descri tion du contenu
Figure imgf000030_0002
Gestion du cache de la radio IP
Le cache ou mémoire cache est un volume mémoire de taille restreinte permettant de stocker sur la radio IP 1 des éléments sur l'historique de son utilisation. Il 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 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. Il existera beaucoup plus de 100 éléments possibles à mettre en cache, cependant après une phase de 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 ce qui permet d'optimiser la taille de la mémoire FLASH nécessaire et d'augmenter ie temps de vie de cette méméoire 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 : 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 MenulD défini par la plateforme. Le cache stocke le contenu de l'élément XML <Menu MenulD="_M_">.; 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 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 <Presets> et est remplacée entièrement dès que cela est nécessaire ; 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 <Favourites>) et est remplacée entièrement dès que cela est nécessaire ; En revanche, l'élément XML <lnfos GMTTimeOfNextRequest="_TIME_"> 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 <Cache> est systématiquement retourné par la plateforme 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
<Cache> comporte les attributs ValidityMenus, ValidityPresets ou
ValidityFavourites qui indiquent le délai de validité de chaque type d'élément du cache. Le délai de 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 à 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 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 <Cache> est renvoyé pour indiquer la 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.
Figure imgf000032_0001
Requête de récupération d'un élément
Au cours du fonctionnement normale, si la Radio IP essaye d'accéder à un élément non présent dans le cache, la Radio IP attend la réponse de la plateforme de services pour afficher le résultat sur l'écran puis met en cache cette réponse. Si la Radio IP essaye d'accéder à un élément présent dans le cache, deux cas sont possibles :
Si le délai de validité du type d'élément correspondant a expiré, une requête est émise vers la plateforme pour récupérer l'élément correspondant. Les entêtes HTTP de cette requête contiennent la liste des menus accèdes par la Radio IP directement à partir du cache pendant que le délai n'était pas expiré. Si la réponse est obtenue en moins de 1 seconde (délai d'attente considéré acceptable par l'utilisateur), le résultat est affiché à l'écran et le cache est mis à jour si besoin. La réponse contient éventuellement un élément <Cache> qui 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 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é 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 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 cœur : 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 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 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.
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 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 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. Elie 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 d'un élément <Cache> 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_RAD1O IP_MENUIDS n'est pas émis. Dans tous les autres cas, l'en-tête HTTP_RADIO 1P_MENUIDS est émis avec la liste des menus accèdes à partir du cache depuis la dernière requête 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'entête HTTP_RADIO IPJVIENUIDS. 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 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, il essaye quelques radios puis décide d'en écouter une pendant quelques minutes ou pius.
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 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 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. 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 <Cache>. 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 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 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 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="Radios Live" IcOnID=11I" /> <MenuItem M<≥nταID="2" Title="Radios à la carte" IconID="l" />
Figure imgf000036_0001
| httρ : //Radio IP .phoenix . net/SvcRadio IP . php?WRequest=Menu&WMenuID=l
KFhoenix Version="l . 0 . 0">
<Cache ValidityMenus="90" ValidityFresets="20"
ValidityFavourites="2Q" />
<Menu MerruID="l" Title="Radios Live" IcOnID=11I1
BackMenulD="Q">
<MenuItem MenuID="10IT 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
Figure imgf000036_0002
http : //Radio IP.phoenix.net/SvcRadio IP .php?WRequest=Menu&WMenuïD=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.phρ?WReguest=Pxesets
Figure imgf000037_0001
|httρ: //Radio IP.phoenix.net/SvcRadio IP.php?MRequest=Favourite5
Figure imgf000037_0002
YTI>
<TextLine Position=l>"Auteur 2 - Chanson y"</TextLlne>
<TextLine Position=2>écoutê le 03 février
2006</TextLine>
<TextLine Position=3>à 20h30</TextLine>
<TextLine Fosition=4>sur Radio K/TextLine>
</Favourite>
</Favourites>
</Phoenix>
L'utilisateur parcourt les menus 0, 1, 10, 101 et 102 avec sa Radio IP 1 avant que le délai de validité n'arrive à échéance (ici : moins de 90s après la mise sous tension). 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" Bac]cMenuID="10">
<StreamDescription>
<TextLines>
|<TextLine Position="l">Radio 2</TextLine>
</TextLines> <StreamORLs>
<StreamURL>http: //radio2. stream.net/radio2</StχeamURL> <StreaitιURL>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> 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 ia dernière requête). 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Û "
Figure imgf000039_0001
http://Rad.io IP.phoenix.net/SvcRadio IP.phρ?WRequest=Menu&WMenuID=100 HTTP RADIO IP MENUIDS: 102,10,101,10,100
<phoenix Version=*'l .0.0">
<Cache ValidityMenus="90" ValiditγPresets=n20" ValidityFavourites="20" /> <Menu MenuID="100" Title="Radio 2" IconID="2" BackMenuID="10IT>
<Ξ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>
L'administrateur modifie l'URL de « Radio 1 ». L'utilisateur parcourt les menus 10, 102 avec sa Radio IP 1 après que ie délai de validité soit arrivé à échéance (ici : plus de 90s après la dernière requête). 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>
Pendant ce temps, en tâche de fond sur la Radio IP http: //Radio IP.phQenix.net/SvcRadio IP. php?WRequest=Menu&WMenuID=IOl
<Phoenix Version="l.Q.0">
<Cache ValidityMenus="90" ValidityPresets="20" validityFavourites="20" /> <Menu MenυID="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</Accèss> <Format>MP3</Format> <Codec>MP3</Codec> <BitRate>128</BitRate> <Channels>2</Channels> <SampleRate>44100</SampleRate>
</StreamDescription>
</Menu>
</Phoenix>
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 Ie délai de validité soit arrivé à échéance (ici : plus de 90 s après la dernière requête). http: //Radio IP.phoenix.net/SvcRadio IP.php?WRequest=Menu&WMenuID=10 HTTP RADIO IP MENUIDS: 102,10
Figure imgf000040_0001
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: //Radio IP.phoenix.net/SvcRadio IP.php?WRequest=Menu&WMenuID=l
HTTP RADIO IP MENUIDS : 1
Figure imgf000041_0001
Synchronisation du mot de passe
II faut assurer un mécanisme minimum d'authentification entre la Radio IP et la plateforme de services pour éviter, entre autre, que tout terminal ou logiciel autre que la Radio IP ne se connecte à la plateforme 4 et récupèrent des informations réservées aux Radios IP, ou des informations relatives à une radio IP particulière et donc à son utilisateur. Mais il faut pourtant permettre à n'importe quelle Radio IP sortie d'usine de s'enregistrer sur la plateforme de services.
Il faut bien évidemment que le processus retenu soit simple et peu coûteux en temps de calcul de vérification, et permette un passage à l'échelle industrielle. IE faut également qu'il offre la possibilité de resynchroniser le mot de passe de la Radio IP à tout moment que ce soit à l'initiative de l'utilisateur (via son profil Radio IP) ou à celle de l'administrateur.
Faisant le choix d'une transmission non chiffrée des informations, il faut alors assurer un mécanisme interdisant le re-jeu d'un mot de passe pour qu'un mot de passe d'authentification de la Radio IP ne puisse être utilisé qu'une seule fois. On se prémunit ainsi des programmes renifleurs. Principe de fonctionnement de la synchronisation du mot de passe
L'algorithmie cryptographique utilisée est seulement consituée de l'algorithme de hachage MD5. Ce dernier permet de hacher un contenu de taille variable et fournir en sortie une donnée binaire sur 16 octets qui sera transformée en une chaîne résultat de 32 caractères hexadécimaux (format « Striπg(32)[0-9][A- F] »).
La chaîne résultat constitue le mot de passe. Ainsi tout mot de passe sera donc constitué de 32 caractères hexadécimaux. Et aucun algorithme de chiffrement symétrique ou asymétrique n'est utilisé dans la solution mise en place.
Le mot de passe est calculé à partir des éléments décrits dans le tableau ci- dessous :
Figure imgf000042_0001
Le mot de passe associé à la Radio IP est le résultat de l'application de l'algorithme MD5 sur la concaténation des chaînes de caractères Adresse MAC, secret partagé, Rad io IPToken et Radio IPSa It
Mot de passe = MD5 ( Adresse MAC + secret partagé 4 Radio IPToken +
Radio IPSaIt )
Etat initial sortie d'usine
Le mot de passe initial de la Radio IP après sortie d'usine est calculé à partir des valeurs par défauts définies dans le paragraphe précédent. L'adresse MAC étant différente pour chaque Radio IP, le mot de passe initial résultat de l'algorithme MD5 est complètement différent d'une Radio IP à l'autre. Enregistrement de la Radio IP
Lors de la première requête HTTP transmise par la Radio IP auprès de la plateforme de services, qui peut être soit une demande de mise à l'heure, soit une regénération du cache, le mot de passe initial sortie d'usine est envoyé dans l'en-tête HTTP en tant que valeur du paramètre « HTTP-RADIO IP_PASSWORD ». Le paramètre d'en-tête « HTTP_RADIO_IP__SALT » est valorisé à 0. Le paramètre d'en-tête « HTTP_MAC_ADDRESS » contient l'adresse MAC de la Radio IP. La plateforme 4 vérifie la validité de ce mot de passe initial et transmet, dans sa réponse XML, un élément <Authentication> avec un code erreur valorisé à 1 et un sous-élément <Synchronization> 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 Version="l .0.0">
<Authentication>
<Error Code="l">
<TextLine Position="l">Bnregistrement</TextLine> <TextLine Position="2">Radio ÏP</TextLine>
</Error> <Synchronization>
<DefaultRadio IPPassword>00112233445566778899AABBCCDDEEFF </DefaultRad±o lPPassword> OettfewRadio IPToken>0123456789ABCDËFFEDCBA9876543210 </SetNewRadio IPToken>
</Synchronization>
</Authentication> | </Phoenix> et un exemple de réponse en cas de mot de passe invalide :
[<Phoenix Version="l . Q . Q'τ>
<Authentication>
<Error Code="2">
<TextLine Position="l">Accès refusé</TextLine>
</Error>
</Authentication> </Phαenix>
Requêtes de la Radio IP
Pour chaque requête HTTP transmise par la Radio IP vers la plateforme de services, le mot de passe calculé avec le jeton reçu lors de l'enregistrement de la Radio IP est transmis en tant que valeur du paramètre d'en-tête « HTTP_RADIO IP_PASSWORD ». Le paramètre d'en-tête
« HTTP-RAD I O_IP_S ALT » est valorisé avec la valeur utilisée dans la requête précédente incrémentée d'une unité, ou avec la valeur 0 si un message de resynchronisation du mot de passe vient d'être reçu par la Radio IP. Le paramètre d'en-tête « HTTP_MAC_ADDRESS » contient toujours l'adresse MAC de la Radio IP.
La plateforme possède toutes les informations pour vérifier ce mot de passe et ainsi accepter ou non la requête. On a représenté ci-dessous un exemple de réponse en cas de mot de passe valide mais avec une valeur du paramètre d'en-tête « HTTP_RADIO_IP_SALT » déjà utilisée (il s'agit de la mise en œuyre d'un protection visant à éviter le re-jeu) :
<Phoenix Version="1.0.0">
<Authenticatiαn>
KError Code="3">
<TextLine Position="l">Accès refusé</TextLine>
</Error>
I </Au.thentication> |</Phoenix>
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 Radio IP n'est alors plus le même sur ia 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 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 <Authentication> avec un code erreur valorisé à 1 et un sous-élément <Synchronization>. On retrouve un processus similaire à celui de l'enregistrement de la Radio IP en sortie d'usine.
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 Ea 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.
Suite à une resynchronisation du mot de passe, la prochaine valeur de
« Radio_IP_Salt » 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 :
<Phoenix Version="l .0.0">
<Authentication>
<Error Code="l">
<TextLine Position='τlττ>ReSynchronisation</TfextLine>
Figure imgf000045_0001
>
</Error> <Synchronization>
<DefaυXtRadio IPPassword>0Û112233445566778899AABBCCDDEEFF </DefaultRadio IPPassword> <SetNewRadio IPTθken>012345678ÔABCDEFFEDCBA9876543210 </SetNewRadio IPToken>
</Synchronization>
</Authentication>
</Phoenix>
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. 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.

Claims

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 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 et à recevoir des requêtes au format XML-Phoenix 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èdes 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é 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 à se connecter au serveur de flux dont l'URL est contenu dans ladite réponse.
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 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 : 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 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 à 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 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.
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 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 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.
PCT/FR2007/051870 2006-09-04 2007-09-04 Architecture d'acces a un flux de donnees au moyen d'un terminal utilisateur WO2008047015A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/439,889 US20100036893A1 (en) 2006-09-04 2007-09-04 Architecture for accessing a data stream by means of a user terminal
EP07823767A EP2060084A1 (fr) 2006-09-04 2007-09-04 Architecture d'acces a un flux de donnees au moyen d'un terminal utilisateur

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0653568A FR2905488B1 (fr) 2006-09-04 2006-09-04 Architecture d'acces a un flux de donnees au moyen d'un terminal utilisateur
FR0653568 2006-09-04

Publications (1)

Publication Number Publication Date
WO2008047015A1 true WO2008047015A1 (fr) 2008-04-24

Family

ID=38016692

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2007/051870 WO2008047015A1 (fr) 2006-09-04 2007-09-04 Architecture d'acces a un flux de donnees au moyen d'un terminal utilisateur

Country Status (4)

Country Link
US (1) US20100036893A1 (fr)
EP (1) EP2060084A1 (fr)
FR (1) FR2905488B1 (fr)
WO (1) WO2008047015A1 (fr)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI459783B (zh) 2006-05-11 2014-11-01 Cfph Llc 使用及管理電子檔案的方法和設備
US8055587B2 (en) * 2008-06-03 2011-11-08 International Business Machines Corporation Man in the middle computer technique
US8356345B2 (en) * 2008-06-03 2013-01-15 International Business Machines Corporation Constructing a secure internet transaction
CN103139720B (zh) * 2011-11-25 2018-01-30 东方元鼎(北京)投资管理有限公司 一种减少手机广告网络流量的处理方法及系统
US20140149392A1 (en) * 2012-11-28 2014-05-29 Microsoft Corporation Unified search result service and cache update
US9767145B2 (en) 2014-10-10 2017-09-19 Salesforce.Com, Inc. Visual data analysis with animated informational morphing replay
US10049141B2 (en) 2014-10-10 2018-08-14 salesforce.com,inc. Declarative specification of visualization queries, display formats and bindings
US9449188B2 (en) 2014-10-10 2016-09-20 Salesforce.Com, Inc. Integration user for analytical access to read only data stores generated from transactional systems
US9600548B2 (en) * 2014-10-10 2017-03-21 Salesforce.Com Row level security integration of analytical data store with cloud architecture
US10101889B2 (en) 2014-10-10 2018-10-16 Salesforce.Com, Inc. Dashboard builder with live data updating without exiting an edit mode
CN106453460B (zh) * 2015-08-12 2021-01-08 腾讯科技（深圳）有限公司 一种文件分发方法、装置和系统
US10115213B2 (en) 2015-09-15 2018-10-30 Salesforce, Inc. Recursive cell-based hierarchy for data visualizations
US10089368B2 (en) 2015-09-18 2018-10-02 Salesforce, Inc. Systems and methods for making visual data representations actionable
US10713376B2 (en) 2016-04-14 2020-07-14 Salesforce.Com, Inc. Fine grain security for analytic data sets
US10311047B2 (en) 2016-10-19 2019-06-04 Salesforce.Com, Inc. Streamlined creation and updating of OLAP analytic databases
US11093868B2 (en) 2018-03-08 2021-08-17 Jetsmarter Inc. Client creation of conditional segments
US11507904B1 (en) * 2018-04-26 2022-11-22 Jetsmarter Inc. Optimizing segment creation
CN110719676B (zh) * 2019-09-05 2022-04-15 深圳市豪恩智能物联股份有限公司 一种照明控制方法及照明控制设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000069101A1 (fr) * 1999-04-27 2000-11-16 Chaincast, Inc. Dispositif radio destine a recevoir et/ou a emettre des informations audio sur internet
US6678215B1 (en) * 1999-12-28 2004-01-13 G. Victor Treyz Digital audio devices
GB2411744A (en) * 2004-03-02 2005-09-07 Lopes Antonio Roldao Internet radio interface system
US20060114890A1 (en) * 1998-10-29 2006-06-01 Martin Boys Donald R Method and apparatus for practicing IP telephony from an internet-capable radio

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020013852A1 (en) * 2000-03-03 2002-01-31 Craig Janik System for providing content, management, and interactivity for thin client devices
US20020065927A1 (en) * 2000-09-05 2002-05-30 Janik Craig M. Webpad and method for using the same
CN100583759C (zh) * 2004-12-13 2010-01-20 华为技术有限公司 实现不同认证控制设备间同步认证的方法
US7480767B2 (en) * 2006-06-15 2009-01-20 Sap Ag Cache with time-based purging and computation of purged items

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060114890A1 (en) * 1998-10-29 2006-06-01 Martin Boys Donald R Method and apparatus for practicing IP telephony from an internet-capable radio
WO2000069101A1 (fr) * 1999-04-27 2000-11-16 Chaincast, Inc. Dispositif radio destine a recevoir et/ou a emettre des informations audio sur internet
US6678215B1 (en) * 1999-12-28 2004-01-13 G. Victor Treyz Digital audio devices
GB2411744A (en) * 2004-03-02 2005-09-07 Lopes Antonio Roldao Internet radio interface system

Also Published As

Publication number Publication date
US20100036893A1 (en) 2010-02-11
EP2060084A1 (fr) 2009-05-20
FR2905488A1 (fr) 2008-03-07
FR2905488B1 (fr) 2011-04-01

Similar Documents

Publication Publication Date Title
WO2008047015A1 (fr) Architecture d&#39;acces a un flux de donnees au moyen d&#39;un terminal utilisateur
US10223510B1 (en) Distributing digital-works and usage-rights to user-devices
US8554681B1 (en) Providing “identified” compositions and digital-works
US7827110B1 (en) Marketing compositions by using a customized sequence of compositions
US7720686B2 (en) Method and system for providing listener-requested music over a network
US20020099798A1 (en) File transfer method and system
US20150099507A1 (en) Unlimited Access to Media and Applications Over Wireless Infrastructure
WO2006053958A9 (fr) Support personnel de mémoire de masse portatif et système informatique d&#39;accès sécurisé a un espace utilisateur via un réseau
WO2006076516A2 (fr) Fourniture personnalisable d&#39;information audio
EP1938556B1 (fr) Diffusion sans telechargement de documents multimedias numeriques sur un reseau de telecommunications
EP2356827A1 (fr) Dispositif, système et procédé de création et d&#39;émission de messages multimédia
WO2008110087A1 (fr) Procédé et système de lecture multimédia, côté client et serveur
FR2911214A1 (fr) Procede de diffusion d&#39;un contenu numerique, appareil et serveur pour la mise en oeuvre d&#39;un tel procede
EP1637989A1 (fr) Procédé et système de séparation de comptes de données personnelles
US11165999B1 (en) Identifying and providing compositions and digital-works
EP1793605A1 (fr) Procédé de fourniture sur demande de menus interactifs à des terminaux couplés à un réseau de communication
EP1901453A1 (fr) Système et procédé de transmission en temps réel ou en différé de services interactifs associés à des contenus diffusés
WO2001088753A1 (fr) Procede et systeme d&#39;acces a un ensemble d&#39;informations stockees dans une base de donnees et relatives a un evenement actuel ou passe, en particulier une chanson diffusee par une station de radiodiffusion
WO2002069634A1 (fr) Dispositifs de commande de fichiers audio et/ou video et dispositifs, procedes et produits d&#39;emission correspondants
FR2901381A1 (fr) Systeme informatique a gestion universelle et collaborative de fichiers utilisateurs
FR2864283A1 (fr) Procede et dispositif de controle d&#39;acces a un document partage dans une reseau de communication poste a poste
WO2005034541A1 (fr) Procede, systeme et equipement pour la diffusion vers des terminaux d’informations relatives a des evenements futurs
FR3006542A1 (fr) Programmation d&#39;enregistrement de contenus audiovisuels presents dans une grille de programmes electronique
FR2797135A1 (fr) Procede de production d&#39;une base de donnees dans un televiseur, procede de gestion d&#39;une base de donnees dans un televiseur
FR2816783A1 (fr) Dispositif electronique, systeme informatique et procede pour la mise a disposition instantanee de donnees audiovisuelles

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07823767

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2007823767

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 12439889

Country of ref document: US