Patent Application
20100142521
The present invention generally relates to a method of and a system for providing near live disc jockey (DJ) audio commentary segments to one of a streaming Internet radio station host or a user device for real-time insertion into a music playlist.
In general, with increased geographic coverage and per device bandwidth capabilities of the emerging mobile internet technologies, traditional radio will now have many opportunities to exploit new business models and network architectures.
More specifically, there is a need for a service which allows a customized playlist for users on their mobile devices, but at the same time provides the near live DJ commentary which still gives the fresh feel of a traditional AM/FM terrestrial radio broadcast.
The present invention generally relates to an Internet radio service which provides near live DJ style segments, also known as snippets, providing DJ commentary to host facilities of internet radio stations or directly to client devices such as a user's mobile device for late binding and, more particularly, to a method of and a system for implementing such an internet radio service.
According to one aspect, the present invention provides a method of providing near live disc jockey (DJ) audio commentary segments to a client device including one of an internet radio station host streaming device or a user device for real-time insertion into a music playlist, the method comprising: transmitting at least one metadata segment packet to the client device; transmitting at least one audio content segment packet to the client device, the at least one audio content segment packet matching directly to the at least one metadata segment packet; and receiving at least one usage segment packet as a response from the client device.
The present invention further provides a system for providing near live disc jockey (DJ) audio commentary segments to a client device including one of an internet radio station host streaming device or a user device for real-time insertion into a music playlist, comprising: means for transmitting at least one metadata segment packet to the client device; means for transmitting at least one audio content segment packet to the client device, the at least one audio content segment packet matching directly to the at least one metadata segment packet; and means for receiving at least one usage segment packet as a response from the client device.
The present invention further contemplates a computer readable medium comprising a program for instructing the system to perform the above-described operations.
Those skilled in the art will appreciate the scope of the present invention and realize additional aspects thereof after reading the following detailed description of the preferred embodiments in association with the accompanying drawing figures.
The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the invention, and together with the description serve to explain the principles of the invention.
The embodiments set forth below represent the necessary information to enable those skilled in the art to practice the invention and illustrate the best mode of practicing the invention. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the invention and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims.
As clients use one (or more) of the DJ snippets, an authentication is provided back to the service and allows closure of the business model. If the DJ snippets are advertisement based (or supplemented), the authentication provides a tracking means to bill the advertiser as shown at 4 in
An exemplary format of the multicast and unicast network streams for this system are shown in
Metadata transmit timestamp 11 (transmit timestamp of the metadata packet);
The separate timestamps 16 provide a method to predict arrival of the snippet packet (i.e., by using the delta of the timestamps, network delays can be eliminated). The DJ snippet ID 12 is a unique identifier or serial number for tracking of multicast metadata snippet or segment packets (MSPs) to multicast audio content snippet or segment packets (CSPs). Use of a separate DJ snippet ID 12 (versus using the timestamp 16) allows for many metadata multicast feeds to co-exist on the same network. For example, one DJ snippet metadata multicast 10 may be for rock stations, while others are for jazz and country. The snippet DRM key 13 allows the client device 2 to decrypt the MSP. A unique key for each snippet allows selected authorization for clients (i.e., advertisement (ad) supplemented services would have access to certain snippets while subscription services would have access to additional snippets). Using the key also allows hacked clients to be turned off, and update real clients with new decryption algorithms. Finally, the metadata for the MSP may include, but would not be limited to, the following:
For instance, the DJ identifier may just include a uniform resource locator (URL) and subdirectory to a full description of the announcer. In a similar fashion, the music related metadata may also point to a URL and subdirectory detailing matching characteristics. For both of these, the client device 2 using the service would first go to the URLs to identify relevant DJ and music tags. One skilled in the art will recognized many methods and usage of metadata matching to content playlists.
The DJ multicast audio content snippet or segment packet (CSP) (e.g., #1105) comprises a DJ content snippet ID 21, a DJ content snippet transmit timestamp 22 and a DJ snippet encrypted content 23, which match directly to the metadata broadcast. The order of information within the snippet packets in both the DJ snippet metadata multicast 10 and the DJ snippet audio content multicast 20 may be arranged differently than shown in
The upstream return path from the client devices 2 shown in
Also, (although not shown in
This supplemental data can be used in conjunction with actual usage data for feedback to DJs to better target the listening audience. This may be of most benefit when the ratio of client devices to DJs is low.
A block diagram showing a control system including components for operating the JIT near live DJ service 1 is illustrated in
Content from the creation function goes into a memory in the form of a DJ snippet content staging buffer 50 for short term storage until fetched to be multicast. Metadata is aggregated, sorted for a given multicast as at 51, and scheduled for transmission via timestamps 52. The scheduling function identifies multicast and transmission times to the audio snippet staging buffer 50. Finally, metadata snippet or segment packets (MSPs) are sent to the correct metadata multicast streamer 60, and content snippet or segment packets (CSPs) are sent to their respective content multicast streamer 70. Actual transmission timestamps 52 are applied as packets are sent. Returned client authentication packets in the form of client usage snippet or segment packets (USPs) are received via a unicast network interface 80. The packets are processed for billing purposes (such as ad sponsors) as shown in
Further details of the snippet or segment creation function is shown in
In parallel to the tagging functions, unique snippet IDs are generated as shown by a snippet ID generation function 120 and DRM encryption keys are generated for each snippet as shown by a DRM unique key generation function 125. As content is sent for tagging, content is also DRM encrypted to the key as shown by a content DRM encryption function 130. Finally, the snippet ID generated by the snippet ID generation function 120, key generated by the DRM unique key generation function 125, and encrypted content generated by the content DRM encryption function 130 are sent to the snippet content packet generation function 135 and output to the staging buffer 50 of
A block diagram showing integration of the client plug-in 150 to a user device 3 is shown in
A simple example would be in support of a use case for vendor branded internet radio the ecosystem of which is shown in
In the example, a vendor/retailer 207 partners with the large internet radio conglomerate 200 to provide a client (user owner mobile device 205) based radio station with the intent of providing direct and indirect advertising for the vendor/retailer 207. The large Internet radio conglomerate 200 provides access to content and royalties tracking for usage of the station via business relationships with a large content provider 208. The content maybe initially watermarked to identify that it is for radio station usage only and not for resale. The large internet radio conglomerate 200 would then DRM lock the content and provide the same to the vendor/retailer 207. The vendor/retailer 207 then provides distribution of the client and DRM locked content for access by only the user's mobile device 205.
The user then downloads/receives the radio station client for their mobile device 205 when visiting the vendors/retailer 207. Additionally, the user receives DRM locked content (such as music) as a reward for visiting the vendor/retailer 207 or based on purchases from the vendor/retailer 207. In addition to downloading the application and content, a user profile based on purchasing records may be obtained. Moreover, the user may activate the radio station through a common user interface and playback device that operates the vendor/retailer 207 radio station as a plug-in.
The present invention has substantial opportunity for variation without departing from the spirit or scope of the present invention. For example, as alternative embodiments, the centralized model may be distributed in any form most suitable to network topology and location of client or re-streaming internet radio host sites. Separation may also be imposed to better match national and local listening audiences.
Further, audio snippets may be watermarked prior to encryption to prevent unauthorized reuse if client devices become compromised. The watermark would contain snippet ID and copyright information for the service. Other protections may include separating DRM keys from the metadata multicast and have the client plug-in negotiate a common key or individual snippet keys from the centralized service.
Specialized ad or subscription models may also be provided, allowing garage shop internet radio stations to have a more polished and professional appearance. This may require additional back-office and hosting radio station interfaces.
Such a DJ service could be key offering of large radio station owners and potential local franchises allowing for leverage of internet radio functionality while still providing the fresh feel of AM/FM terrestrial radio. Business models include ad based or subscription services as discussed previously.
While a multicast embodiment has been described above as an exemplary embodiment, the present invention is not limited thereto. In this regard, as shown in
However, as shown in
In another embodiment, Peer-to-Peer (P2P) techniques are used to establish an “Application-Level Multicast” (ALM) distribution channel from the Snippet Service source to the receiving Client Device. In this case, the first steps are identical to steps 1-3 from the unicast embodiment above, but then at step 4, the Snippet Service transmits each packet via unicast to only a subset of the subscribing Client Devices. On receiving each packet, these Client Devices then propagate it via unicast to a subset of other Client Devices that may have not yet received the packet. This propagation continues recursively until every Client Device receives each packet. The Client Devices may communicate with each other in a distributed manner, and/or with a central server (the Snippet Service,) to organize themselves so as to achieve the most efficient distribution of packets. Thus, in the ideal case, none of the involved devices—neither the Snippet Service nor any of the Client Devices—have to transmit every packet to every other device, but only a small subset, greatly reducing the load on any single device. In this way, the Client Devices simulate multicast functionality at the Application layer rather than rely on it at the Network layer (in reference to the 7-layer OSI model). Thus, the present invention is not limited to the multicast embodiment and also contemplates a unicast embodiment or a peer-to-peer embodiment or a combination of all three.
Those skilled in the art will recognize improvements and modifications to the preferred embodiments of the present invention. All such improvements and modifications are considered within the scope of the concepts disclosed herein and the claims that follow.
