ARCHITECTURE FOR ACCESSING A DATA STREAM BY MEANS OF A USER TERMINAL

• US 20100036893A1
• Filed: 09/04/2007
• Published: 02/11/2010
• Est. Priority Date: 09/04/2006
• Status: Abandoned Application

• Current Assignee: Baracoda
• Original Assignee: Baracoda
• Inventors: Giroud, Olivier, GIROUD, Olivier, Serval, Thomas
• Application Number:
  US12/439,889
• Publication Number:
  US 20100036893A1
• Time in Patent Office: Days
• US Class Current: N/A
• CPC Class Codes: H04L 63/0807 using tickets, e.g. Kerberos cryptographic mechanisms or cryptographic arrangements for entity authentication using tickets or tokens H04L9/3213
• CPC Class Codes: H04L 63/083 using passwords cryptographic mechanisms or cryptographic arrangements for entity authentication using a predetermined code H04L9/3226
• CPC Class Codes: H04L 63/102 Entity profiles
• CPC Class Codes: H04L 9/40 Network security protocols

Abstract

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

Claims

1. A user terminal comprising:

storage means and calculation means;

a man-machine interface having display means and input means;

means for connection to a TCP/IP network, for accessing audio files available from audio streaming server, each audio file being located by an URL;

means for decoding the data stream transmitted by said server; and

means for reproducing sound from said decoded data stream,

characterized in that said storage means comprise a cache memory to store the terminal use history, said cache memory being a volatile memory and being of reduced size,

and in that said terminal further comprises means for communicating with a services platform, said communication means being capable of emitting HTTP GET requests toward the platform and of receiving requests in the XML-Phoenix format from the platform.

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

3. An architecture for accessing audio files available from audio streaming servers, each audio file being located by an URL, characterized in that it comprises a terminal according to claim 1 and a services platform capable of collecting from third-party servers heterogeneous resources-related data and converting them into the Phoenix format, and in that, when receiving a response in the XML-Phoenix format from the platform, the terminal is capable of connecting to the streaming server whose URL is contained in said response.

4. An architecture according to claim 3, characterized in that said platform comprises:

an in-line part comprising a virtual storefront interface managing the communication exchanges with the user terminal;

a transaction engine;

a database comprising a general catalogue, a user catalogue, users and equipments profiles;

an off-line part comprising a copy of said database; and

a module for collecting and converting heterogeneous resources-related data, capable of communicating with third-party servers and of recording the converted data into said database copy;

a means for synchronizing the content of the database copy of the off-line part with the database of the in-line part.

11. An architecture for accessing audio files available from audio streaming servers, each audio file being located by an URL, characterized in that it comprises a terminal according to claim 2 and a services platform capable of collecting from third-party servers heterogeneous resources-related data and converting them into the Phoenix format, and in that, when receiving a response in the XML-Phoenix format from the platform, the terminal is capable of connecting to the streaming server whose URL is contained in said response.

5. A communication method using the TCP/IP protocol between a user terminal and a services platform, said user terminal being capable of accessing an audio file available from an audio streaming server, said audio file being located by an URL,

characterized in that said method consists in:

authenticating the user terminal with the services platform;

updating the cache memory of the user terminal based on the information saved on said platform;

the terminal user emitting a request in the HTTP GET format toward the platform, said request comprising, among other things, the alias of an audio file;

the platform emitting a response in the XML-Phoenix format toward the user terminal, said response containing, among other things, the URL corresponding to said audio file, said terminal then connecting to the corresponding streaming server to access the audio file associated with said URL.

6. A method according to claim 5, characterized in that said step of updating the cache memory is performed a first time at the power-on of the user terminal, and in that said first step of updating comprises:

emitting a first request in the HTTP GET format to ask for a list of elements of the cache to be updated;

receiving a response in the XML-Phoenix format comprising the list of elements to be updated, said list being memorised in said cache memory.

7. A method according to claim 5, characterized in that each element of the cache comprises an attribute defining its validity time-period, and in that said step of cache updating is performed at expiry of this validity time-period for updating the corresponding element.

8. A method according to claim 5, characterized in that updating an element consists in emitting a HTTP GET request asking the services platform for the content of the element to be updated, followed by the platform emitting a response in the XML-Phoenix format giving the content of the element to be updated, wherein this request-response transaction can be performed in background.

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

10. A method according to claim 9, characterized in that the password associated with an Radio IP is the result of applying an algorithm MD5 to the concatenation of the character strings comprising at least the MAC address of the user terminal, the token value of the last synchronization step or, if not, the factory setting value, and the count value of the request-response transactions between the user and the platform from the last synchronization step.

12. A method according to claim 6, characterized in that each element of the cache comprises an attribute defining its validity time-period, and in that said step of cache updating is performed at expiry of this validity time-period for updating the corresponding element.

13. A method according to claim 6, characterized in that updating an element consists in emitting a HTTP GET request asking the services platform for the content of the element to be updated, followed by the platform emitting a response in the XML-Phoenix format giving the content of the element to be updated, wherein this request-response transaction can be performed in background.

14. A method according to claim 7, characterized in that updating an element consists in emitting a HTTP GET request asking the services platform for the content of the element to be updated, followed by the platform emitting a response in the XML-Phoenix format giving the content of the element to be updated, wherein this request-response transaction can be performed in background.