HK1169877B

HK1169877B - Digital downloading jukebox system with central and local music servers

Info

Publication number: HK1169877B
Application number: HK12110436.7A
Authority: HK
Inventors: 盖伊．内森; 多米尼克．迪恩
Original assignee: 陶诗通公司
Priority date: 2005-07-21
Filing date: 2012-10-19
Publication date: 2017-08-25

Description

Digital download jukebox system with central and local music servers

This application is a divisional application of the invention patent application entitled "digital download jukebox system with Central and local music Server" filed on 12.1.2006 with application number 2006100051348.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present invention is a continuation-in-part application of No.10/661,811, filed on 5/12/2003, claiming priority of the provisional patent application No.60/410,832, filed on 16/9/2002, entitled "digital download jukebox system with central and local music servers," the contents of which are hereby incorporated by reference.

Technical Field

The present invention relates to jukebox systems, and more particularly to digital download jukebox systems of the type that generally include a central server and remote jukebox devices that communicate with the central server to account for royalties and/or update content. Exemplary embodiments of the present invention improve such a jukebox system by providing a local server for each jukebox device in the network of jukebox systems. The local server provides a second, broader source of content (i.e., audio and/or visual data) that can be selected by the user of the jukebox device for reproduction on the jukebox device. The local server preferably provides a mirror of the central server so that the entire audio and/or visual database is readily available to each jukebox device without the need to download the requested content from the central server that is not present on the mass storage device of the jukebox device itself. The overall set of local servers may also function as a network of distributed content servers to be controlled by the central server through each jukebox device to provide services to other devices, such as non-portable jukebox devices. In addition, under the control of the central server, the jukebox device and the local server function as a "central hub" or management device for the various downloadable charging devices co-located with the jukebox device.

Background

Jukeboxes have existed for some decades or so and provide users with the ability to conveniently and advantageously select desired music for reproduction. Jukeboxes are typically located in commercial establishments, such as restaurants and bars, to provide desired music on demand for its customers for a fee. In recent years, a new generation of jukebox devices have become available that provide significant operational improvements to all parties involved. More specifically, conventional stand-alone record or CD jukeboxes are being replaced by digital download jukeboxes that are controlled by and communicate with a central server. An example of this new generation of jukebox system is shown in U.S. patent No.6308204, which is incorporated herein by reference in its entirety. The primary provider of this new generation of jukebox systems is touch units Music Corporation.

FIG. 1 shows an overview of an exemplary embodiment of a digital download jukebox system 10 (hereinafter referred to simply as a "jukebox system"). As shown in FIG. 1, the jukebox system 10 includes a central server 12, the central server 12 containing a master library of audio content (typically music) that can be downloaded therefrom, and alternatively, audiovisual content (typically music and associated video or graphics). The jukebox system also includes a series of remote jukebox devices 16, 16a-16 f. These jukebox devices are typically located at bars, restaurants, clubs or other desired locations and are capable of playing music in response to receiving payment from a user, such as coins, banknotes, credit/debit cards, etc., and causing one or more songs to be selected by the user for play. In an alternative embodiment, the music service is paid by the location for a subscription fee, and the music selected is free to the end user. The jukebox device 16 generally includes a screen 18 that presents information to the user and allows the user to select songs therefrom, and an audio system 20 that plays the selected songs. The screen 18 is also used to display video or graphics related to the song. The screen 18 may also be used to display advertisements for the jukebox itself to attract customers, to display other types of advertisements, and/or to display any other desired information.

The jukebox devices 16 (sometimes referred to simply as "jukeboxes") communicate with the central server 12 via a communication network 14, such as the Internet. The jukeboxes 16 periodically communicate with the server 12 to provide information to the server 12 regarding the particular songs that have been played on the jukebox. The central server then uses this information to determine the appropriate royalties and/or other payments owed to the songs played on each jukebox. Thus, one significant advantage of this new generation of jukeboxes is that sound reproduction and/or other appropriate music rights can be adhered to more accurately and reliably, thereby ensuring that proper royalties are paid to artists or music owners. The central server 12 can also provide new songs to the jukebox 16 to keep the appropriate or most popular songs on the jukebox based on the particular customer at the location. Thus, the songs available on each jukebox can be customized through communication with the central server to provide the types of songs and/or music that are typically requested by the customer at each jukebox location. As described in the above-referenced U.S. patent No.6308204, the central server may also be advantageously used to update operating software on the jukebox in order to change the operation of the jukebox, such as to provide new or improved functionality. Thus, another significant advantage of this new generation of jukeboxes is the ability to remotely change songs (or other audio and/or visual content), as well as the operation of the jukebox itself, as desired, without having someone (e.g., a salesman) personally maintain the jukebox. Instead, such updating may be accomplished using the central server 12.

As described above, the jukebox devices 16 each include a mass storage device, such as a hard drive, that stores the songs and associated video/graphics data (if any), as well as any other desired graphical information for rendering on the jukebox. The mass storage of the jukebox is typically limited in storage capacity relative to the storage device of the central server 12. Thus, only a small portion of the songs stored on the central server are actually stored on the mass storage of the jukebox at any one time. There are other reasons for having limited storage capacity on the jukebox and/or limiting the number of songs stored on the jukebox, such as security of the data or limited space on the jukebox itself. For example, on wall-mounted jukeboxes and the like that are designed to be smaller in size than free-standing types, physical space is limited. As described above, the songs on the jukebox can be changed through communication with the central server, but at any one time, any one jukebox only maintains a portion of the entire library of songs maintained by the central server.

In order to maximize the revenue generated by the jukebox, it is important that the most desirable songs exist on the jukebox over time. If the customer cannot find their favorite songs on the jukebox, the jukebox usage (and resulting revenue) will be significantly reduced. On the other hand, it is not possible to predict in advance exactly what a customer located at any particular location wishes to play on the jukebox. In fact, there may be many instances where a customer has selected a song that is present on the central server but is not currently on the jukebox. Thus, the jukebox is not appreciated and cannot be used to the fullest extent. To address this problem and increase revenue, jukebox systems in the past have provided functionality that enables a user to search for songs on a central server from a jukebox and request immediate downloading of desired songs from the central server to the jukebox at a premium. This functionality enables a user to play any song in the master library of songs maintained by the central server using the jukebox, regardless of whether that particular song is currently stored in the mass storage of the jukebox itself. Thus, the user can first look for the desired song on the local storage of the jukebox and then further search for the desired song on the central server, if desired. In contrast to standard playback directly from the local storage of the jukebox, jukebox devices typically charge a premium (e.g., 5 credits instead of one credit) for the immediate download and playback of songs from the central server.

However, one problem with the immediate download function is that it is desirable to implement an immediate, high speed connection to the central server. In addition, the central server and network must be ready and able to reliably and efficiently process such requests so that the function works properly. These requirements are not always satisfied and thus, the implementation of this function is limited. For example, many locations with jukeboxes do not have high speed connections (e.g., DSL), but rather use dial-up modem connections. Jukeboxes that rely on dial-up connections are typically only designed to communicate with a central server on a regular basis and do not allow the user to download songs immediately. However, they enable the user to vote on a song to be downloaded later when the dial-up connection is established. This is of course not sufficient to be as satisfactory to the user as downloading a song directly. Other problems arise with this download functionality if the network or server is not currently available for downloading due to traffic, failure, etc.

