GB2476980A

GB2476980A - Jukebox system streaming track data requested from mobile device

Info

Publication number: GB2476980A
Application number: GB1000782A
Authority: GB
Inventors: Adam Castleton; Adam Paul Smith
Original assignee: JUKESTREAM Ltd
Current assignee: JUKESTREAM Ltd
Priority date: 2010-01-19
Filing date: 2010-01-19
Publication date: 2011-07-20
Also published as: GB201000782D0

Abstract

A method of selecting and delivering audio and/or video data tracks in a jukebox system for playing at a venue 1. A request containing an identification of a data track is sent from a mobile device 8 to a data network via a wireless access network. The request is received at a network server 4 and parsed to identify the requested track which is then streamed across the Internet from a streaming server 5. The streamed data is received at a receiver 3 located at the venue 1, and the data played out on a playback system 2 at the venue. The mobile device may be a mobile phone that sends the request as a short message service (SMS) message. Requested tracks may be queued in a playlist at the streaming server. If a track is not stored in a local database 6 it can be provided from a central server 9 having a master database 10.

Description

J U KEBOXES

Technical Field

The present invention relates to jukeboxes and in particular to a method and apparatus for allowing users to request the playing of tracks using mobile phones and the like.

Background

The conventional jukebox is a music player located in a venue such as a pub or restaurant. Music is stored on the player using for example compact disks (CDs), a hard disk drive, or a solid state memory. Where the storage medium allows, the music catalogue available on the jukebox may be updated by downloading tracks from a web server via the Internet. Typically, a user requests a track by making a selection on a user interface of the player and depositing a required payment into the player.

With the now widespread use of mobile phones, including smart phones, it has been proposed to make use of such devices to request tracks for playing on a jukebox. For example, US7,577,717 describes a system for playing tracks (including both audio and video tracks) in a public place, and which allows users to request tracks by sending text messages (SMS) either to the (local) player or to some central server which then instructs the jukebox to play the requested track. The user is charged for the service by the mobile network operator, and a proportion of this fee is given to the jukebox operator. W02006014739 also describes a system according to which a user can request the playing of a track by sending a text message from a mobile phone to a local jukebox system.

Whilst providing users with an entertaining and easy way to request tracks for playing on a jukebox, these known systems and methods suffer from the disadvantage that it may be difficult to handle copyright and royalty related matters. On the one hand it may be difficult for performing rights authorities to monitor which tracks have been played at a particular venue, and on the other hand it may prove an administrative burden on the part of the venue operator to record and report the required information.

Summary

It is an object of the present invention to avoid or mitigate problems associated with known remote jukebox systems. This object is achieved by streaming requested tracks to participating venues such that track data need not be stored permanently at the venues.

According to a first aspect of the present invention there is provided a method of selecting and delivering audio and/or video data tracks for playing at a venue. The method comprises sending a request containing an identification of a data track from a mobile device to a data network via a wireless access network, receiving the request at a network server and parsing the request to identify the requested track, and streaming data corresponding to the requested track across the Internet from a streaming server.

The streamed data is received at a receiver located at said venue, and the data played out on a playback system at the venue.

Said request may be sent from the mobile device within a Short Message Service, SMS, message, or alternatively over a packet data channel. Other delivery mechanisms are also possible. Said request may include in text format a track and/or artist name.

The method may comprise an initialisation step of tuning said receiver to a data stream provided by said streaming server.

The method may comprise receiving requests from a plurality of different mobile devices at said network server, performing said step of parsing the messages, queuing corresponding track data at the streaming server, and streaming the data across the Internet.

The method may comprise, upon receipt of said message at the network server and following parsing of the message, determining if the requested track is stored on a local database wherein, if the track is stored on the local database, the track data is provided to the streaming server, and, if the track is not stored on the local server, the track data is requested from a remote network server and the track data downloaded from that central server via the Internet and provided to the streaming server. In the event that the track data is downloaded from the central server, a copy of the track data may be stored in the local database.

Preferably, a copy of the streamed data is not stored at the receiver following playing out of the data on the playback system.

According to a second aspect of the present invention there is provided a computer server configured to cause streaming music and/or video data to be provided to at least one receiver via the Internet. The computer server comprises a receiver for receiving track requests from a plurality of users, a processor for determining track identifiers associated with said track requests, each track identifier identifying track data stored on a track database, and a track playlist controller for causing the track identifiers to be added to a playlist held by a streaming server.

Brief Description of the Drawings

Figure 1 illustrates schematically a system for handling user requests and for providing streaming music to one or more venues; Figure 2 illustrates schematically a procedure for attaching an Internet radio to a music stream; and Figure 3 is a flow diagram showing a process for handling user requests and for providing streaming music to a venue.

Detailed Description

