EP2060084A1 - 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 utilisateurInfo
- Publication number
- EP2060084A1 EP2060084A1 EP07823767A EP07823767A EP2060084A1 EP 2060084 A1 EP2060084 A1 EP 2060084A1 EP 07823767 A EP07823767 A EP 07823767A EP 07823767 A EP07823767 A EP 07823767A EP 2060084 A1 EP2060084 A1 EP 2060084A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- radio
- platform
- user
- phoenix
- user terminal
- Prior art date
- Legal status (The legal status 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 status listed.)
- Withdrawn
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
Description
Claims
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 |
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 |
Publications (1)
Publication Number | Publication Date |
---|---|
EP2060084A1 true EP2060084A1 (fr) | 2009-05-20 |
Family
ID=38016692
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP07823767A Withdrawn EP2060084A1 (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)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
TWI633769B (zh) * | 2006-05-11 | 2018-08-21 | Cfph股份有限公司 | 使用及管理電子檔案的方法和設備 |
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 |
US10101889B2 (en) | 2014-10-10 | 2018-10-16 | Salesforce.Com, Inc. | Dashboard builder with live data updating without exiting an edit mode |
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 |
US9767145B2 (en) | 2014-10-10 | 2017-09-19 | Salesforce.Com, Inc. | Visual data analysis with animated informational morphing replay |
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 | 深圳市豪恩智能物联股份有限公司 | 一种照明控制方法及照明控制设备 |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6993004B2 (en) * | 1998-10-29 | 2006-01-31 | Sound Starts, Inc. | Method and apparatus for practicing IP telephony from an Internet-capable radio |
US6249810B1 (en) * | 1999-02-19 | 2001-06-19 | Chaincast, Inc. | Method and system for implementing an internet radio device for receiving and/or transmitting media information |
US20020013852A1 (en) * | 2000-03-03 | 2002-01-31 | Craig Janik | System for providing content, management, and interactivity for thin client devices |
US6678215B1 (en) * | 1999-12-28 | 2004-01-13 | G. Victor Treyz | Digital audio devices |
US20020065927A1 (en) * | 2000-09-05 | 2002-05-30 | Janik Craig M. | Webpad and method for using the same |
GB2411744A (en) * | 2004-03-02 | 2005-09-07 | Lopes Antonio Roldao | Internet radio interface system |
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 |
-
2006
- 2006-09-04 FR FR0653568A patent/FR2905488B1/fr not_active Expired - Fee Related
-
2007
- 2007-09-04 US US12/439,889 patent/US20100036893A1/en not_active Abandoned
- 2007-09-04 EP EP07823767A patent/EP2060084A1/fr not_active Withdrawn
- 2007-09-04 WO PCT/FR2007/051870 patent/WO2008047015A1/fr active Application Filing
Non-Patent Citations (1)
Title |
---|
See references of WO2008047015A1 * |
Also Published As
Publication number | Publication date |
---|---|
FR2905488B1 (fr) | 2011-04-01 |
US20100036893A1 (en) | 2010-02-11 |
WO2008047015A1 (fr) | 2008-04-24 |
FR2905488A1 (fr) | 2008-03-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2060084A1 (fr) | Architecture d'acces a un flux de donnees au moyen d'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 | |
US20070245376A1 (en) | Portable media player enabled to obtain previews of media content | |
WO2006053958A9 (fr) | Support personnel de mémoire de masse portatif et système informatique d'accès sécurisé a un espace utilisateur via un réseau | |
WO2006076516A2 (fr) | Fourniture personnalisable d'information audio | |
EP1938556B1 (fr) | Diffusion sans telechargement de documents multimedias numeriques sur un reseau de telecommunications | |
WO2008110087A1 (fr) | Procédé et système de lecture multimédia, côté client et serveur | |
FR2911214A1 (fr) | Procede de diffusion d'un contenu numerique, appareil et serveur pour la mise en oeuvre d'un tel procede | |
US20120117197A1 (en) | Content auto-discovery | |
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'acces a un ensemble d'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'emission correspondants | |
WO2005034541A1 (fr) | Procede, systeme et equipement pour la diffusion vers des terminaux d’informations relatives a des evenements futurs | |
FR2901386A1 (fr) | Support personnel de memoire de masse portatif et systeme informatique d'acces securise a un reseau par des utilisateurs. | |
FR3006542A1 (fr) | Programmation d'enregistrement de contenus audiovisuels presents dans une grille de programmes electronique | |
FR2797135A1 (fr) | Procede de production d'une base de donnees dans un televiseur, procede de gestion d'une base de donnees dans un televiseur | |
FR2816783A1 (fr) | Dispositif electronique, systeme informatique et procede pour la mise a disposition instantanee de donnees audiovisuelles | |
FR2882876A1 (fr) | Procede et dispositf de mise en relation automatique de terminaux proches |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20090303 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR |
|
AX | Request for extension of the european patent |
Extension state: AL BA HR MK RS |
|
RIN1 | Information on inventor provided before grant (corrected) |
Inventor name: GIROUD, OLIVIER Inventor name: SERVAL, THOMAS |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: RADIOLINE SAS |
|
DAX | Request for extension of the european patent (deleted) | ||
17Q | First examination report despatched |
Effective date: 20121002 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20130413 |