For the reasons stated above, there is a need for a jukebox system that overcomes these and other deficiencies. The present invention addresses these and other problems and provides more functionality to such jukebox systems.

Disclosure of Invention

According to an exemplary aspect of the present invention, a local content server is provided for each jukebox in the jukebox system. The local server preferably mirrors a master library of songs (and/or other content) on the central server. The local server is installed in the vicinity of the jukebox to which it is assigned, preferably in the same restaurant or bar in which the jukebox is installed. The local server may even be installed within the housing of the jukebox device if space permits. However, the local server is preferably installed only at a convenient location and is connected to the jukebox using a high-speed connection, such as Ethernet or the like. According to an exemplary embodiment, the local server is used to implement the immediate download functionality described above without requiring a high speed connection to the central server. In other words, the user may first search the local storage on the jukebox for the desired song, and then further search the local server for the desired song, if desired. If the desired song is found on the local memory, the desired song is played from the local memory for a standard fee. If, on the other hand, the song is found only on the local server, then at the user's option, the song may be downloaded immediately from the local server to the jukebox for play for a fee, preferably greater than the standard fee. Thus, the immediate download function can be reliably implemented regardless of the type of connection to the central server, and regardless of the availability of the network or the central server. Furthermore, since the download is from a local server, rather than a central server, it is transparent to the user.

In another exemplary aspect, the jukebox is configured with a locally-connected extended storage medium. Although not as large as the server drive in the preferred embodiment above, in one embodiment the storage medium holds approximately 20% of the songs on the central server. Studies have shown that a song group containing approximately the top 20% of the most requested songs will satisfy approximately 80% of the end-user's play requests. In another exemplary embodiment, the media may hold about 30% of the songs on the central server, which is relevant to about 90% of the end-user's requests. The amount of song data stored on the media may be any suitable amount to accomplish the desired function. For example, if the new data indicates that only 10% of the songs need to be saved, then the amount should be the appropriate amount to be saved.

According to another exemplary aspect of the present invention, a local server or storage medium is periodically updated with data (e.g., songs) to correspond to the contents of a master library of data (e.g., songs). The update may be done remotely using a dial-up or broadband connection, or it may be manually updated by the operator using an update tool provided by the entity controlling the jukebox system that can be directly connected to the jukebox or local server to update the local server or storage media so that the content corresponds to the master library on the central server, or so that the content corresponds to at least the currently desired percentage of the most frequently selected songs.

According to another exemplary embodiment of the present invention, the server includes a hard disk drive array with an associated IDE controller, a microprocessor, a flash memory containing a BIOS and operating system, a RAM and an Ethernet controller in communication with the jukebox. Each local server is preferably assigned to or registered with the particular jukebox to which it is connected. From a security perspective, the data on the local server preferably does not contain any complete songs. Instead, the jukebox device includes the missing data for each song on the local server, such that the jukebox can compose an entire song from the contents of its memory and the contents of the local server. The data on the local server is also preferably encrypted with the missing data (e.g., a block of data) to prevent any device other than the jukebox to which the local server is assigned from copying or playing the song from the local server.

According to another exemplary aspect of the invention, a collection of local servers may be used as a network of distributed servers that may be controlled by a central server to provide music services to other devices that may be connected to the network through which the central server and jukebox communicate. For example, in addition to providing song services to a particular jukebox connected and assigned, a local server and associated jukebox are used to deliver any requested song to a dedicated residential or commercial jukebox device (or other suitable jukebox device).

According to another exemplary aspect of the invention, the local server and the jukebox device are used to provide management services to other types of slot or payment triggering devices, such as gaming devices, installed in the same location as the jukebox, under the control of the central server. In other words, the jukebox system is preferably used to update the functionality of and/or manage other downloading devices that exist at the same location. Thus, the jukebox functions as a "central hub" for all downloading devices in a location. In one embodiment, this feature is implemented by networking all the download devices in a single location with the jukebox and local file server. The central server may then download the information to the local server, along with instructions to the jukebox as to what data and/or software to update which devices to apply. The jukebox device and local server may also be used to collect information from other downloading devices it is managing and upload that information to the central server for reporting/billing purposes. Thus, the jukebox system owner/operator can act as a third party service provider for other coin-operated equipment companies to manage and/or update their equipment, such as electronic gaming devices.

According to another exemplary aspect of the exemplary embodiments, the jukebox has or is given the processing power to play multiple songs simultaneously, with different outputs to different zones. In a preferred embodiment, three zones are included: restaurants, bars and billiard room establishments can have many choices played simultaneously, up to the number of zones or speaker outputs. It facilitates increasing revenue in jukebox systems because customers in either area can listen to a selected song while customers in another area listen to a different song.

According to another exemplary aspect of the exemplary embodiments, a user may select to play a song in more than one area of a commercial establishment. Such playback may be performed simultaneously in multiple zones, or may be performed at different times. This allows the jukebox operator to gain additional revenue for playing the song, and possibly even a greater amount of revenue to ensure that the song is played simultaneously in multiple areas of the establishment, than if the same song were played at once.

According to another exemplary aspect of the exemplary embodiments, each zone is provided with a terminal that allows customers in that zone to select songs for play on the jukebox. In a preferred embodiment, the terminal is a "virtual" terminal equipped with a Graphical User Interface (GUI) for song selection, but a game terminal or any other suitable device capable of providing a GUI may be used.

According to another exemplary aspect of the exemplary embodiments, the operator can limit the selections that can be played in a designated area. For example, in a restaurant section of a multi-section establishment, the operator wishes to limit the music to music that is suitable for the dining atmosphere. The operator may also limit or allow other aspects of the selected play in each zone, such as volume, priority play availability, etc.

According to another exemplary aspect of the exemplary embodiments, the jukebox may be provided with an algorithm or other method of selectively selecting background music based on the zone, time, or any other suitable criteria.

According to another exemplary aspect of the exemplary embodiments, different zones may have separate priority play queues and non-priority play queues.

According to another exemplary aspect of the illustrative embodiments, a jukebox with extended song storage capabilities may only provide a subset of the total songs stored as the base available songs. If the user desires a song that is not a member of the provided subset, the user may pay an additional fee to have the song played. If the song is stored in a larger master collection on the extended storage capacity, the song may be immediately queued up without downloading, allowing the user to more quickly access the extended song selection. The user may order the song even if it is not present in the extended list, and may hear the song almost immediately if appropriate conditions, such as a high speed connection, are present. Alternatively, the song may be downloaded and saved for selection by the user at a later date or time, such as when the jukebox is connecting in a dial-up mode and the song needs to be downloaded at a later time.

According to another exemplary aspect of the exemplary embodiments, the jukebox may be set to a "custom mode" in which the user may use the interface to select songs to be transferred from the local server or the extended media storage to the jukebox or group of jukeboxes. After the jukebox is newly installed at a location, the schema may be used by old users or old customers and location personnel to specify which songs should be permanently present on the jukebox.