Figure 1 illustrates schematically a system for allowing users to request, via their mobile phones, tracks including audio and video tracks to be played at any one of a number of venues 1. Each venue 1 is provided with a playback system 2 including, for example, amplifiers, loud speakers, display screens etc, and a streaming data receiver 3 (these entities are illustrated for only one of the venues shown in the Figure). The streaming receiver is connected to the playback system using, for example, standard RCA connectors. The streaming receiver is also connected to the Internet via a wired or wireless connection. This connection is preferably a broadband connection, e.g. an ASDL/SDSL connection. The streaming receiver 3 may be a standard computer, e.g. a personal computer, or a dedicated computer provided to the venue operator by a music service operator. In the latter case, the dedicated computer may be an Internet radio player, such as the P100TM radio player available from Revo Technologies Limited (www.revo.co.uk).

Also provided at the venue are signs (not shown in Figure 1) which indicate a telephone number to which jukebox requests should be sent. This number is unique to the venue. For example, a sign may display the message "text JUKE888 and song title/artist to 80806", where "888" uniquely identifies the venue. Larger venues may be assigned a unique phone number, with signs for example displaying the message "text song title/artist to 80806". Of course these information messages may be displayed on a television/computer screen. Information may additionally, or alternatively, be displayed on promotional material such as beer mats, leaflets, etc. Also coupled to the Internet are a service handling server 4, a streaming server 5, and a slave track database 6. These servers and the slave track database are operated by a music service provider with which the various venue operators have a service agreement. The music service provider in turn has a service agreement with a royalty collection agency such as the Performing Rights Society (PRS) in the United Kingdom.

The music service provider in turn subscribes to an SMS relay service provided by an operator such as EsendexTM. This service converts text messages sent by users to some predefined number into messages which are sent via the Internet to the service handling server 4. An SMS gateway server is indicated by reference numeral 7 in Figure 1, with a plurality of user mobile phones indicated by numerals 8.

It will be appreciated that the service handling server, streaming server, and slave track database may be implemented in practice as a group or cloud of connected servers and databases in order to provide sufficient capacity. In particular, the slave track database may be implemented on a Storage Area Network (SAN) accessible to all servers within the group.

Figure 1 also illustrates a central server 9 coupled to a master track database 10 and to the Internet. This server and database are operated by yet another service provider, for example iTunesTM or 7digitalTM.

Considering the case where the streaming data receiver 3 is an Internet radio player, the player is typically configured with a unique MAC address and a URL or IP address of some radio portal database that maintains a mapping between player MAC addresses and streaming URLs. When it is switched on, the receiver sends a GET request, containing its MAC address and an activation code, to the radio portal database. This is illustrated in Figure 2. The database returns the streaming URL, optionally including a username and password, to the receiver. Once received, the receiver sends a GET request to the streaming URL, e.g. "http://username:password@serverl.com/stream4.m3u". Upon receipt of this GET request, the streaming server authenticates the username and password and, assuming that authentication is successful, begins playing out a data stream held in a buffer or queue. If no actual requested tracks are queued for playing, the streaming server plays out either null data (silence) or "background" tracks. It is assumed here that all tracks are encoded using the MP3 format, and that all devices are, where applicable, configured to handle that format.

Considering now the operation of the system of Figure 1, in order to request the playing of a music track at a given venue, a user creates an appropriate text message, e.g. "JUKE888 michael Jackson thriller" and sends this to the advertised phone number using his or her mobile phone. It is noted that the track is identified in the message by a "free text" string, i.e. it is not necessary to include some track ID code as is required with prior art solutions. The message is routed, via the cellular network, to the SMS gateway server 7. The message is then routed onwards to the service handling server 4 via the Internet via an appropriate Application Programming Interface (API).

Upon receipt of the request at the service handling server 4, the message is parsed to identify the free text string. This string is used as a search query to determine whether or not the requested track is currently stored in the slave track database 6 (the slave database maintains a track index for this purpose). If the track is not stored in the database, the server 4 sends a query to the central server 9 which in turn queries its own master track database 10. The central server and associated master track database will store all tracks that are ever likely to be requested. Assuming that the requested track is stored in the master track database, the central server retrieves this from the database and sends it to the service handling server which stores the track in its slave track database (updating the track index). If the track cannot be found using the free text string, the service handling server 4 sends a track "not found" message to the SMS gateway server which in turn includes the message in an SMS message which is sent to the user. The user is riot charged for the service, although a standard network charge may be applied to the original SMS sent by the user. In the event that no match is found, the service handling server may send to the use an alternative suggestion, or a "closest match", with the user being give the opportunity to select the suggested track.

As an alternative to the above approach, the service handling server and slave track database may maintain a complete list of available tracks, and an indication of whether a track is currently held in the slave track database. If a track is known but not stored in the slave database, a download request is sent to the central server. If a track is unknown, an appropriate response is triggered to the user.