In accordance with another exemplary aspect of the illustrative embodiments, the jukebox may "morph" based on the triggering event. The triggering event may include a commercial establishment's theme night, time change, or any other suitable criteria. When the jukebox is morphed, it may provide a subset of the different available songs, in whole or in part, for selection by the user at a standard fee. In addition, because the interface is a digital interface, new graphics, advertisements, or other suitable display changes may appear in accordance with the variations. The distortion may also selectively prevent all access to certain songs based on the suitability of the songs under the criteria that caused the distortion. For example, if a commercial establishment holds "Country nights," the available songs will become all Country songs. The jukebox may also block extended access to all songs defined as unsuitable for "Country nights," such that even if the price paid increases, such closed songs cannot be played until the distortion expires. The definition of "appropriate songs" may be a factory set definition or may be defined by the jukebox operator or by any other suitable sorting mechanism.

According to another exemplary aspect of the exemplary embodiments, different terminals of a multi-zone system may be deformed independently of each other, so that after a certain hour, a bar zone may be deformed (morph) while a restaurant zone may remain unchanged.

According to another exemplary aspect of the illustrative embodiments, a user may bid for the right to play a song before other songs previously selected for priority play are played. In a preferred embodiment, the user is shown the highest price paid for priority play, and the user may pay a higher fee than this price to obtain the highest priority available.

According to another exemplary aspect of the exemplary embodiments, the user is not allowed to be shown how much the other person paid for the priority. However, the user may pay the money he wants to spend in order to obtain the priority order, and then receive the priority order based on the amount paid.

However, according to another exemplary aspect of the exemplary embodiments, the user may pay money he wants to spend, and then be displayed with a priority position that has been obtained according to the amount paid. If the location is not satisfactory to the user, the user may pay an additional fee to advance the prioritization of the songs. The user may also pay additional fees to make it more difficult for other users to pre-fetch the selected priority location on the priority list in bidding situations. Any other suitable method of increasing the payment amount and thereby increasing the priority may also be implemented.

According to another exemplary aspect of the exemplary embodiments, the user may "lock" the prioritization if the preselected amount is paid. For example, if the user pays 15 credits (credit) to get a 3 rd priority and wishes to guarantee a third order, the user may pay 4 more credits to "lock" the order. Since locking the sequence also requires a "lock" that is higher than all sequences of the user, the user is required to pay a certain amount in order to "lock" all songs above the user's selection. In one such scenario, the user may choose to pay the price reported as "locked out," or pay a credit of the same amount or a change in amount in an attempt to prevent future over-pricing, or to advance the user's songs further in the priority list.

In accordance with another exemplary aspect of the illustrative embodiments, any of the foregoing bidding strategies may be implemented, and the user may be shown how much each person paid for their particular sequence. This allows the user to know exactly how much he has to pay to obtain a certain preferred location. If the "lock" function is implemented, this also allows the user to know whether it is cheaper to pay the price of "locking" the song or to pay to advance the song on the priority list. All of these options result in increased revenue for the operator.

Drawings

These and other features, objects and advantages of the present invention will be further understood by reference to the following detailed description of the invention when read in conjunction with the accompanying drawings, wherein:

FIG. 1 is a block diagram of a conventional downloading digital jukebox system;

FIG. 2 is a block diagram of an improved download digital jukebox system in accordance with a preferred embodiment of the present invention;

FIG. 3 is an exemplary screen shot showing an initial selection screen of a preferred embodiment of a jukebox system in accordance with the present invention;

FIG. 4 is another screen shot showing an exemplary search screen for use in searching songs on a local server in accordance with a preferred embodiment of the present invention;

FIG. 4A shows an exemplary process for searching for songs that fit in a user-specified profile (profile) using a personal music assistant;

FIG. 4B shows an exemplary process for searching for songs that may be appropriate for the identified user profile using a personal music assistant;

FIG. 5 is another exemplary screen shot showing the results of a search on a local server and providing the user with the option of downloading a desired song to the jukebox device for a fee, in accordance with a preferred embodiment of the present invention;

FIG. 5A shows an exemplary process for searching through a list of popular songs;

FIG. 6 is another exemplary screen shot showing an alternative method of allowing use of the download functionality of the present invention;

FIG. 7 is a block diagram of a preferred embodiment of the local server of the present invention;

FIG. 8 shows a block diagram of an exemplary overall network including commercial jukeboxes and residential jukeboxes, as well as other downloading devices and associated connections managed by the jukebox system of the present invention;

FIG. 9 shows an overhead view of an exemplary establishment layout for a multi-zone jukebox system;

FIG. 10 shows an overhead view of an exemplary establishment layout for a multi-zone jukebox system with selection terminals in each zone;

FIG. 11 is a flow chart showing an exemplary implementation of a zone selection process for a multi-zone jukebox system;

FIG. 12 is a flow diagram showing an exemplary implementation of priority play by the zone selection process for a multi-zone jukebox system;

FIG. 13 shows an exemplary implementation of a multi-zone set of priority and non-priority queues having a subset of queues per zone;

FIG. 14 is a flow chart showing an exemplary distribution and initialization scheme with morphing (morph) capabilities;

FIG. 15 is a flowchart showing an exemplary implementation of a jukebox morph initiation process based on a triggering event;

FIG. 16 is a flow chart showing an exemplary implementation of a jukebox morphing process;

FIG. 17 shows the relationship between a jukebox with extended media storage and a central server;

FIG. 18 is a flowchart showing an exemplary process for a song selection process when a song is not in the "standard" available playable song list;

FIG. 19 is a flow diagram showing an exemplary process for a priority play queue with bid-based prioritization capabilities.

Detailed Description

Referring now to the drawings, FIG. 2 shows a block diagram of an exemplary preferred embodiment of an improved jukebox system 10'. The jukebox system 10' includes similar components as shown in FIG. 1 and described above, including a central server 12, a communication network 14 and remote jukebox devices 16, 16a-16 f. However, the jukebox system 10' also includes a local server 22, 22a-22f connected to each of the jukebox devices 16, 16a-16f, respectively. The central server 12 includes a master library of songs (and/or other content). Each jukebox device includes a subset of the master library on a local storage of the jukebox. The central server may be used to individually manage the contents of the jukebox by monitoring the use of the jukebox devices and updating a subset of the songs on each jukebox device in an attempt to maximize its use. The central server 12 periodically receives data from each jukebox to account for royalties and pay for songs played. The jukebox device may be connected to the network in any suitable manner, such as a dial-up modem or a broadband modem (e.g., DSL, cable, wireless broadband, or satellite). The communication network 14 may be any suitable network capable of distributing data (e.g., audio-visual data) from the central server 12 to the jukeboxes 16, and enabling data to be uploaded from the jukeboxes 16 to the central server 12.

Before sending the songs to the jukebox, the songs (and/or other data) are preferably digitized, compressed, and encrypted by the central server 12 using known techniques for security and bandwidth considerations. The songs are then decompressed and decrypted by the jukebox for storage and reproduction on the jukebox. Thus, each jukebox maintains a library of digitized songs in a database for playing on the jukebox, wherein the library of songs can be changed or updated by the central server through communication. The jukebox also preferably receives and stores data constituting images (e.g., still and/or moving video and/or graphical images) that may be displayed on the display 18 of the jukebox device 16. In an exemplary embodiment of the present invention, the jukebox device has the structure and operation described in U.S. patent No.6308204 referenced above. Thus, the jukebox devices 16 each preferably include one or more microprocessors, such as a main CPU and audio DSP, a memory, such as a hard drive, that stores songs and/or other content, a display that displays visual items, an audio device 20 that provides audio, a communication system that enables the jukebox to communicate with the central server 12 via the communication network 14, and operating software that controls the operation of the jukebox, the operating software preferably including a multitasking operating system. The operating software is also preferably updatable through communication with the central server 12 as described in the above-referenced U.S. patent No. 6308204. The jukebox 16 also includes one or more payment devices, such as coin, bill and/or credit card input devices, to facilitate customer payment for use of the jukebox device. The screen 18 is preferably a touch screen that enables a user to input selections by touching the screen.