Assuming that the track is found, either directly within the slave track database or by retrieval via the central server, the service handling server 4 sends a message to the SMS gateway server to cause that server to send a chargeable SMS response to the user's mobile phone. The operator of the SMS gateway has an agreement with the user's mobile operator to handle allocation of charges, and also has an agreement with the music service operator to credit the operator's account. The user may or may not be required to send an acceptance SMS to the SMS gateway.

As has already been discussed, the streaming receiver 3 at the venue in question will already be listening to the streaming server's output. This output will include previously requested tracks stored within a playlist on the streaming server. The newly requested track is now added to that playlist by the service handling server 4. As and when required, the streaming server 5 retrieves a track from the slave track database 6, loads this into a buffer memory, and begins streaming the track data. The streamed data is received at the streaming receiver 3, where it is reassembled into the original track data. [The data may be encoded at the streaming server and decoded at the receiver to ensure that it is visible only to the authenticated party.] This data is then passed to the playback system 2. The data is not cached at the streaming receiver, other than temporarily for the purpose of reassembling the data and delivering it to the playback system. This avoids potential copyright problems on the part of the venue operator.

An interface may be provided to allow a venue operator to control certain aspects of the track playout system. This interface is typically a web interface and may be used via the streaming receiver if the receiver permits, or via a separate computer (where the operator logs on to the control system using his username and password). Aspects that may be controlled by the venue operator may include one or more of the following: * play mode (a jukebox with or without background music, play one track every x minutes, etc); * genre selections and schedules (rock on Friday nights, pop on Saturdays), i.e. to which selections are restricted; * a ban on requests from certain mobile phone numbers, or for explicit content or particular genres or tracks from requests (at specified times if required); * the sending of SMS advertising messages to customers who have requested tracks in their venue (customers may unsubscribe by replying with stop').

* account details, e.g. revenue.

The system described above may be enhanced with many new and interesting features. For example, an application may be installed on users' mobile phones which searches the phones for music tracks, allowing the user to easily select a favourite track for playing on the streaming jukebox system. An SMS may be generated automatically, prepopulated with the necessary track details.

To simplify the process of requesting a track, "geotagging" may be used to tag an SMS message request with a venue location. In this case, all SMS requests may be sent to the same telephone number.

It will be appreciated that, as an alternative to using SMS messages to request a track, the system may employ a data connection between mobile phones and their access networks. Such data connections are widely available, e.g. the GPRS network of GSM and 3G systems. Data connections effectively extend the Internet to mobile phones.

An appropriate application (or "app") installed on the phone can be used to exchange messages with the service handling server. Users may be charged for requesting a track using the SMS response approach described above, or by debiting a subscriber account. Another payment alternative is the use or pre-paid vouchers (e.g. scratch cards) that users may purchase at the venue.

It will be appreciated by the person of skill in the art that various modifications may be made to the above descilbed embodiments without departing from the scope of the present Invention.

Claims

CLAIMS: 1. A method of selecting and delivering audio and/or video data tracks for playing at a venue, the method comprising: sending a request containing an identification of a data track from a mobile device to a data network via a wireless access network; receiving the request at a network server and parsing the request to identify the requested track; streaming data corresponding to the requested track across the Internet from a streaming server; receiving the streaming data at a receiver located at said venue; and playing out the data on a playback system at the venue.
2. A method according to claim 1, wherein said request is sent from the mobile device within a Short Message Service, SMS, message.
3. A method according to claim 1, wherein said request is sent from the mobile device as data, over a packet data channel.
4. A method according to any one of the preceding claims, wherein said request includes in text format a track and/or artist name.
5. A method according to any one of the preceding claims, and comprising an initialisation step of tuning said receiver to a data stream provided by said streaming server.
6. A method according to any one of the preceding claims and comprising receiving requests from a plurality of different mobile devices at said network server, performing said step of parsing the messages, queuing corresponding track data at the streaming server, and streaming the data across the Internet.
7. A method according to any one of the preceding claims and comprising, upon receipt of said message at the network server and following parsing of the message, determining if the requested track is stored on a local database wherein, if the track is stored on the local database, the track data is provided to the streaming server, and, if the track is not stored on the local server, the track data is requested from a remote network server and the track data downloaded from that central server via the Internet and provided to the streaming server.
8. A method according to claim 7 and comprising, in the event that the track data is downloaded from the central server, a copy of the track data is stored in the local database.
9. A method according to any one of the preceding claims, wherein a copy of the streamed data is not stored at the receiver following playing out of the data on the playback system.
10. A computer server configured to cause streaming music and/or video data to be provided to at least one receiver via the Internet, the computer server comprising: a receiver for receiving track requests from a plurality of users; a processor for determining track identifiers associated with said track requests, each track identifier identifying track data stored on a track database; and a track playlist controller for causing the track identifiers to be added to a playlist held by a streaming server.