Each jukebox device has a local server 22 that is accessible by the jukebox device. The local servers are each connected to the jukebox devices using an ethernet or other type of local connection. The local servers 22 each preferably include a mirror copy of a master library of music recordings maintained by the central server 12. The local server 22 may be loaded with the master library by an entity that owns and/or controls the jukebox network prior to shipping the local server and jukebox device to the jukebox distributor or operator. Of course, over time, the local server no longer corresponds exactly to the central server, since it is preferable to continually update the central server with additional or new songs. Thus, the local servers 22 are also preferably updated periodically to maintain correspondence with the libraries on the central server 12. Such updating may be accomplished by the central server 12 through communication with the jukebox device connected to the local server 22 using, for example, a dial-up or broadband modem. Alternatively, such updates may be done in person using an update tool that may be connected directly to the jukebox or local server by a promoter or other person to update the content of the local server. Such portable tools include removable storage media, such as hard drives, that can be returned to and reused by the jukebox system owner for future updates. The tool itself may be maintained by the operator or other person responsible for maintaining the particular jukebox for use when updated removable storage media is received from the owner of the jukebox system.

For security reasons, the local server 22 preferably does not include all of the digital data that makes up any one of the songs stored on the local server 22. In addition, the portion of the song on the local server is encrypted. The jukebox device 16 contains the missing portions of each song on the local server, thereby enabling the jukebox to combine to obtain a complete song based on the contents of the memory on the local server and the jukebox device. To decrypt the song, the missing data located on the jukebox is needed. For example, a single chunk (or other small portion) of data for each song is not present on the local server but rather on the jukebox device, encryption may be based on the missing chunk data, and may occur on a chunk-by-chunk basis. Thus, any data block cannot be decrypted without obtaining and/or decrypting the previous block of data. This feature provides significant security and prevents or deters theft or other types of unauthorized use or copying of songs on the local server. Thus, in this embodiment, each local server must be explicitly assigned to a particular jukebox device in order to be able to properly perform the above-described decryption.

According to a preferred exemplary embodiment, the local servers are also individually registered with and identified by the central server 12, respectively, so that the central server can individually manage and monitor each local server. The same is true for the jukebox device, i.e., the jukebox device is also preferably registered with the central server so that it can be individually monitored and managed by the central server. As can be appreciated from the above description, by making its content accessible to the jukebox device in order to provide other services (e.g., providing additional songs) that are not present on the jukebox device itself, the local server becomes a new and advantageous part of the jukebox device. As described below, the song library and/or storage capacity of the central server itself may be advantageously used to provide services to other jukeboxes, such as fee-based residential and commercial jukeboxes and/or other fee-based devices. One preferred use of the local server is to provide instant song download functionality to jukebox devices, as will be described in detail below with reference to the exemplary screen shots of FIGS. 3-6.

FIG. 3 shows an exemplary screenshot of a music selection screen 30 displayed on a touch screen of the jukebox device. As shown in FIG. 3, the selection screen (which is preferably an initial selection screen displayed to the customer) includes a graphical representation 32 of the individual album art for the songs stored in the memory of the jukebox device. Album art is displayed alphabetically and a virtual slider bar 33 can be used to scroll through existing albums. Up and down direction keys (34 and 35) are additionally provided to step through existing albums. A "Now Playing" button 36 is additionally provided to display information on the jukebox related to the song currently Playing, if any. A "Top Ten" button 38 is additionally provided to display a list of the 10 most popular songs on the jukebox. A "Tune Central" (TM of touch units Music Corporation) button 39 is also provided, the function of which will now be described in detail with reference to FIG. 4.

If the user does not see an album of interest in the display of album art or wishes to search for available songs that are not present on the jukebox device for any reason, the user may select the "Tune Central" button 39. When the "Tune Central" button is pressed, the display on the jukebox changes from the FIG. 3 screen to the FIG. 4 screen. The exemplary screenshot of FIG. 4 represents a search screen 40, the search screen 40 enabling a search on the local server 22 connected to the jukebox device. Screen 40 provides a virtual keyboard 42 for entering a search request. Based on the associated buttons 47, a search may be made by album, artist, song, genre, or theme (i.e., a sorted list of songs that helps the user find a particular song, preferably based on popularity). Once a Search is entered, the user touches the "Search" button 44, initiating a Search of the content of the local server. With the Clear button 46, the input from the virtual keyboard can be cleared.

Similar to genre and theme searches, a user may search for songs using a personal music assistant, an exemplary process of which is shown in FIG. 4A. Preferably, after pressing the personal Assistant button (step 402), if the user is not already identified, the jukebox may query certain information to identify the user (step 404). Such information may include, for example, age (or date of birth), preferred style, background, place of birth, or other information that may be used to generate a user's profile. The jukebox then preferably compares the profile information with selections made by other users having similar profiles from the jukebox, the particular establishment, or the national database (step 406), and recommends the song (step 408). For example, The jukebox may recommend The song "The Doors" to a male user from california who is born in 1960. The user then selects a song from the list or initiates a new search (step 410).

Further, instead of entering an identifier, as shown in FIG. 4B, the personal music assistant may identify the user in other ways (step 422), such as after the on-demand machine reads a credit card or a pre-programmed venue-specific identification card. Preferably, the personal music assistant maintains a list of selections made by the user. The list of user selections is stored on the local jukebox terminal, on the central jukebox server at the location, on a remote server, or on an identification card. After the personal music assistant identifies the user, it may then recommend songs based on the songs of the artist enjoyed by the particular user (step 426), the songs that the user frequently plays (step 428), the songs that the user has not listened to recently (step 430), and so on.

In addition, a personal music assistant that identifies a preferred customer or a customer with a large amount of credit may make jukebox variants (morphs) more enjoyable to that particular user. The credit may be purchased by the user; or awarded to the user as a prize, for example, due to the purchase of a beverage or memento at a commercial establishment, or due to being a frequent guest. Thus, the personal music assistant may make selecting songs a more interesting, dynamic, and responsive process, while eliminating the direct pressure on the user to know which songs to select.

When the search is started from the screen 40, the screen is changed to the screen shown in fig. 5 to display the result of the search. As shown in fig. 5, the results of the search are enumerated. More specifically, in this example, a list of songs that satisfy the search request is listed. If the search is album based, the listing may also be album based. The user may scroll through the search results using slider 53. A display 55 of the number of current credits and a display 56 of the number of credits required to download a song from the local server to the jukebox device are also displayed to the user. By touching the "Back" button 57, the user can return to the previous screen. If the user selects a song from the search list and then touches the "Get It Now" button 54, the jukebox immediately downloads the selected song from the local server to the jukebox for playing on the jukebox. The downloaded song may be queued up for play on the jukebox along with any other selected but unplayed songs (if any). In this example, the download would cost 5 credits, rather than 1 credit as is done conventionally from the memory of the jukebox itself. Once the downloaded song is played, it is preferably deleted from the jukebox device (along with any graphical data downloaded from the local server as well as the downloaded song, such as album art graphics). Thus, by using the "Tune Central" button, the user has the option of temporarily obtaining any song from the master library of recordings on the jukebox without having to contact the Central server 12. As a result, the jukebox provides a more enjoyable experience to the user while also increasing the revenue generated thereby.

Additionally providing the user with an interesting experience is the ability of the central server to recognize "hot hits" preferably in real time. Preferably, new songs may be made available in the master catalog-i.e., they need not be available on a local server or extended media storage. Subsequently, songs played frequently in a specified area (e.g., from a single location or group of locations to a state or country to a global connection) may be considered popular. These songs, or "hot hits," are preferably downloadable by, or transmittable to, the respective jukeboxes. Each jukebox preferably maintains a list of "hot hits" in real-time, allowing users to search for the most popular songs at any given time. On the other hand, the jukebox may maintain a list of "hot hits" without downloading the popular songs, thereby saving download time and resources. Thus, the jukebox may provide an enjoyable experience to the user due to the ease of accessing the most popular songs.

FIG. 5A shows an exemplary process for saving "hot hits" on a jukebox with a broadband connection. It should be noted that the same process applies to systems with different types of connections, although downloading songs over slower connections may require more time and resources. In step 502, songs from the master catalog are received by a central server of the venue. Of course, it should be noted that songs may be saved to the storage medium of the local jukebox. In step 504, the user using the jukebox terminal may select the "HotList" button. After displaying "Hot List" (step 506), the user may select a particular song or begin a new search (step 508).

Fig. 6 shows another illustrative screenshot of a song selection screen 60 that is displayed when the user touches the album art graphic from the screen of fig. 3. Thus, the screen represents an alternative (or typical) method of selecting songs, where songs are selected directly from a subset of songs that are available directly from the storage device of the jukebox itself (rather than the local server). In this example, the great Hits of Joe Cocker is selected from the screen of FIG. 3. As shown in FIG. 6, the resulting screen display 60 displays a selected album graphic 61 and a list of songs 62 that are present on the jukebox for that album. The jukebox may or may not include all of the songs for a particular album. The available songs can be scrolled through, if desired, by using scroll bars 63a and 63 b. Through the "Play" button 65 the user has the option of selecting a song from the list to be played on the jukebox. A "Play Now" button 66 is also provided to enable the user to select a priority Play of a song to give the song a higher priority than the song selected using the "Play" button 65. This priority feature preferably requires more play credits than normal play. The display 67 represents the number of credits available to the user. Button 64 displays other albums by the same artist, shown at 61, so that the user can easily search through the albums by a particular artist for the desired song.

Also shown in FIG. 6 is a "Tune Central" button 68, enabling the user to search for songs by that same artist on the local server, as described in connection with FIG. 4. In other words, button 68 takes the user to the search screen 40 of FIG. 4 in order to search the local server. The user may then proceed to search the local server and select a song from the local server (if desired), as described above in connection with fig. 4 and 5. Thus, as described above, the user can access the local server at each screen in a convenient and efficient manner, depending on the user's desires when interacting with the jukebox screen.

As can be seen from fig. 3-6, the user is provided with the option of playing songs that are present on the jukebox device itself, or alternatively, selecting songs from a local server for download and playing in an efficient and reliable manner, thereby significantly improving the operation of the jukebox system, particularly those jukebox systems that are not capable of quickly, easily or reliably receiving a download of requested music from a central server. Note that the screen shots of FIGS. 3-6 are merely illustrative and any suitable screen configuration may be used to provide the functionality described herein. In addition, the jukebox operator is provided with the ability to set filters by genre or style of music via operator screens (not shown) in order to limit access to end users and avoid playing undesirable music at a particular location.

FIG. 7 shows a block diagram of the electronic components that determine the local server 22 in accordance with an illustrative embodiment. As shown in FIG. 7, the local server 22 includes a CPU 72 (e.g., AMD Elan100MHz), a flash memory (e.g., 8MB) containing the BIOS and OS, a pair of master/slave hard drives (82, 84 and 86, 88, respectively), a pair of IDE controllers 78 and 80 for the hard drive pair, respectively, a RAM 76 (e.g., 32MB), an Ethernet controller controlling communication with the jukebox device 16, and an appropriate bus interconnecting the various components. Of course, other configurations or arrangements of the local server 22 may be used. A unique identifier may be set in the local server to enable the local server to be uniquely identified and registered by the jukebox and/or the central server. The identifier may be located in the flash memory 74.

As can be appreciated from the above description of the present invention, the addition of a local server significantly enhances the operation of the jukebox device as part of the jukebox system. However, the local server also provides other benefits and features as will now be described.

A collection of local servers 22 may be used as a network of distributed servers that the central server 12 can control through its associated jukebox devices 16 to provide music services to other devices. For example, in addition to providing song services to a particular jukebox connected and assigned, a local server and associated jukebox may be used to deliver requested songs to a dedicated residential or commercial jukebox device (or other suitable jukebox device). Thus, the network of distributed servers can form a support network for implementing residential and commercial jukeboxes of the type that allow users to download songs for reproduction and/or storage at a residential or commercial location for an appropriate fee. Thus, a jukebox system operator can provide and control commercial jukeboxes as well as residential jukeboxes through the jukebox system. In this embodiment, the jukebox device and/or local server is connected to the Internet (or other suitable network) using a broadband modem and is provided with software that can selectively transfer song files to any dedicated residential jukebox device (which may also be connected to the Internet) under the control of the central server. The central server receives the request from the residential jukebox, and by analyzing traffic on the network, provides instructions to the selected jukebox device to download the requested song file (either from its memory or from the local server) to the residential jukebox for a fee or according to the subscription plan of the residential jukebox.

According to another exemplary aspect of the invention, the local server and the jukebox device are used to provide management services to other types of slot or payment triggering devices, such as gaming devices, installed in the same (or proximate) location as the jukebox, under the control of the central server. In other words, the jukebox system is preferably used to update the functionality of and/or manage other downloading devices that exist at the same location. Thus, the jukebox becomes a "central hub" for all downloading devices in a location. In one embodiment, this feature is implemented by networking all the download devices in a single location with the jukebox and local file server. The central server may then download the information to the local server, along with instructions to the jukebox as to what data and/or software to update which devices to apply. The jukebox device and central server may also be used to collect information from other download devices that it is managing and upload that information to the central server for reporting/billing purposes. Thus, the jukebox system owner/operator can act as a third party service provider for other coin-operated equipment companies to manage and/or update their equipment.

The large amount of memory provided by the local server, and the fact that they are located in thousands of locations and can be accessed over a well-controlled network, makes jukebox systems a powerful tool that can be used to implement various functions in the slot industry. An increasing number of coin-operated device manufacturers are producing games that are software updatable through their internal hard drives. These updates are made periodically, but as these devices increase, there is an increasing need for a system that can reliably and efficiently update from a remote location. The jukebox system described herein satisfies this need by enabling all appropriate electronic coin-freed equipment located at the jukebox location to be managed by a central server using the jukebox and local server located at that location. The central server can download software or data updates, store them on the local server, and then send the updates to the predetermined units of equipment in the establishment. Thus, the jukebox system may function as a third party service provider for other companies in the coin operated business, thereby significantly enhancing the functionality of the jukebox system.

As an example, there are currently about 140000Merit slot table devices in the united states, each device enabling users to play games and the like on a pay basis. Many of these devices work with hard disk drives that are upgradeable with new software. The Merit accomplishes this by sending the CD-ROM to the operator who then needs to drive to each site and manually update each machine. However, according to the present invention, all appropriate coin-freed apparatus located at a location are connected (directly or indirectly) to the local jukebox and the local server assigned to it. This enables the central server to receive predetermined software updates for any device, and information identifying what devices are to be upgraded with what software. The upgrade service is preferably fee based and provides an additional revenue stream for the jukebox system. The central server then downloads the software to the local server along with upgrade instructions to further download the upgrade to the appropriate device.

As described above, the local server, under the control of the central server, can cause songs to be downloaded to the commercial jukebox to which it is assigned, or to the residential jukebox. In addition, the local server can be used to manage the in-store networking applications of its slot machines. These various features of the present invention are illustrated in fig. 8.

FIG. 8 shows a block diagram of an overall jukebox system network contemplated by an exemplary embodiment. As described above, the system includes a central server 12 connected to a communications network 14, a series of commercial jukeboxes 16a, 16b and 16c with associated local music file servers 22a, 22b and 22c, a series of residential jukeboxes 100a, 100b and 100c connected to the network through broadband devices 102a, 102b and 102c, and an on-premise network shown on the right-hand side of FIG. 8. The in-store network includes a jukebox device 16d connected to a local file server 22d through a router or network hub 110, a number of additional coin-op devices such as a dart game 104, a golf game 106 and a countertop electronic game 108, and a broadband modem 112 connecting the local network to the communications network 14. With this exemplary configuration as shown in FIG. 8, all of the functions described herein can be implemented by the jukebox system of the present invention.

FIG. 9 shows an overhead view of an exemplary establishment layout for a multi-zone jukebox system. According to an exemplary embodiment, the business person has three areas 121, 123, 125. Each zone is equipped with its own set of speakers 127, 129, 131, which are connected to the jukebox 133. Different music may be played simultaneously in all three zones 121, 123, 125, and all music may be played from a single jukebox 133. Jukebox 133 may be provided with additional hardware to allow for such implementation.

Alternatively, the user may choose to have a certain song played in more than one of the regions 121, 123, 125 at the same time, or at different times. To accomplish either of these functions, the user has to pay additional credits. A preferred embodiment of the multi-zone System can play music in different zones with high quality by using the System disclosed in application serial No.11/023390 (application date 2004, 12/29), "Wireless digital transmission System for Loudspeakers" (which is an application filed 1998, 9/28, part of serial No.09/161584 continues). The entire contents of both applications are hereby incorporated by reference. By using this system, the jukebox can compress and transmit audio data over the AC power line to an addressable location where it can be received, decompressed, converted and played.

It will be appreciated that in other embodiments where it is desirable to transmit data between two or more devices, the wireless digital transmission system may be used for other purposes. For example, the system may be used to configure virtual terminals. In such embodiments, the wireless digital transmission system may be used to transmit information such as whether or not to morph, what songs are appropriate under a particular variation of the jukebox, the area in which the selected song should be played, the maximum volume, etc.

The operator may also restrict what types of music are available in a given area based on the type of activity in that area, the time of day, or any other suitable selection criteria. For example, in FIG. 9, zone three 125 is a restaurant. Restaurant patrons may not wish to hear the same type of music as in area one 121, or area two 123, where area one 121 is a pub and area two 123 is a pool room in fig. 9. The operator recognizes this and limits the types of music that can be played in zone three 125. On the other hand, the operator may limit the volume of music in any given area. For example, patrons of the pool room 123 or restaurant 125 may not want music as loud as desired in the bar room 121. And the restaurant 121 may be kept quieter than the pool room 123. The owner can adjust and control all appropriate settings to provide a more versatile, customer friendly environment in each area according to any appropriate criteria.

FIG. 10 shows an overhead view of an exemplary establishment layout for a multi-zone jukebox system with selection terminals in each zone. According to an exemplary embodiment, the bar has three areas 121, 123, 25. Each zone is equipped with its own set of speakers 127, 129, 131, which set of speakers 127, 129, 131 is connected to the jukebox 133. Different music may be played simultaneously in all three zones 121, 123, 125, and all music may be played from a single jukebox 133. The jukebox 133 may be equipped with additional hardware to allow for such implementation.

In fig. 10, there are also one or more "virtual" terminals 137, 139 located throughout the establishment. An exemplary virtual terminal may use X-server technology. These terminals 137, 13 (which may be stand alone devices or may be provided as part of an interface on a gaming machine or other suitable device having a digital display) allow songs to be selected from the jukebox 133. These terminals 137, 139 may be restricted to only allowing selection of music for playing in the area in which the respective terminal is located, or they may allow selection of music for playing in one or more different areas.

In addition, the graphical interface of the terminals 137, 139 may vary depending on the selections present, the mood of the bar, the mood of the space in which each terminal is located, or any other suitable criteria.

FIG. 11 is a flow chart showing an exemplary implementation of a zone selection process for a multi-zone jukebox system. According to an exemplary embodiment, the jukebox first begins a transaction 141 with the user. The user is instructed to select a song 143 and to select one or more regions 145 where the song is to be played. The jukebox then determines a price 147 based on the number of zones selected. The jukebox accepts payment from the user 149 and queues the song for play 151 in the selected zone or zones. The jukebox then checks to see if the user wants to select another song 153. If the user wants another song, the process returns to the select song step 143 and repeats from this step. If the user is finished selecting, the process ends 155.

FIG. 12 is a flow diagram of an exemplary implementation showing a priority play of a zone selection process for a multi-zone jukebox system. According to an exemplary embodiment, an jukebox system may be provided with one or more priority queues corresponding to one or more zones. If priority play is provided for one or more zones, the jukebox first checks to see if the user wants priority play 161 for the selected song. If priority play is selected, the jukebox provides the user with the option 163 of selecting one or more zones that should be played preferentially. Based on the number of zones selected for priority play, the jukebox determines a price 165 and accepts payment 167 from the user. The jukebox then places the song in the priority play queue for each selected zone 169.

FIG. 13 shows an exemplary implementation of a multi-zone set of priority and non-priority queues with a subset of queues for each zone. According to an exemplary embodiment, each of the N regions 171 may have its own set of queues, including a priority queue 175 and a non-priority queue 173. A list of songs selected to be played is stored in each queue 173, 175. Each song in each queue may have an identifier 171, 179 that identifies the song, and/or the location of the song in the queue, and/or any other suitable factors.

FIG. 14 is a flowchart showing an exemplary distribution and initialization scheme for a jukebox with morph capabilities. According to an exemplary embodiment, the contents of the factory drive are defined at the time of manufacture 181. This same drive (extended media storage) may be shipped 183 with all jukeboxes and may contain only a subset of the total songs present on the central server. Once the jukebox containing the drive reaches its destination, the operator may select a subset of the songs on the drive as the base playable list 185. The selection may be made based on the type of establishment, the type of music that is generally liked by a customer of the establishment, or any other suitable criteria. The operator also allows the central server to recommend a basic playable list. The drive also allows songs 187 not on the basic list to be selected for an additional fee. However, the list of "prepared" songs may not include all songs, as the operator may wish to restrict access to those songs that do not meet the mood of the commercial establishment. For example, a country bar owner may never want to allow selection of a bounty or rap song on the jukebox.

Once the songs on the drive are properly categorized, the jukebox begins operation 189. As long as a new basic playable list is not needed 191, the jukebox continues to operate 189 with the currently selected basic playable list. If a new basic playable list is needed 191, the jukebox becomes a "new" jukebox, selects a different subset of playable songs as the basic playable list 185, and changes additional features as dictated by the variation.

FIG. 15 is a flowchart showing an exemplary implementation of a jukebox morph initiation process based on a triggering event. According to an exemplary embodiment, a user may define an event, such as a subject night or a time of day, as a trigger event 201 that triggers a jukebox morph. The jukebox then operates as usual 203, periodically checking to see if a triggering event has occurred 205. If no trigger event has occurred, then the jukebox simply continues to operate 203, but if a trigger event has occurred, the jukebox is morphed into a "new" jukebox. The trigger events may be one time events, or they may be scheduled to occur weekly, daily, monthly, or according to any other suitable criteria. It should be noted that in a multi-zone configuration, different zones may be deformed while other zones are unchanged. This feature of the exemplary embodiments allows a designated area or areas to be dedicated to a certain type of music, while other areas may vary depending on any of a variety of factors, such as the time of day, the desire of the owner to change the music, or the user's request.

FIG. 16 is a flowchart showing an exemplary embodiment of a jukebox morphing process. According to an exemplary embodiment, when the jukebox begins to morph 211, it selects a new subset of songs to be the basic playable list 213. The jukebox then allows for an increased fee to be paid for the selection of some or all of the remaining songs on the jukebox 215. Some of the remaining songs may be restricted based on what triggers the deformation. Other features of the jukebox may also change 217, for example, the user interface may change, and different advertisements may be displayed that correspond to the predicted tastes of the demographic for which the jukebox has been changed. Other suitable variations may also be made. In one example of a preferred embodiment, the club owner has sung at wednesday starting at 9 pm and ending at 4 am. At 9 pm on wednesday, the jukebox morphs into a rap jukebox with a basic selection of appropriate music. According to this variant, the jukebox blocks all access to music genres such as country music, classical rock, jazz, bruise and nostalgic music, and the jukebox limits the available choices of additional hard rock songs to "rap-like" hard rock songs. The graphics on the jukebox are converted into well-defined city graphics, the advertisement changes accordingly, and products such as apparel, beverages, and merchandise that appeal to the rap group are displayed. At 4 am, the jukebox changes back to the club's "standard" jukebox, or to any other suitable jukebox. Alternatively, the jukebox may remain set to talk mode until the next triggering event occurs. Additionally, it should be noted that in a multi-zone configuration, different zones may be deformed while other zones are unchanged. In the illustrative, non-limiting embodiment described above, the system may morph into a solo mode in one area for the night, and still play the "standard" music for the club in another area.

FIG. 17 shows the relationship between a jukebox with extended media storage and a central server. According to an exemplary embodiment, the central server 221 contains a master library of songs, such master library containing all songs that are currently available for download and all songs that are currently installed on the jukebox hard drive. The central server may communicate 222 with a remote jukebox 225 that contains a local hard drive 223. The hard drive 223 on the jukebox may have several partitions including available space 227 for downloading, space 228 occupied by pre-downloaded songs, and space 229 for software and operating systems. Additional suitable sections may be added, such as sections containing different images for altering the GUI. The jukeboxes 225 may communicate with the central server 221 to download songs, upload usage information, update software, and perform any other suitable function.

FIG. 18 is a flow chart showing an exemplary process for a song selection process when a song is not on the "standard" available playable song list. According to an exemplary embodiment, the user first selects song 231. The jukebox checks to see if the song exists as a "non-standard" selection on the local hard drive 233. If the song is present on the local hard drive, the jukebox charges the customer the set price 235 to obtain and play the non-standard song and plays the song 237 (or adds it to the playlist as appropriate).

If the song does not exist on the local hard drive, the jukebox checks to see if there is a high-speed connection to the central server 239. If there is no high speed connection, the jukebox notifies the user that the song is temporarily unavailable 241 and orders the song for download 243. The jukebox may or may not charge an additional fee for ordering the song. However, if there is a high speed connection available to the central server, the jukebox immediately orders the song and immediately downloads the song using the high speed connection, queuing it for play 245. The jukebox then charges the customer a non-standard selection of costs 247.

FIG. 19 is a flow diagram showing an exemplary process for a priority play queue with bid-based prioritization capabilities. According to an exemplary embodiment, the user first indicates that he wants to play 251 preferentially. The jukebox then displays the current status of the priority play queue 253. The display may include information such as how many songs are in the queue, what the head is, how many each song has bid, which songs are "locked", and any other suitable information about the priority queue. The jukebox then allows the user to select how much additional the user would like to pay to place his songs in a particular location in the prioritized list, and accepts payment 255 for the selected amount. After accepting the payment 255, the jukebox places the song in a prioritized list at a location corresponding to the premium received from the user.

In another exemplary aspect of the exemplary embodiments, on the other hand, the user may bid on the right to play a certain song before other songs previously selected for priority play are played. In a preferred embodiment, the user is shown the highest price paid for priority play, and the user may pay a higher fee than this price to obtain the highest priority available.

Another exemplary aspect of the exemplary embodiments does not allow the user to be shown how much other people paid for priority. However, the user may pay the amount he wants to spend in order to obtain a priority order, and then receive a priority order based on the amount paid.

However, according to another exemplary aspect of the exemplary embodiments, the user may pay money he wants to spend in order to obtain the priority order according to the previous exemplary aspect, and then display the obtained priority position thereto according to the amount of payment. If the location is not satisfactory to the user, the user may pay a premium to advance the prioritization of songs and display the new prioritization to the user based on the premium paid. The user may repeat the process until the desired priority is obtained. The user may also pay additional fees to make it more difficult for other users to pre-fetch the selected priority location on the priority list in bidding situations. Any other suitable method of increasing the payment amount and thus increasing the priority may also be implemented.

According to another exemplary aspect of the exemplary embodiments providing a "lock" function, a user may "lock" a prioritization if a preselected amount is paid. For example, if the user pays 15 credits to obtain a 3 rd priority order and wishes to guarantee a third order, the user may pay 4 more credits to "lock" the order. Since locking the sequence also requires a "lock" that is higher than all sequences of the user, the user is required to pay a certain amount in order to "lock" all songs above the user's selection. In one such scenario, the user may choose to pay the price reported as "locked out," or pay a credit of the same amount or a change in amount in an attempt to prevent future over-pricing, or to advance the user's songs further in the priority list.

It should be noted that while the above embodiments describe a system for distributing media to non-removable jukeboxes, alternative embodiments utilizing similar systems for distributing media to portable jukebox devices are contemplated by and within the scope and spirit of the present invention. The portable jukebox may be, for example, a PDA, a cell phone, or any other removable device capable of receiving and playing music. Further, the media may be distributed to the portable jukeboxes using the methods described above (e.g., via a broadband connection, wireless connection, etc.), or any other suitable method that is more appropriate for the particular portable device, such as using Bluetooth technology. In addition, the above-described jukeboxes are typically used for commercial purposes. However, jukeboxes for other purposes, such as playing residential media, are also contemplated and within the scope and spirit of the present invention.

While the preferred aspects of the present invention have been illustrated and described herein, it will be apparent to those skilled in the art that various changes and/or modifications can be made. Accordingly, the detailed description is to be construed as exemplary only and not limiting of the invention, except as provided by the appended claims.

Claims

1. An apparatus for morphing a jukebox, wherein the jukebox further comprises a graphical user interface displaying at least one of: a first list of media instances that can be selected for output by a user at a standard fee, a second list of media instances that is different from the first list, one or more advertisements, or one or more graphics of the list or the one or more advertisements that can be selected for output by the user at an elevated fee that is greater than the standard fee, the apparatus comprising:

means for defining, by a jukebox operator, an event that triggers a deformation of the jukebox;

means for operating the jukebox;

means for checking to see if an operator-defined event has occurred or has occurred that triggers a deformation of the jukebox; and

means for switching between display of the first list of media instances and the second list of media instances in the graphical user interface and changing presentation of the graphical user interface to present in a predetermined visually distinct manner in response to an operator-defined event occurring or having occurred that triggers the modification of the jukebox.

2. The apparatus of claim 1, wherein the means for altering the presentation of the graphical user interface to present in a predetermined visually distinct manner further comprises means for altering the presentation to match a graphic matching a criteria, wherein the criteria is set based on an operator-defined event defined to trigger a modification of the jukebox.

3. The apparatus of claim 1, wherein the means for altering the presentation of the user graphical interface to be presented in a predetermined visually distinct manner further comprises:

means for displaying a new first list of media instances selectable by a user, wherein the content of the new first list is determined according to first criteria, wherein the first criteria are set according to operator-defined events defined to trigger a variation of jukeboxes; and

means for displaying a new second list of media instances that is different from the new first list, selectable by the user, wherein the content of the new second list is determined according to second criteria, wherein the second criteria is set according to an operator-defined event defined to trigger a modification of the jukebox, wherein the new second list does not contain all remaining media instances in the set of media instances that are not contained in the new first list.

4. The apparatus of claim 1, wherein the graphical user interface allows a user to search for media using a personal music assistant, the personal music assistant comprising:

a data input mechanism that collects profile information about the user;

a comparator for comparing the input profile information with other profiles and recommending media to the user;

a display to output a list of recommended songs; and

a selector that specifies which media instances should be played.

5. The apparatus of claim 4 wherein the data entry mechanism of the personal music assistant comprises a keyboard.

6. The apparatus of claim 4 wherein the data entry mechanism of the personal music assistant comprises a credit card.

7. The apparatus of claim 4 wherein the data entry mechanism of the personal music assistant comprises a pre-programmed media card or an identification pen.

8. The apparatus of claim 1, wherein the graphical user interface allows a user to search for media from a list of popular media compiled from media selection habits of jukeboxes within a predetermined geographic area.

9. The apparatus of claim 1, wherein the operator-defined trigger event comprises a specified date, time or day of the week.

10. The apparatus of claim 1, wherein the operator-defined trigger event comprises an identification of a preferred user.

11. The apparatus of claim 1, further comprising means for selecting an instance of media, said means for selecting an instance of media comprising:

means for inputting identification data to create a user profile;

means for comparing the entered profile information with other profiles;

means for recommending a narrowed media list to the user; and

means for specifying which media instances should be played.

12. The apparatus of claim 9, wherein the user is identified by reading a credit card.

13. The apparatus of claim 9, wherein the user is identified by receiving a signal from a pre-programmed card or identification pen from a receiver connected to the jukebox.

14. The apparatus of claim 1, wherein selecting an instance of media further comprises selecting media from a list of popular media compiled from media selection habits of jukeboxes within a predetermined geographic area.

15. A method of morphing a jukebox, wherein the jukebox further comprises a graphical user interface displaying at least one of: a first list of media instances that can be selected for output by a user at a standard fee, a second list of media instances that is different from the first list, one or more advertisements, or one or more graphics of the list or the one or more advertisements that can be selected for output by the user at an elevated fee that is greater than the standard fee, the method comprising the steps of:

defining, by a jukebox operator, an event that triggers a deformation of the jukebox;

operating the jukebox;

checking to see if an operator-defined event that triggers a deformation of the jukebox occurred or has occurred; and

in response to an operator-defined event occurring or having occurred that triggers a variation of the jukebox, switching between display of the first list of media instances and the second list of media instances in the graphical user interface and changing presentation of the user graphical interface to present in a predetermined visually different manner.

16. The method of claim 15, wherein changing the presentation of the graphical user interface to present in a predetermined visually distinct manner further comprises changing to a graphic that matches a criteria, wherein the criteria is set based on an operator-defined event defined to trigger a modification of the jukebox.

17. The method of claim 15, wherein altering the presentation of the user graphical interface to present in a predetermined visually distinct manner further comprises:

displaying a new first list of media instances selectable by a user, wherein the content of the new first list is determined according to first criteria, wherein the first criteria are set according to operator-defined events defined to trigger a variation of jukeboxes; and

displaying a new second list of media instances that is different from the new first list, selectable by the user, wherein the content of the new second list is determined according to second criteria, wherein the second criteria is set according to operator-defined events defined to trigger a morphing of jukeboxes, wherein the new second list does not contain all remaining media instances in the set of media instances that are not included in the new first list.

18. The method of claim 15, wherein the graphical user interface allows a user to search for media using a personal music assistant, the personal music assistant comprising:

a data input mechanism that collects profile information about the user;

a display to output a list of recommended songs; and

a selector that specifies which media instances should be played.

19. The method of claim 18 wherein the data entry mechanism of the personal music assistant comprises a keyboard.

20. The method of claim 18, wherein the data entry mechanism of the personal music assistant comprises a credit card.

21. The method of claim 18, wherein the data entry mechanism of the personal music assistant comprises a pre-programmed media card or an identification pen.

22. The method of claim 15, wherein the graphical user interface allows the user to search for media from a list of popular media compiled according to media selection habits of jukeboxes within a predetermined geographic area.

23. The method of claim 15, wherein the operator-defined trigger event comprises a specified date, time or day of the week.

24. The method of claim 15, wherein the operator-defined trigger event comprises an identification of a preferred user.

25. The method of claim 15, further comprising the step of selecting an instance of media, said step of selecting an instance of media comprising:

inputting identification data to create a profile of the user;

comparing the input profile information with other profiles;

recommending a reduced media list to the user; and

specifying which media instances should be played.

26. The method of claim 23, wherein the user is identified by reading a credit card.

27. The method of claim 23, wherein the user is identified by receiving a signal from a preprogrammed card or identification pen from a receiver connected to the jukebox.

28. The method of claim 15, further comprising the step of selecting an instance of media, said step of selecting an instance of media comprising selecting media from a list of popular media compiled from media selection habits of jukeboxes within a predetermined geographic area.