Digital downloading jukebox system with central and local music servers

Description

FIELD OF THE INVENTION

The instant invention relates to, for example, jukebox systems and, more particularly, to digital downloading jukebox systems of the type which typically include a central server and remote jukebox devices that communicate with the central server for royalty accounting and/or content updates. Exemplary embodiments of the instant invention improve such systems by providing a local server for each jukebox device in the jukebox system network. The local server provides a second and more expansive source of content (i.e., audio and/or visual data) that can be selected by a user of the jukebox device for reproduction on the jukebox device. The local servers preferably provide a mirror of the central server, thereby enabling the entire library of audio and/or visual data to be conveniently available to each jukebox device without the need to download requested content, that is not available on the mass storage device of the jukebox device itself, from the central server. The collective group of local servers may also act as a network of distributed content servers that can be controlled by the central server through each jukebox device to provide services to other devices, such as, for example, non-portable jukebox devices. In addition, the jukebox device and local server can, under control of the central server, operate as a “central hub” or management device for various downloadable fee-based devices present in a location with the jukebox device.

BACKGROUND AND SUMMARY OF THE INVENTION

Jukeboxes have been around for decades and provide users with the ability to select desired music for reproduction in a convenient and advantageous manner. Jukeboxes have conventionally been provided in commercial establishments, such as restaurants and bars, in order to provide desired music on demand for patrons thereof for a fee. Over the last several years, a new generation of jukebox devices have become available that provide significant improvements in the operation thereof for all parties involved. More specifically, the conventional standalone phonorecord and CD jukeboxes are being replaced by digital downloading jukeboxes that are controlled by and communicate with a central server. An example of this new generation jukebox system is shown in U.S. Pat. No. 6,308,204, the disclosure of which is incorporated by reference herein in its entirety. A leading provider of this new generation of jukebox systems is TouchTunes Music Corporation.

FIG. 1 shows an overview of an exemplary embodiment of a digital downloading 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 that contains a master library of audio content (typically music), as well as or alternatively audiovisual content (typically music and associated video or graphics), that can be downloaded therefrom. The jukebox system also includes a series of remote jukebox devices 16, 16a-16f. Each of these jukebox devices are generally located in a bar, restaurant, club or other desired location, and are operable to play music in response to receiving a payment from a user, such as coins, bills, credit/debit card, etc., and having one or more songs selected by the user for play. In an alternative embodiment, a music service is paid for on a subscription basis by the location, and the selected music is free for the end-user. The jukebox device 16 typically includes a screen 18 that presents information to the user and allows the user to select songs therefrom, as well as an audio system 20 that plays the selected songs. The screen 18 may also be used for displaying song-related video or graphics. The screen 18 may also be used to display advertisements for the jukebox itself in order to attract customers thereto, to display other types of advertisements and/or to display any other desired information.

The jukebox devices 16 (sometimes referred to as simply “jukeboxes” herein) are operable to communicate with the central server 12 through a communications network 14, such as, for example, the Internet. The jukeboxes 16 periodically communicate with the server 12 in order to provide information to the server 12 regarding the specific songs that have been played on the jukebox. The central server then uses this information in order to determine the appropriate royalties and/or other payments that are owed for songs played on each jukebox. Thus, one significant advantage of this new generation of jukeboxes is that the sound reproduction and/or other applicable music rights can be adhered to in a more accurate and reliable manner, thereby assuring the proper royalties are paid to the artists or music owners. The central server 12 can also provide new songs to the jukebox 16 in order to assure that the appropriate or most popular songs are maintained on the jukebox based on the specific customers at that location. Thus, the songs available on each jukebox can be customized through communication with the central server in order to provide the songs and/or types of music that customers generally request at each jukebox location. As described in the above-referenced U.S. Pat. No. 6,308,204, the central server can also advantageously be used to update the operating software on the jukeboxes in order to, for example, change the operation of the jukebox, such as to provide new or improved features. Thus, another significant advantage of this new generation of jukeboxes is that the songs (or other audio and/or visual content), and the operation of the jukebox itself can be remotely changed as desired without the need to have someone (such as a routeman) personally service the jukebox. Instead, such updates can be done using the central server 12.

As indicated above, the jukebox devices 16 each include a mass storage device, such as a hard drive, which stores the songs and associated video/graphics data (if any), as well as any other desired graphical information for reproduction on the jukebox. The mass storage device of the jukebox typically has limited storage capacity relative to the storage device of the central server 12. As a result, only a fraction of the songs stored on the central server are actually stored on the mass storage device of the jukebox at any one time. There may be other reasons as well, such as for security of the data or limited room in the jukebox itself, for having limited storage capacity on the jukebox and/or limiting the number of songs stored thereon. For example, physical space may be limited on wall-mount jukeboxes or the like, which are designed to be small in size as compared to free standing models. As explained above, the songs on the jukebox can be changed through communication with the central server, but any one jukebox only stores a subset of the complete library of songs maintained by the central server at any one time.

In order to maximize the revenue that a jukebox generates it is important to make the most desired songs available on the jukebox over time. If customers cannot find songs they like on the jukebox, usage of the jukebox (and the revenue generated thereby) will dramatically decrease. On the other hand, it is impossible to predict in advance exactly what a customer at any particular location will desire to play on the jukebox. In fact, there are likely many instances where a customer would have selected a song that exists on the central server but is not currently present on the jukebox. As a result, the jukebox may not be enjoyed and used to its fullest extent. In order to address this problem and increase revenue, jukebox systems have in the past provided a feature which enables the user to search for songs on the central server from the jukebox and request an immediate download of a desired song from the central server to the jukebox for an additional fee. This feature enables the user to play any song in the master library of songs maintained by the central server using the jukebox, regardless of whether or not the specific song is presently stored in the mass storage of the jukebox itself. Thus, the user can first look for desired songs on the local storage of the jukebox and then, if desired, search further on the central server for desired songs. The jukebox device typically charges an additional fee (such as five credits instead on one credit) for an immediate download and play of a song from the central server as opposed to a standard play directly from the jukebox's local storage.

One problem, however, with the immediate downloading feature is that it is desirable to have an immediate and high speed connection with the central server to implement. In addition, the central server and network must be prepared to and capable of handling such requests in a reliable and efficient manner for the feature to properly operate. These requirements cannot always be met and, as a result, implementation of this feature has been limited. For example, many locations that have jukeboxes do not have high speed connections (such as DSL) and instead use dial-up modem connections. Jukeboxes which rely on dial-up connections generally are only designed to communicate with the server periodically and do not allow the user to immediately download a song. They have, however, enabled a user to vote for a song to be downloaded at a later time when the dial-up connection is made. This, of course, is not as satisfying to the user as being able to immediately download a song. Other problems can arise in connection with this download feature if the network or server is not currently available for the download, due to traffic, malfunctions or the like.

For the reasons explained above, there is a need for a jukebox system that overcomes these and other disadvantages. The instant invention is designed to address these and other problems and to provide even further functionality for such jukebox systems.

In accordance with an exemplary aspect of the instant invention, a local content server is provided for each jukebox in the jukebox system. The local server preferably mirrors the master library of songs (and/or other content) on the central server. The local server is installed in close proximity to the jukebox to which it is assigned and preferably in the same restaurant or bar where the jukebox is installed. The local server may even be installed within the housing of the jukebox device itself if space permits. Preferably, however, the local server is simply installed in a convenient location and connected to the jukebox using a high speed connection, such as, for example, Ethernet or the like. In accordance with an exemplary embodiment, the local server is used to implement the immediate downloading feature described above without the need for a high-speed connection with the central server. In other words, the user can first search the local storage on the jukebox for desired songs and then, if desired, search further on the local server for desired songs. If the desired song is found on the local storage it is played from the local storage for a normal fee. On the other hand, if the song is only found on the local server, the song can be immediately downloaded, at the option of the user, from the local server to the jukebox for playing for a fee that is preferably higher than the normal fee. As a result, the immediate downloading feature can be reliably implemented regardless of the connection type to the central server and regardless of the availability of the network or the central server. Moreover, because the download comes from the local server rather than the central server is transparent to the user.

Alternatively, in another exemplary aspect, a jukebox is provided with locally-attached expanded storage media. While not as large as the server drive in the above preferred embodiment, the storage media may, in one embodiment, hold approximately 20% of the songs available on the central server. Studies have shown that the song group comprising approximately the top 20% of the most requested songs will satisfy the play requests of approximately 80% of the end users. In another exemplary embodiment, this media may hold approximately 30% of the songs available on the central server, which correlates to the requests of approximately 90% of the end users. The amount of song data stored on the media can be any suitable amount to accomplish the desired functionality. For example, if new data indicates that only 10% of the songs need to be stored, then that would be an appropriate amount to store.

In accordance with another exemplary aspect of the invention, the local server or storage media is periodically updated with data (e.g., songs) to correspond with the contents of the master library of data (e.g., songs). The updating may occur remotely using dial-up or broadband connections, or it may be updated manually by, for example, an operator using an update tool provided by the entity controlling the jukebox system which can be directly connect to the jukebox or local server for the purpose of updating the local server or storage media so that the contents correspond to the master library on the central server, or so that the contents at least correspond to the current desired percentage of the most selected songs.

In accordance with another exemplary embodiment, the server includes an array of hard drives with associated IDE controller(s), a microprocessor, a flash memory containing the BIOS and the operating system, RAM and an Ethernet controller for communication with the jukebox. Each local server is preferably assigned or registered to the specific jukebox to which it is connected. For security purposes, the data on the local server preferably does not comprise any complete songs. Instead, the jukebox device includes missing data from each song on the local server, so that the jukebox can construct the entire song from the contents of its storage device and the contents of the local server. The data on the local server is also preferably encrypted using the missing data (e.g., one block), thereby preventing songs from being copied or played from the local server by any device other than the jukebox to which it is assigned.

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

In accordance with a further exemplary aspect of the invention, the local server and jukebox device are used, under control of the central server, to provide management services for other types of coin operated or payment triggered equipment, such as gaming devices, installed in the same location as the jukebox. In other words, the jukebox system is preferably used to update the functionality of and/or manage other downloading devices present in the same location. As a result, the jukebox functions as a “central hub” for all downloading equipment in a location. This feature is achieved, in one embodiment, by networking all of the downloading devices in a single location together with the jukebox and local file server. The central server can then download information to the local server together with instructions to the jukebox as to which devices should be updated with what data and/or software. The jukebox device and local server can also be used to collect information from the other downloading devices to which it is managing and upload that information to the central server for reporting/accounting purposes. Thus, the owner/operator of the jukebox system can act as a third party service provider to other coin-op companies for the purpose of managing and/or updating their equipment, such as electronic gaming equipment.

In accordance with an additional exemplary aspect of the illustrative embodiments, the jukebox has, or is given, the processing power to play multiple songs simultaneously through different outputs to different zones. In a preferred embodiment, an establishment containing three zones: a restaurant, a bar, and a pool room, can have a number of selections, up to the number of zones or speaker outputs, playing at the same time. This allows for increased revenue in the jukebox system, as patrons of any one zone can listen to a selected song at the same time as patrons of another zone listen to a different song.

In accordance with a further exemplary aspect of the illustrative embodiments, the user may select a song to play in more than one zone of the establishment. This play may be simultaneous in the multiple zones, or may occur at different times. This allows the jukebox operator to capture additional revenue for playing the same song more than once, and potentially an even greater amount of revenue for guaranteeing that the song is played simultaneously in multiple zones of the establishment.

In accordance with another exemplary aspect of the illustrative embodiments, each zone is provided with a terminal which allows patrons in that zone to select songs for play on the jukebox. In a preferred embodiment, the terminal is a “dummy” terminal, provided with a graphical user interface (GUI) for song selection, however a gaming terminal or any other suitable device capable of providing a GUI may be used.

In accordance with an additional exemplary aspect of the illustrative embodiments, the operator can restrict the selections that can be played in a given zone. For example, in a restaurant zone of a multi-zone establishment, the operator may desire to restrict music to that suitable for a dining atmosphere. The operator can also restrict or allow other aspects of selection play in each zone, such as volume, priority play availability, etc.

In accordance with a further exemplary aspect of the illustrative embodiments, the jukebox may be provided with an algorithm or other method to selectively select background music, based on the zone, the time, or any other suitable criteria.

In accordance with another exemplary aspect of the illustrative embodiments, the different zones may be provided with independent priority and non-priority play queues.

In accordance with an additional exemplary aspect of the illustrative embodiments, jukeboxes with expanded song storage capability may provide only a subset of the total songs stored as the basic available songs. If a user desires a song that is not a member of the provided subset, the user may pay extra to have the song played. If the song is stored in the larger master set on the expanded storage capacity, the song can be queued up immediately, without the need for download, allowing users faster access to an expanded song selection. Even if the song is not available on the expanded list, the user may order the song, and if suitable conditions, such as a high speed connection, exist, the user may hear the song almost immediately. Alternatively, the song may be downloaded and saved for the user to select at a later date or time, such as, for example, when the jukebox is connecting in dial-up mode and needs to download the songs at a later time.

In accordance with another exemplary aspect of the illustrative embodiments, the jukebox can be set to “customize mode,” where users can use an interface to select songs that will be transferred from the local server or expanded media storage to the jukebox or jukebox set. This mode could be used, for example, by regular users or customers and location staff to specify which songs should permanently reside on the jukebox after a jukebox is newly installed in a location.

In accordance with a further exemplary aspect of the illustrative embodiments, a jukebox can “morph” based on a triggering event. Triggering events can include themed establishment nights, time changes, or any other suitable criteria. When the jukebox morphs, it may provide a wholly or partially different subset of available songs for user selection at normal cost. Additionally, since the interface is a digital one, new graphics, advertising or other suitable display changes may occur, in accordance with the morph. The morph may also selectively block all access to certain songs, based on the appropriateness of the song under the criteria which caused the morph. For example, if an establishment had a “country night,” then the available songs might shift to all country songs. The jukebox might further block expanded access to all songs that were not defined as appropriate for a “country night,” so that such blocked songs were not even available for play at an increased price until the morph had expired. The definition of “appropriate songs” can be a factory set definition, or can be definable by the operator of the jukebox or by any other suitable classification mechanism.

In accordance with another exemplary aspect of the illustrative embodiments, different terminals of a multi-zone system can morph independently of each other, so that, for example, a bar zone may morph after a certain hour while a restaurant zone may remain the same.

In accordance with an additional exemplary aspect of the illustrative embodiments, a user can bid on the right to have a song played before other songs previously selected for priority play are played. In a preferred embodiment, the user is shown the top price paid for a priority play, and can pay more than that price to obtain the highest priority available.

In accordance with a further exemplary aspect of the illustrative embodiments, a user may not be shown how much anyone else has paid for priority. The user can pay however much the user desires to spend to obtain a priority ranking, and then receive a ranking of priority based on the amount paid.

In accordance with another exemplary aspect of the illustrative embodiments, a user can pay however much the user desires to spend to obtain a priority ranking, and then be shown the priority spot which has been obtained based on the paid amount. If this spot is not satisfactory to the user, the user can pay additional money to move the song up in priority ranking. The user can also pay additional money to make it harder for other users to pre-empt the selected priority spot on the list in a bidding-type situation. Any other suitable method of increased-pay-for-increased-priority may also be implemented.

In accordance with a further exemplary aspect of the illustrative embodiments, a user can “lock in” a priority ranking with a payment of a pre-selected amount. For example, if a user pays 15 credits to obtain a ranking of 3^rdin priority, and wishes to guarantee the third ranking, the user may pay, for example, 4 more credits to “lock in” the ranking. Since locking in the ranking may require the “lock in” of all the rankings above the user as well, the user may be required to pay a certain amount to “lock in” all songs above the user's selection. In one such situation, the user can either choose to pay the price quoted for the “lock in” or pay the same or a varying amount of credits in an attempt to prevent future over-bidding or to move the user's song up further in the priority list.

In accordance with another exemplary aspect of the illustrative embodiments, any of the aforementioned bidding strategies may be implemented, and the user may be shown how much everyone has paid for their particular rankings. This allows the user to know exactly how much he will have to pay to obtain a certain priority position. If the “lock in” feature is implemented, this will also let a user know if it is cheaper to pay the price to “lock in” the song or to pay to move up on the priority list. All of these options result in increased revenue for the operator.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, objects and advantages of the instant invention will be further understood by review of the following detailed description of the invention when read in conjunction with the appended drawings, in which:

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

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

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

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

FIG. 4A shows an exemplary process for using a Personal Music Assistant to search for songs that might be appropriate for a user-specified profile;

FIG. 4B shows an exemplary process for using a Personal Music Assistant to search for songs that might be appropriate for a recognized user's profile;

FIG. 5 is another exemplary screen shot showing the results of a search on the local server and providing the user an option of downloading a desired song to the jukebox device for a fee, in accordance with a preferred embodiment of the instant 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 access to the downloading feature of the instant invention;

FIG. 7 shows a block diagram of a preferred embodiment of the local sever of the instant 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 that are managed by the jukebox system of the instant 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 flowchart showing an exemplary implementation of a zone selection process for a multi-zone jukebox system;

FIG. 12 is a flowchart showing an exemplary implementation of a priority play by 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, with a subset of queues for each zone;

FIG. 14 is a flowchart showing an exemplary distribution and initialization scheme for a jukebox with morph capability;

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

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

FIG. 17 shows the relationship between a jukebox with expanded 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; and

FIG. 19 is a flowchart showing an exemplary process for a priority play queue with prioritization-based-on-bidding capability.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

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 elements as shown in FIG. 1 and described above, including a central server 12, communications network 14, and remote jukebox devices 16, 16a-16f. However, the jukebox system 10′ further includes local servers 22, 22a-22f respectively connected to each of the jukebox devices 16, 16a-16f. The central server 12 includes a master library of songs (and/or other content). Each of the jukebox devices includes a subset of the master library on a local storage device of the jukebox. The central server may be used to individually manage the contents of the jukebox device, by monitoring usage of and updating the subset of songs on each of the jukebox devices with the intent of maximizing the usage thereof. The central server 12 periodically receives data from each of the jukeboxes for the purpose of royalty accounting and payment for songs played. The jukebox devices may connect to the network in any suitable manner, such as dial-up modem or broadband modem (e.g., DSL, cable, wireless broadband, or satellite). The communications network 14 may be any suitable network capable of distributing data (e.g., audiovisual 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.

The songs (and/or other data) are preferably digitized, compressed and encrypted by the central server 12 prior to sending songs to the jukeboxes for security and bandwidth purposes using known techniques. The songs are then decompressed and decrypted by the jukeboxes for storage and reproduction thereon. Thus, each of the jukeboxes maintains in a database a library of digitized songs for play on the jukebox, wherein the library can be changed or updated through communication by the central server. The jukeboxes preferably also receive and store data constituting images (e.g., still and/or moving video and/or graphical images) that can be displayed on the display 18 of the jukebox device 16. In one exemplary embodiment of the invention, the jukebox devices have the structure and operation described in U.S. Pat. No. 6,308,204 referenced above. Thus, the jukebox devices 16 each preferably include one or more microprocessors, such as a main CPU and an audio DSP, a memory, such as a hard drive, for storing songs and/or other content, a display of displaying visual items, an audio arrangement 20 for providing audio, a communication system for enabling the jukebox to communicate with the central server 12 through the communications network 14, and operating software, preferably including a multitasking operating system, that controls the operation of the jukebox. The operating software is also preferably updateable through communication with the central server 12 as described, for example, in U.S. Pat. No. 6,308,204 referenced above. The jukeboxes 16 further include one or more payment devices, such as coin, bill and/or credit card input devices, for enabling a customer to pay for usage of the jukebox device in a convenient manner. The screen 18 is preferably a touch screen that enables the user to input selections by touching the screen.

Each jukebox device has a local server 22 that can be accessed by the jukebox device. The local servers are respectively connected to the jukebox devices using Ethernet or other type of local connection. The local servers 22 each preferably include a mirror copy of the master library of musical recordings maintained by the central server 12. The local server 22 can be loaded with the master library by the 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 sever will no longer correspond identically to the central server, due to the fact that the central server is preferably continually updated with additional or new songs. Thus, the local servers 22 are also preferably updated periodically to maintain a correspondence with the library on the central server 12. This updating can be done, for example, by the central server 12 through communication with the jukebox devices connected with the local servers 22 using, for example, either dial-up or broadband modems. Alternatively, the updating can be done personally with an update tool that can be connected by a routeman or other person directly to the jukebox or local server for the purpose of updating the contents of the local server. The portable tool could include a removable storage medium, such as a hard drive, that could be returned to and reused by the owner of the jukebox system for future updates. The tool itself could be keep by the operator or other person in charge of maintaining specific jukeboxes for use upon receipt of the updated removable storage medium from the owner of the jukebox system.

For security reasons, the local server 22 preferably does not include all of the digital data that constitutes any one song that is stored on the local server 22. In addition, the part of the song that is on the local server is encrypted. The jukebox device 16 contains the missing part of each of the songs on the local server, thereby enabling the jukebox to assemble the complete song based on the contents of the local server and the memory on the jukebox device. The missing data located on the jukebox is needed in order to decrypt the songs. For example, a single block (or other small fraction) of data for each song may be missing on the local server but present on the jukebox device, and the encryption may be based on the missing block and may proceed on a block by block basis. Thus, none of the blocks can be decrypted without obtaining and/or decrypting a preceding block. This feature provides significant security and prevents or deters theft or other type of unauthorized use or copying of the songs on the local server. Thus, in this embodiment, each local server must be specifically assigned to a specific jukebox device so that the decryption described above can be properly performed.

In accordance with a preferred exemplary embodiment, the local servers may also each be individually registered with and identified to the central server 12, so that the central server can individually manage and monitor each local server. The same is true for the jukebox device itself, i.e., it may also preferably be registered with the central server so that it too can be individually monitored and managed by the central server. As will be understood from the foregoing description, the local servers become an important and advantageous part of the jukebox system by allowing the contents thereof to be accessed by the jukebox device to provide additional services (such as providing additional songs) not available on the jukebox device itself. As will be explained below, the song library of the central server and/or the storage capacity itself can be advantageously used to provide services to other jukeboxes, such as fee-based residential and commercial jukeboxes and/or other fee-based equipment. One preferred use of the local servers may be to provide an immediate song downloading feature for the jukebox device will now be described below in detail with reference to the exemplary screen shots of FIGS. 3-6.

FIG. 3 shows an exemplary screen shot for a music selection screen 30 as displayed on the touch display of the jukebox device. As can be seen in FIG. 3, this selection screen, which is preferably the initial selection screen displayed to a customer, includes graphical representations 32 of the various album covers for songs that are stored in the memory of the jukebox device. The albums covers are shown in alphabetical order and the virtual slide bar 33 can be used to scroll through the available albums. Up and down arrows (34 and 35) are also provided for stepping through the available albums. A “Now Playing” button 36 is also provided for showing information on the song currently playing on the jukebox (if any). A “Top Ten” button 38 is also provided for showing a list of the ten most popular songs on the jukebox. A “Tune Central” (TM of TouchTunes 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 covers or desires for any reason to search for available songs that are not present on the jukebox device, the user may select the “Tune Central” button 39. When the “Tune Central” button is pressed, the display on the jukebox is changed from that of FIG. 3 to that of FIG. 4. The exemplary screen shot of FIG. 4 shows a search screen 40 which enables a search to be performed on the local server 22 connected to the jukebox device. This screen 40 provides a virtual keyboard 42 for use in entering a search request. The search can be done by album, artist, song, or genres or themes (i.e. categorized lists of songs, preferably based on popularity, that help a user find a particular song), based on the associated buttons 47. Once a search is typed, the user touches the “Search” button 44 and a search of the contents of the local server is initiated. Input from the virtual keyboard can be cleared using the “Clear” button 46.

Similar to the genres and themes search, a user may, for example, search for a song using a Personal Music Assistant, an exemplary process for which is shown in FIG. 4A. Preferably, after pressing a Personal Assistant button (step 402), the jukebox would ask certain information to identify the user if the user is not already identified (step 404). Such information could include, for example, age (or date of birth), preferred style, background, place of birth, or other information that could be used to generate a profile of the user. The jukebox then preferably could compare the profile information to selections made by other users with similar profiles (step 406) from, for example, the specific jukebox, the particular establishment, or a national database and recommend songs (step 408). For example, the jukebox might suggest a song by “The Doors” to a male user from California who was born in 1960. The user could then choose a song from that list or initiate a new search (step 410).

Furthermore, instead of entering identifiers, as shown in FIG. 4B, the Personal Music Assistant could recognize a user in other ways (step 422), such as, for example, after a credit card or a pre-programmed site-specific identification card is swiped by the jukebox. Preferably, the Personal Music Assistant would maintain a list of selections made by the user. The user's list of selections could be maintained, for example, on a local jukebox terminal, on a site's central jukebox server, on a remote server, or on an identification card. After the Personal Music Assistant recognizes the user, it could then recommend songs based on, for example, songs by the artists the particular user enjoys (step 426), songs played frequently by the user (428), songs not heard recently by the user (430), etc.

Additionally, a Personal Music Assistant recognizing, for example, a preferred customer or a customer with a large number of credits might morph the jukebox into a jukebox more enjoyable to that specific user. Credits could be, for example, purchased by the user; or given to the user as a reward, for example, for purchasing drinks or souvenirs at an establishment, or for being a regular repeat customer. Thus, a Personal Music Assistant could make selecting songs a more enjoyable, dynamic, and responsive process while removing the immediate pressure place on the user to know which song to choose.

When a search is initiated from screen 40, the screen is changes to that shown in FIG. 5 to display the results of the search. As shown in FIG. 5, the results of the search are listed. More particularly, in this example, a list of songs that satisfy the search request are listed. The list could also be by album if the search was album based. The user can scroll through the search results using slide bar 53. The user is also shown a display 55 of the number of current credits and a display 56 of the number of credits that are required to download a song from the local server to the jukebox device. The user can go back to the previous screen by touching the “Back” button 57. If the user selects and song from the search list and then touches the “Get It Now” button 54, the jukebox is operable to immediately download the selected song from the local server to the jukebox for play on the jukebox. The downloaded song can be queued up with any other selected but unplayed songs (if any) for play on the Jukebox. In this example, the download costs five credits instead of one credit like a normal selection from the storage of the jukebox itself. Once the downloaded song is played, it is preferably deleted from the jukebox device (together with any graphical data, such as the album cover graphic) that was also downloaded from the local server in connection with the song download). In this way, the user has the option, through use of the “Tune Central” button, to temporarily obtain on the jukebox any song from the master library of recordings without the need to contact the central server 12. As a result, the jukebox provides a more enjoyable experience for the user, while also increasing revenue generated thereby.

Also providing an enjoyable experience for the user is the central servers' capability to identify “hot hits,” preferably in real-time. Preferably, new songs could be made available in a master catalog—that is, they need not reside on local servers or expanded media storage. Then, songs played frequently in a given area (ranging from, for example, a single site or group of sites, to a state or country, to a global connection) could be identified as popular. These songs, or “hot hits,” preferably could be downloaded by, or sent to, individual jukeboxes. Individual jukeboxes preferably would maintain lists of “hot hits” in real-time, allowing users to search through the most popular songs at any given time. Alternatively, a jukebox might maintain a list of “hot hits” without downloading the popular songs, thereby potentially saving download time and resources. As a result, the jukebox could provide an enjoyable experience for the user by providing easy access to the most popular songs.

FIG. 5A shows an exemplary process for maintaining a “hot list” on a jukebox with a broadband connection. It should be noted that the same process could apply for a system with a different type of connection, though more time and resources may be used to download a song over a slower connection. In step 502, songs from a master catalog are received by a site's central server. Of course, it should be noted that songs could be stored to a local jukebox's storage media. In step 504, a user using a jukebox terminal would select a “Hot List” button. After the “Hot List” is displayed (step 506), the user could select a particular song or initiate a new search (508).

FIG. 6 shows another exemplary screen shot of a song selection screen 60 that is displayed when a user touches an album cover graphic from the screen 30 of FIG. 3. Thus, this screen shows an alternative (or typical) method of selecting a song, wherein the song is selected directly from the subset of songs that are directly available from the storage device of the jukebox itself (rather than the local server). In this example, Joe Cocker's Greatest Hits was selected from the screen of FIG. 3. As shown in FIG. 6, the resulting screen display 60 shows the selected album graphic 61 and a list of the songs 62 that are available 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 necessary using scroll bars 63a and 63b. The user has the option, through the “Play” button 65, to select a song from the list for play on the jukebox. A “Play Now” button 66 is also provided for enabling the user to select a priority play of the song, thereby giving the song a higher priority than songs selected using the “Play” button 65. This priority feature preferably requires more play credits than the normal play. A display 67 shows the number of credits available for the user. Button 64 shows other albums for the same artist being shown at 61, thereby enabling a user to easily search through the albums for a particular artist for a desired song.

As also shown in FIG. 6, a “Tune Central” button 68 is displayed that enables the user to search for songs by this same artist on the local server as explained in connection with FIG. 4. In other words, button 68 takes the user to the search screen 40 of FIG. 4 for searching the local server. The user can then proceed to search the local server and select songs therefrom, if desired, as described above in connection with FIGS. 4 and 5. Thus, as explained above, the user can access the local server at various screens in a convenience and efficient manner, depending on the desires of the user when interacting with the jukebox screen.

As can be seen from FIGS. 3-6, the user is provided with the option of playing songs that are resident on the jukebox device itself or, alternatively, selecting songs from the local server for download and play in an efficient and reliable manner, thereby significantly improving the operation of jukebox systems, particularly those that cannot quickly, easily or reliably receive downloads of music on demand from a central server. It is noted that the screen shots of FIGS. 3-6 are only exemplary and any suitable screen configurations can be used to provide the functionality described herein. In addition, the jukebox operator is provided with the ability through operator screens (not shown) to set filters per genre or style of music in order to limit access to the end user and avoid undesirable music being played at a specific location.

FIG. 7 shows a block diagram of the electronic elements that define the local server 22 in accordance with an exemplary embodiment. As shown in FIG. 7, the local server 22 includes a CPU 72 (e.g., AMD Elan 100 MHz), a flash memory (e.g., 8 MB) 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 pairs respectively, a RAM 76 (e.g., 32 MB), an Ethernet controller for controlling communication with the jukebox device 16, and the appropriate buses interconnecting the various elements. Of course, other configurations or arrangements for the local server 22 may be used. A unique identifier may be provided in the local server for enabling the local server to be uniquely identified and registered by the jukebox and/or central server. The identifier may, for example, be located in the flash memory 74.

As will be appreciated from the description of the invention above, the addition of the local server significantly enhances the operation of the jukebox devices that are part of a jukebox system. However, the local servers also provide other benefits and features that will now be described.

A collection of local servers 22 may be used as a network of distributed servers that can be controller by the central server 12 through its associated jukebox device 16 to provide music services to other devices. For example, the local servers and associated jukebox can be used to deliver requested songs to a dedicated residential or commercial jukebox device (or other suitable jukebox device) in addition to providing song services to the specific jukebox to which it is connected and assigned. Thus, the network of distributed servers can provide a support network for implementing residential and commercial jukeboxes of the type which allow a user to download songs for reproduction and/or storage at a residential or commercial location for an appropriate fee. As a result, the jukebox system operator can provide and control commercial jukeboxes and well as residential jukeboxes through the jukebox system. In this embodiment, the jukebox device and/or local server are connected to the Internet (or other suitable network) using a broadband modem and is provided with software that can selectively deliver song files to any dedicated residential jukebox device (also connectable to the Internet) under control of the central server. The central server receives requests from a residential jukebox and, by analyzing traffic on the network, provides instructions to a 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 under a subscription plan for the residential jukebox.

In accordance with another exemplary aspect of the invention, the local server and jukebox device are used, under control of the central server, to provide management services for other types of coin operated or payment triggered equipment, such as gaming devices, installed in the same location as (or in close proximity to) the jukebox. In other words, the jukebox system is preferably used to update the functionality of and/or manage other downloading devices present in the same location. As a result, the jukebox becomes a “central hub” for all downloading equipment in a location. This feature is achieved, in one embodiment, by networking all of the downloading devices in a single location together with the jukebox and local file server. The central server can then download information to the local server together with instructions to the jukebox as to which devices should updated with what data and/or software. The jukebox device and central server can also be used to collect information from the other downloading devices to which it is managing and upload that information to the central server for reporting/accounting purposes. Thus, the owner/operator of the jukebox system can act as a third party service provider to other coin-op companies for the purpose of managing and/or updating their equipment.

The large amounts of memory provided by the local servers and the fact that they are provided and accessible at thousands of locations over a well controlled network, turns the jukebox system into a powerful tool that can be used to perform a variety of functions in the coin-op industry. More and more coin-op manufacturers are going towards games that are software upgradeable through their internal hard drives. These updates are done periodically, but as these devices increase there will be an ever increasing need for a system that can reliably and efficiently perform the updates from a remote location. The jukebox system described herein satisfies this need by enabling all suitable electronic coin-op devices at a jukebox location to be managed by the central server using the jukebox and local server at the location. The central server can download software or data updates, store them on the local server and then dispatch the updates to the intended units of equipment in the establishment. Thus, the jukebox system can act as a third party service provider to other companies in the coin-op business, thereby significantly enhancing the functionality of the jukebox system.

As an example, there are currently about 140,000 Merit coin-operated countertop devices in the USA, each of which enables users to play games and the like for a fee. Many of these devices operate with a hard drive that can be upgraded with new software. Merit does this by shipping CD-ROMs to operators who then need to drive to each location and manually update each machine. In accordance with the instant invention, however, all suitable coin-op equipment at a location are connected (directly or indirectly) with the local jukebox and local server assigned thereto. This enables the central server to receive the intended software update for any device, together with information that identifies what devices are to upgraded with what software. The upgrade services are preferably fee based and provide an additional revenue stream for the jukebox system. The central server then downloads the software to the local servers with the upgrade instructions to further download the upgrades to the appropriate device(s).

As explained above, the local server enables songs to be downloaded to a commercial jukebox to which it is assigned or to residential jukeboxes under control of the central server. In addition, the local servers can be used for an on-premise networked application which manages other coin-op devices. These various features of the instant invention are illustrated in FIG. 8.

FIG. 8 shows a block diagram of a complete jukebox system network as contemplated by an exemplary embodiment. As explained 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 via broadband devices 102a, 102b and 102c, and an on-premise network shown on the right hand side of FIG. 8. This on-premise network includes a jukebox device 16d connected via a router or network hub 110 to a local file server 22d, a number of additional coin-op equipment, such as a dart game 104, a golf game 106 and a countertop videogame 108, and a broadband modem 112 connecting this local network to the communications network 14. With this exemplary configuration as shown in FIG. 8 all of the functionality described herein can be implemented through the jukebox system of the instant invention.

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

Alternatively, the user may elect to have a song played in more than one of the zones 121, 123, 125 simultaneously, or in more than one of the zones at different times. The user may have to pay additional credits to implement either of these features. A preferred embodiment of a multi-zone system could play music at a high quality in the different zones using the system described in application Ser. No. 11/023,390, filed Dec. 29, 2004, entitled “Wireless Digital Transmission System for Loudspeakers,” which is a continuation in part of Ser. No. 09/161,584, filed on Sep. 28, 1998. The entire contents of both applications is incorporated herein by reference. Using this system, for example, a jukebox could compress and transmit audio data through AC power lines to an addressable location, where it could be received, decompressed, converted, and played.

It is to be appreciated that Wireless Digital Transmission System can be used for other purposes in other embodiments where data needs to be sent between two or more devices. For example, this system could be used to configure dummy terminals. In such an embodiment, the Wireless Digital Transmission System could be used to send information such as, for example, whether to morph, what songs are appropriate given a particular morphing of the jukebox, the zones in which selected music should be played, maximum volume levels, etc.

The operator may also restrict what kind of music is available in a given zone, based on the type of activity in the zone, 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 listen to the same type of music as someone in zone one 121, which is a bar room in FIG. 9, or in zone two 123, which is a pool room. The operator may recognize this and restrict the type of music that can be played in zone three 125. Alternatively, the operator may restrict the volume of the music in any given zone. For example, patrons of a pool room 123 or a restaurant section 125 may not want the music as loud as it is desired to be in the bar room 121. And maybe the restaurant section 121 is to be kept quieter even than the pool room 123. The owner can adjust and control all suitable settings to provide the most versatile, patron friendly environment in each of the zones, based on any suitable criteria.

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

In FIG. 10 there are also one or more “dummy” terminals 137, 139 located throughout the establishment. An exemplary illustrative dummy terminal could use X-server technology. These terminals 137, 139, which may be stand alone devices or may be provided as part of the interface on a gaming machine or other suitable device with a digital display, allow selection of songs from the jukebox 133. These terminals 137, 139 duplicate the zone restrictions imposed on the main jukebox interface and selection criteria. The terminals 137, 139 may be restricted to only allowing selection of music for play in the zone where each respective terminal is located, or they may allow selection for play in one or more different zones.

Additionally, the graphical interface of the terminals 137, 139 may change in accordance with available selections, themes of the bar, themes of the room in which each terminal is located, or any other suitable criteria.

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

FIG. 12 is a flowchart showing an exemplary implementation of a priority play by zone selection process for a multi-zone jukebox system. In accordance with an exemplary embodiment, certain jukebox systems may be provided with one or more priority queues corresponding to one or more zones. If priority play is provided for a zone or zones, the jukebox first checks to see if the user would like to select priority play for the selected song 161. If priority play is selected, the jukebox then provides an option for the user to choose a zone or zones in which priority play should occur 163. Based on the number of zones selected for priority play, the jukebox determines a price 165, and accepts payment of that price 167 from the user. The jukebox then places the song in a 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. In accordance with an exemplary embodiment, each of N zones 171 may be provided with its own set of queues, comprising a priority queue 175 and a non-priority queue 173. A list of songs selected for play is maintained within each queue 173, 175. Each song in each queue may be provided with an identifier 177, 179, which identifies the song, and/or the position 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 capability. In accordance with an exemplary embodiment, the contents of a factory drive are defined at the point of manufacture 181. This same drive (expanded media storage) may be shipped out with all jukeboxes 183, and may only contain a subset of the total number of songs available on the central server. Once the jukebox containing the drive has reached its destination, the operator may select a subset of songs on the drive as the basic playable list 185. This selection can be made based on the type of establishment, the type of music the establishment's patrons typically prefer, or any other suitable criteria. The operator may also allow the central server to recommend a basic playable list. The drive may also allow selection of songs not on the basic list for an additional fee 187. This list of “alternate” songs might not include all songs however, as the operator might desire to restrict access to songs that don't meet the theme of the establishment. For example, a country bar owner might not ever want to allow selection of rap or hip-hop songs on the jukebox.

Once the songs on the drive have been appropriately categorized, the jukebox begins operation 189. As long as a new basic playable list is not desired 191, the jukebox continues to operate 189 with the currently selected basic playable list. If a new basic playable list is desired 191, the jukebox morphs 193 into a “new” jukebox, selecting a different playable subset of songs for basic selection 185, and changing additional characteristics as dictated by the morph.

FIG. 15 is a flowchart showing an exemplary implementation of an automatic jukebox morph initiation process based on a triggering event. In accordance with an exemplary embodiment, the user may define an event 201, for example a themed night or a time of day, as a triggering event which triggers a jukebox morph. The jukebox then operates as normal 203, checking periodically to see if the triggering event occurs 205. If the triggering event has not occurred, the jukebox simply continues to operate 203, but if the triggering event occurs, the jukebox is morphed into a “new” jukebox. The triggering events may be one time events, or they may be scheduled to occur weekly, daily, monthly or scheduled based on any other suitable criteria. It should be noted that in a multi-zone configuration, different zones may be morphed while others do not change. This feature of the illustrative embodiments allows, for example, a given zone or zones to be dedicated to a certain kind of music while the other(s) may vary based on any variety of factors, such as the time of day, an owner's desire to change the music, or a user's request.

FIG. 16 is a flowchart showing an exemplary implementation of a jukebox morphing process. In accordance with an exemplary embodiment, when the jukebox begins morphing 211, it selects a new subset of songs to be the basic playable list 213. The jukebox then allows some or all of the remaining songs on the jukebox to be selected for an enhanced fee 215. Some of the remaining songs may be restricted based on what triggered the morph. Other characteristics of the jukebox may also change 217, for example, the user interface may be changed, and different advertising may be displayed which corresponds with the predicted tastes of the crowd for which the jukebox has been morphed. Other suitable changes may also be made. In one example of a preferred embodiment, a club owner has a hip-hop night on Wednesdays, beginning at 9:00 pm and ending at 4:00 am. At 9:00 pm on Wednesdays, the jukebox morphs into a hip-hop jukebox, with a basic selection of appropriate music. In accordance with the morph, the jukebox blocks all access to genres of music such as country music, classic rock, jazz, blues and oldies, and the jukebox limits the available selection of hard rock additional songs to “hip-hop-esque” hard rock songs. The graphics on the jukebox convert to edgy, urban graphics, and the advertising changes accordingly, displaying products such as apparel, drinks, and goods which should appeal to the hip-hop crowd. At 4:00 am, the jukebox morphs back into the “standard” jukebox for that club, or into any other suitable jukebox. Alternatively, the jukebox may remain set in hip-hop mode until the next triggering event occurs. Again, it should be noted that in a multi-zone configuration, different zones may be morphed while others do not change. In the above exemplary non-limiting embodiments, the system might morph into hip-hop in one zone for the night, while the “standard” music for the club remains playing in another area.

FIG. 17 shows the relationship between a jukebox with expanded media storage and a central server. In accordance with an exemplary embodiment, the central server 221 contains a master library of songs, such library comprising all songs that are currently available to be downloaded and all songs currently installed on jukebox hard drives. The central server may communicate 222 with the remote jukebox 225 containing a local hard drive 223. The hard drive 223 on the jukebox may have several sections, including available space for downloads 227, space occupied by preloaded songs 228, and space for software and an operating system 229. Additional suitable sections may be added, for example, a section containing different pictures for altering the GUI. The jukebox 225 may communicate with the central server 221 to download songs, upload usage information, update software, and perform any other suitable functions.

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. In accordance with an exemplary embodiment, the user first selects a song 231. The jukebox checks to see if the song is available on the local hard drive as a “non-standard” selection 233. If the song is available on the local hard drive, the jukebox charges the customer the price set for obtaining and playing a non-standard song 235 and plays the song 237 (or adds it to a playlist, when appropriate).

If the song is not available on the local hard drive, the jukebox checks to see if a high-speed connection to the central server is available 239. If there is no high-speed connection, the jukebox informs 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 amount for ordering the song. If, however, there is an available high-speed connection to the central server, the jukebox orders the song immediately and uses the high-speed connection to download the song right away, queuing it up for playing 245. The jukebox then charges the customer the price of a non-standard selection 247.

FIG. 19 is a flowchart showing an exemplary process for a priority play queue with prioritization-based-on-bidding capability. According to an exemplary embodiment, the user first indicates that he would like priority play 251. The jukebox then displays the current status of the priority play queue 253. This display may include information such as how many songs are in the queue, what the top bid is, how much has been bid on each song, which songs are “locked in,” and any other suitable information about the priority queue. The jukebox then allows the user to select how much additional money the user would like to pay to place his song in a particular spot on the priority list and accepts payment in the selected amount 255. After accepting the payment 255, the jukebox places the song in a position on the priority list corresponding to the additional amount received from the user 257.

Alternatively, in another exemplary aspect of the illustrative embodiments, a user can bid on the right to have a song played before other songs previously selected for priority play are played. In a preferred embodiment, the user is shown the top price paid for a priority play, and can pay more than that price to obtain the highest priority available.

Another exemplary aspect of the illustrative embodiments does not allow a user to be shown how much anyone else has paid for priority. The user can pay however much the user desires to spend to obtain a priority ranking, and then receive a ranking of priority based on the amount paid.

In accordance with a further exemplary aspect of the illustrative embodiments, a user can pay however much the user desires to spend to obtain a priority ranking in accordance with the previous exemplary aspect, and then be shown the priority spot which has been obtained based on the paid amount. If this spot is not satisfactory to the user, the user can pay additional money to move the song up in priority ranking, and be shown the new priority ranking obtained based on the additional money paid. The user can repeat this process until the desired priority ranking has been obtained. The user can also pay additional money to make it harder for other users to pre-empt the selected priority spot on the list in a bidding-type situation. Any other suitable method of increased-pay-for-increased-priority may also be implemented.

In accordance with an additional exemplary aspect of the illustrative embodiments which may provide a “lock in” feature, a user can “lock in” a priority ranking with a payment of a pre-selected amount. For example, if a user pays 15 credits to obtain a ranking of 3^rdin priority, and wishes to guarantee the third ranking, the user may pay, for example, 4 more credits to “lock in” the ranking. Since locking in the ranking may require the “lock in” of all the rankings above the user as well, the user may be required to pay a certain amount to “lock in” all songs above the user's selection. In one such situation, the user can either choose to pay the price quoted for the “lock in” or pay the same or a varying amount of credits in an attempt to prevent future over-bidding or to move the user's song up further in the priority list.

It should be noted that although the embodiments above describe a system for distributing media to non-movable jukeboxes, alternative embodiments using similar systems could distribute media to portable jukebox devices and are contemplated by, and within the scope and spirit of, this invention. A portable jukebox may be, for example, a PDA, a cell phone, or any other movable device capable of receiving and playing music. Furthermore, media may be distributed to portable jukeboxes using the above described methods (e.g. through a broadband connection, wireless connection, etc.), or any other appropriate method, more suited to the particular portable device, such as, for example, using Bluetooth technology. Additionally, the jukeboxes described above typically are for commercial purposes. However, jukeboxes for other purposes such as, for example, playing residential media, also are contemplated by, and within the scope and spirit of, this invention.

While the preferred aspects of the invention have been illustrated and described herein, it will be apparent to one of ordinary skill in the art that various changes and/or modifications can be made. Thus, the specific description herein is meant to be exemplary only and is not intended to limit the invention beyond the terms of appended claims.

Claims

1. A method of operating a jukebox having a processor, a digital memory storage, a payment receiving unit, a plurality of output channels each of which is connected to a respective speaker located at a respectively different geographic zone in a multi-zone establishment, and at least one queue of a plurality of queues, in a memory accessible to the processor, corresponding to each output channel of the plurality of channels, the method comprising: providing, using the processor and in the digital memory storage, a storage location storing a first plurality of instances of media available for output;configuring a first amount of money to be collected, using the payment receiving unit communicatively coupled to the processor, for playing one or more instances of media;receiving, from a user input device communicatively coupled to the processor, input corresponding to a selection, by a jukebox user, of the plurality of output channels to which one or more instances of media are to be output via a first subset of queues of the plurality of queues;receiving, by the processor, input from the jukebox user selecting a second plurality of instances of media from the stored first plurality of instances of media, the received input indicating that each instance of the selected second plurality of instances is to be output to a respectively different one of the selected plurality of output channels via a second subset of queues of the plurality of queues;determine, by the processor and based at least on how many of the output channels are selected by the jukebox user, an additional amount of money greater than the first amount of money to charge the jukebox user;collect, using the processor and the payment receiving unit, an amount of money corresponding to the determined amount; andoutputting, using the processor, to each of the selected plurality of output channels via a respectively different queue of the second subset of queues a corresponding instance of media from the selected second plurality of instances of media at the same time based on the input from the jukebox user and whether said collected amount of money is an appropriate amount of money for the selected output channels.
2. The method of claim 1, further comprising: associating a non-priority queue and a priority queue, from the plurality of queues, with each said output channel;maintaining each non-priority queue such that instances of media selected by users for playback on the associated output channel are stored in the order that they were selected by the one or more users; andmaintaining each priority queue such that instances of media selected by users for playback on the associated output channel are prioritized based on a predefined prioritization algorithm, wherein the predefined prioritization algorithm assigns priorities to the instances of media based on the corresponding collected amounts of money.
3. The method of claim 2, wherein the predefined prioritization algorithm specifies that an instance of media for which a greater amount of money was collected is given priority in the associated priority queue over another instance of media for which a lesser amount was collected by the collection mechanism.
4. The method of claim 3, further comprising displaying an amount of money collected for each instance of media in the priority queue corresponding to one of the plurality of output channels.
5. The method of claim 2, further comprising assigning, by the predefined prioritization algorithms of more than one of the plurality of priority queues corresponding to more than one of the plurality of the output channels, a same priority position in the respective lists to a specific instance of media selected for output on the more than one of the plurality of output channels to guarantee simultaneous play on the more than one of the plurality of output channels.
6. The method of claim 5, further comprising charging an additional amount of money for guaranteeing simultaneous play.
7. A jukebox operable in an out-of-home location on a pay-for-play basis, comprising: a storage location storing a first plurality of instances of media available for output;a plurality of output channels which are configured to output one or more instances of media and each of which is configured to be connected to a respective speaker located at a respectively different geographic zone in a multi-zone establishment;at least one processor;a memory coupled to the processor;a plurality of queues in the memory, with at least one queue of the plurality of queues corresponding to each output channel of the plurality of channels;the at least one processor configured to present a user interface and control the jukebox to at least: configure the jukebox to collect a first amount of money for playing one or more instances of media;receive input corresponding to a selection, by a jukebox user, of two or more of the plurality of output channels to which one or more instances of media are to be output via a first subset of queues of the plurality of queues, via the user interface;receive input from the jukebox user selecting a second plurality of instances of media from the stored first plurality of instances of media, the received input indicating that each instance of the selected second plurality of instances is to be output to a respectively different one of the selected output channels via a second subset of queues of the plurality of queues;determine, based at least on how many of the output channels are selected, an additional amount of money greater than the first amount of money to charge the jukebox user;collect an amount of money corresponding to the determined amount; andcontrol the jukebox to output to each of the selected output channels via a respectively different queue of the second subset of queues a corresponding instance of media from the selected second plurality of instances of media at the same time based on the input from the jukebox user and whether said collected amount of money is an appropriate amount of money for the selected output channels.
8. The jukebox of claim 7, further comprising: a non-priority queue and a priority queue, in the plurality of queues, associated with each said output channel;each non-priority queue being maintained such that instances of media selected by users for playback on the associated output channel are stored in the order that they were selected by the one or more users; andeach priority queue being maintained such that instances of media selected by users for playback on the associated output channel are prioritized based on a predefined prioritization algorithm, wherein the predefined prioritization algorithm assigns priorities to the instances of media based on the corresponding collected amounts of money.
9. The jukebox of claim 8, wherein the predefined prioritization algorithm specifies that an instance of media for which a greater amount of money was collected is given priority in the associated priority queue over another instance of media for which a lesser amount was collected by the collection mechanism.
10. The jukebox of claim 9, wherein the user interface is configured to display an amount of money collected for each instance of media in the priority queue corresponding to one of the plurality of output channels.
11. The jukebox of claim 8, wherein the predefined prioritization algorithms of more than one of the plurality of priority queues corresponding to more than one of the plurality of the output channels is configured to assign a same priority position in the respective lists to a specific instance of media selected for output on the more than one of the plurality of output channels to guarantee simultaneous play on the more than one of the plurality of output channels.
12. The jukebox of claim 11, wherein the at least one processor is further configured to charge an additional amount of money for guaranteeing simultaneous play.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No. 14/883,885 filed Oct. 15, 2015, which is a divisional of U.S. application Ser. No. 13/336,866 filed Dec. 23, 2011, now U.S. Pat. No. 10,089,613 issued Oct. 2, 2018, which is a continuation of application Ser. No. 11/185,974 filed Jul. 21, 2005, now U.S. Pat. No. 8,103,589 issued Jan. 24, 2012, which is a Continuation-in-Part of application Ser. No. 10/661,811 filed Sep. 15, 2003, now U.S. Pat. No. 9,646,339 issued May 9, 2017, which claims priority on Provisional Application No. 60/410,832 filed Sep. 16, 2002, the entire contents of each of which are hereby incorporated by reference in its entirety.

US Referenced Citations (676)

Number	Name	Date	Kind
3807541	Kortenhaus	Apr 1974	A
3982620	Kotenhaus	Sep 1976	A
4008369	Theurer et al.	Feb 1977	A
4186438	Benson	Jan 1980	A
4232295	McConnell	Nov 1980	A
4335809	Wain	Jun 1982	A
4335908	Burge	Jun 1982	A
4336935	Goldfarb	Jun 1982	A
4356509	Skerlos et al.	Oct 1982	A
4369442	Werth et al.	Jan 1983	A
4375287	Smith	Mar 1983	A
4412292	Sedam	Oct 1983	A
4413260	Siegel et al.	Nov 1983	A
4521014	Sitrick	Jun 1985	A
4528643	Freeny	Jul 1985	A
4558413	Schmidt et al.	Dec 1985	A
4572509	Sitrick	Feb 1986	A
4577333	Lewis et al.	Mar 1986	A
4582324	Koza	Apr 1986	A
4588187	Dell	May 1986	A
4593904	Graves	Jun 1986	A
4597058	Izumi	Jun 1986	A
4636951	Harlick	Jan 1987	A
4652998	Koza	Mar 1987	A
4654799	Ogaki	Mar 1987	A
4658093	Hellman	Apr 1987	A
4667802	Verduin et al.	May 1987	A
4674055	Ogaki et al.	Jun 1987	A
4675538	Epstein	Jun 1987	A
4677311	Morita	Jun 1987	A
4677565	Ogaki	Jun 1987	A
4703465	Parker	Oct 1987	A
4704725	Harvey et al.	Nov 1987	A
4707804	Leal	Nov 1987	A
4722053	Dubno	Jan 1988	A
4761684	Clark	Aug 1988	A
4766581	Korn et al.	Aug 1988	A
4787050	Suzuki	Nov 1988	A
4792849	McCalley	Dec 1988	A
4807052	Amano	Feb 1989	A
4811325	Sharples	Mar 1989	A
4814972	Winter et al.	Mar 1989	A
4825054	Rust	Apr 1989	A
4829570	Schotz	May 1989	A
4852154	Lewis et al.	Jul 1989	A
4857714	Sunyich	Aug 1989	A
4868832	Marrington	Sep 1989	A
4885694	Pray et al.	Dec 1989	A
4905279	Nishio	Feb 1990	A
4920432	Eggers	Apr 1990	A
4922420	Nakagawa	May 1990	A
4924378	Hershey	May 1990	A
4926485	Yamashita	May 1990	A
4937807	Weitz	Jun 1990	A
4949187	Cohen	Aug 1990	A
4953159	Hayden et al.	Aug 1990	A
4956768	Sidi	Sep 1990	A
4958835	Tashiro	Sep 1990	A
4965675	Masashi et al.	Oct 1990	A
4977593	Ballance	Dec 1990	A
4999806	Chernow	Mar 1991	A
5008814	Mathur	Apr 1991	A
5012121	Hammond	Apr 1991	A
5027426	Chiocca	Jun 1991	A
5041921	Scheffler	Aug 1991	A
5046093	Wachob	Sep 1991	A
5053758	Cornett et al.	Oct 1991	A
5058089	Yoshimara	Oct 1991	A
5077607	Johnson et al.	Dec 1991	A
5081534	Geiger et al.	Jan 1992	A
5101451	Ash et al.	Mar 1992	A
5101499	Streck et al.	Mar 1992	A
5106097	Levine	Apr 1992	A
5117407	Vogel	May 1992	A
5128862	Mueller	Jul 1992	A
5138712	Corbin	Aug 1992	A
5148159	Clark et al.	Sep 1992	A
5155847	Kirouac	Oct 1992	A
5159678	Wengelski et al.	Oct 1992	A
5163131	Row	Nov 1992	A
5166886	Molnar	Nov 1992	A
5172413	Bradley et al.	Dec 1992	A
5180309	Egnor	Jan 1993	A
5189630	Barstow et al.	Feb 1993	A
5191573	Hair	Mar 1993	A
5191611	Lang	Mar 1993	A
5192999	Graczyk	Mar 1993	A
5197094	Tillery	Mar 1993	A
5203028	Shiraishi	Apr 1993	A
5210854	Beaverton et al.	May 1993	A
5214761	Barrett et al.	May 1993	A
5222134	Waite et al.	Jun 1993	A
5228015	Arbiter et al.	Jul 1993	A
5231157	Herzig et al.	Jul 1993	A
5237157	Kaplan	Aug 1993	A
5237322	Heberle	Aug 1993	A
5239480	Huegel	Aug 1993	A
5250747	Tsumura	Oct 1993	A
5252775	Urano	Oct 1993	A
5260999	Wyman	Nov 1993	A
5261104	Bertram et al.	Nov 1993	A
5262875	Mincer et al.	Nov 1993	A
5276866	Paolini	Jan 1994	A
5278904	Servi	Jan 1994	A
5282028	Johnson et al.	Jan 1994	A
5289476	Johnson et al.	Feb 1994	A
5289546	Hetherington	Feb 1994	A
5315161	Robinson	May 1994	A
5315711	Barone et al.	May 1994	A
5319455	Hoarty et al.	Jun 1994	A
5321846	Yokota et al.	Jun 1994	A
5327230	Dockery	Jul 1994	A
5335313	Douglas	Aug 1994	A
5339095	Redford	Aug 1994	A
5339413	Koval	Aug 1994	A
5341350	Frank	Aug 1994	A
5355302	Martin et al.	Oct 1994	A
5357276	Banker	Oct 1994	A
5369778	SanSoucie	Nov 1994	A
5375206	Hunter	Dec 1994	A
5386251	Movshovich	Jan 1995	A
5389950	Martin et al.	Feb 1995	A
5404505	Levinson	Apr 1995	A
5406634	Anderson et al.	Apr 1995	A
5408417	Wilder	Apr 1995	A
5410326	Goldstein	Apr 1995	A
5410703	Nilsson et al.	Apr 1995	A
5418713	Allen	May 1995	A
5420923	Beyers	May 1995	A
5428252	Walker	Jun 1995	A
5428606	Moskowitz	Jun 1995	A
5431492	Rothschild	Jul 1995	A
5440632	Bacon et al.	Aug 1995	A
5444499	Saitoh	Aug 1995	A
5445295	Brown	Aug 1995	A
5455619	Truckenmiller et al.	Oct 1995	A
5455926	Keele	Oct 1995	A
5457305	Akel	Oct 1995	A
5465213	Ross	Nov 1995	A
5465329	Whistler	Nov 1995	A
5467212	Huber	Nov 1995	A
5467326	Miyashita et al.	Nov 1995	A
5469370	Ostrover et al.	Nov 1995	A
5469573	McGill et al.	Nov 1995	A
5471576	Yee	Nov 1995	A
5473746	Pritt et al.	Dec 1995	A
5475835	Hickey	Dec 1995	A
5481509	Knowles	Jan 1996	A
5487167	Dinallo et al.	Jan 1996	A
5489103	Okamoto	Feb 1996	A
5495610	Shing	Feb 1996	A
5496178	Back	Mar 1996	A
5499921	Sone	Mar 1996	A
5511000	Kaloi	Apr 1996	A
5513117	Small	Apr 1996	A
5515173	Mankovitz et al.	May 1996	A
5519435	Anderson	May 1996	A
5519457	Nishigaki et al.	May 1996	A
5521631	Budow et al.	May 1996	A
5521918	Kim	May 1996	A
5521922	Fujinami et al.	May 1996	A
5523781	Brusaw	Jun 1996	A
5528732	Klotz	Jun 1996	A
5532734	Goertz	Jul 1996	A
5532991	Sasaki	Jul 1996	A
5546039	Hewitt et al.	Aug 1996	A
5548729	Akiyoshi	Aug 1996	A
5550577	Verbiest	Aug 1996	A
5554968	Lee	Sep 1996	A
5555244	Gupta	Sep 1996	A
5557515	Abbruzzese et al.	Sep 1996	A
5557541	Schulhof	Sep 1996	A
5557724	Sampat et al.	Sep 1996	A
5559505	McNair	Sep 1996	A
5559549	Hendricks	Sep 1996	A
5559714	Banks et al.	Sep 1996	A
5561709	Remillard	Oct 1996	A
5565908	Ahmad	Oct 1996	A
5566237	Dobbs	Oct 1996	A
5570363	Holm	Oct 1996	A
5578999	Matsuzawa et al.	Nov 1996	A
5579404	Fielder et al.	Nov 1996	A
5583561	Baker et al.	Dec 1996	A
5583937	Ullrich et al.	Dec 1996	A
5583994	Rangan	Dec 1996	A
5583995	Gardner et al.	Dec 1996	A
5592482	Abraham	Jan 1997	A
5592551	Lett	Jan 1997	A
5592611	Midgely et al.	Jan 1997	A
5594509	Florin	Jan 1997	A
5596702	Stucka et al.	Jan 1997	A
5607099	Yeh et al.	Mar 1997	A
5612581	Kageyama	Mar 1997	A
5613909	Stelovsky	Mar 1997	A
5616876	Cluts	Apr 1997	A
5617565	Augenbraun et al.	Apr 1997	A
5619247	Russo	Apr 1997	A
5619249	Billock et al.	Apr 1997	A
5619250	McClellan et al.	Apr 1997	A
5619698	Lillich	Apr 1997	A
5623666	Pike	Apr 1997	A
5631693	Wunderlich et al.	May 1997	A
5636276	Brugger	Jun 1997	A
5638426	Lewis	Jun 1997	A
5642337	Oskay et al.	Jun 1997	A
5643831	Ochiai et al.	Jul 1997	A
5644714	Kikinis	Jul 1997	A
5644766	Coy	Jul 1997	A
5654714	Takahashi et al.	Aug 1997	A
5659466	Norris et al.	Aug 1997	A
5661517	Budow et al.	Aug 1997	A
5661802	Nilssen	Aug 1997	A
5663756	Blahut et al.	Sep 1997	A
5668592	Spaulding	Sep 1997	A
5668778	Quazi	Sep 1997	A
5668788	Allison	Sep 1997	A
5675734	Hair	Oct 1997	A
5680533	Yamato et al.	Oct 1997	A
5684716	Freeman	Nov 1997	A
5689641	Ludwig et al.	Nov 1997	A
5691778	Song	Nov 1997	A
5691964	Niederlein et al.	Nov 1997	A
5696914	Nahaboo et al.	Dec 1997	A
5697844	Von Kohorn	Dec 1997	A
5703795	Mankowitz	Dec 1997	A
5708811	Arendt	Jan 1998	A
5712976	Falcon et al.	Jan 1998	A
5713024	Halladay	Jan 1998	A
5715416	Baker	Feb 1998	A
5717452	Janin et al.	Feb 1998	A
5721583	Harada et al.	Feb 1998	A
5721815	Ottesen et al.	Feb 1998	A
5721827	Logan et al.	Feb 1998	A
5721829	Dunn et al.	Feb 1998	A
5724525	Beyers et al.	Mar 1998	A
5726909	Krikorian	Mar 1998	A
5734719	Tsevdos et al.	Mar 1998	A
5734961	Castille	Mar 1998	A
5739451	Winksy et al.	Apr 1998	A
5743745	Reintjes	Apr 1998	A
5745391	Topor	Apr 1998	A
5748254	Harrison et al.	May 1998	A
5748468	Notenboom et al.	May 1998	A
5748954	Mauldin	May 1998	A
5751336	Aggarwal et al.	May 1998	A
5752232	Basore et al.	May 1998	A
5757936	Lee	May 1998	A
5758340	Nail	May 1998	A
5761655	Hoffman	Jun 1998	A
5762552	Vuong	Jun 1998	A
5774527	Handelman et al.	Jun 1998	A
5774668	Choqiuer	Jun 1998	A
5774672	Funahashi	Jun 1998	A
5778395	Whiting	Jul 1998	A
5781889	Martin et al.	Jul 1998	A
5786784	Gaudichon	Jul 1998	A
5790172	Imanaka	Aug 1998	A
5790671	Cooper	Aug 1998	A
5790856	Lillich	Aug 1998	A
5790935	Payton	Aug 1998	A
5793364	Bolanos et al.	Aug 1998	A
5793980	Glaser	Aug 1998	A
5798785	Hendricks	Aug 1998	A
5802283	Grady et al.	Sep 1998	A
5802558	Pierce	Sep 1998	A
5802599	Cabrera	Sep 1998	A
5805804	Laursen et al.	Sep 1998	A
5808224	Kato	Sep 1998	A
5809246	Goldman	Sep 1998	A
5812643	Schelberg et al.	Sep 1998	A
5815146	Youden et al.	Sep 1998	A
5825884	Zdepski et al.	Oct 1998	A
5828343	MacDonald et al.	Oct 1998	A
5831555	Yu et al.	Nov 1998	A
5831663	Waterhouse et al.	Nov 1998	A
5832024	Schotz et al.	Nov 1998	A
5832287	Atalla	Nov 1998	A
5835843	Haddad	Nov 1998	A
5842869	McGregor et al.	Dec 1998	A
5845104	Rao	Dec 1998	A
5845256	Pescitelli et al.	Dec 1998	A
5848398	Martin	Dec 1998	A
5851149	Xidos et al.	Dec 1998	A
5854887	Kindell	Dec 1998	A
5857020	Peterson	Jan 1999	A
5857707	Devlin	Jan 1999	A
5862324	Collins	Jan 1999	A
5864811	Tran et al.	Jan 1999	A
5864868	Contois	Jan 1999	A
5864870	Guck	Jan 1999	A
5867714	Todd	Feb 1999	A
5870721	Norris	Feb 1999	A
5880386	Wachi et al.	Mar 1999	A
5880769	Nemirofsky et al.	Mar 1999	A
5884028	Kindell	Mar 1999	A
5884298	Smith	Mar 1999	A
5887139	Madison, Jr. et al.	Mar 1999	A
5887193	Takahashi	Mar 1999	A
5892900	Ginter	Apr 1999	A
5893162	Lau et al.	Apr 1999	A
5895455	Bellinger et al.	Apr 1999	A
5896094	Narisada et al.	Apr 1999	A
5903266	Berstis et al.	May 1999	A
5913040	Rakavy	Jun 1999	A
5914712	Sartain et al.	Jun 1999	A
5915094	Kouloheris	Jun 1999	A
5915238	Tjaden	Jun 1999	A
5917537	Lightfoot	Jun 1999	A
5917835	Barrett	Jun 1999	A
5918213	Bernard et al.	Jun 1999	A
5920700	Gordon et al.	Jul 1999	A
5920702	Johnson	Jul 1999	A
5923885	Johnson	Jul 1999	A
5926531	Petite	Jul 1999	A
5926624	Katz et al.	Jul 1999	A
5930765	Martin	Jul 1999	A
5931908	Gerba	Aug 1999	A
5933090	Christenson	Aug 1999	A
5940504	Griswold	Aug 1999	A
5949411	Doerr et al.	Sep 1999	A
5949688	Montoya	Sep 1999	A
5953429	Wakai et al.	Sep 1999	A
5956716	Kenner et al.	Sep 1999	A
5959869	Miller	Sep 1999	A
5959945	Kleiman	Sep 1999	A
5960167	Roberts et al.	Sep 1999	A
5963916	Kaplan	Oct 1999	A
5966495	Takahashi	Oct 1999	A
5970467	Alavi	Oct 1999	A
5978855	Metz et al.	Nov 1999	A
5978912	Rakavy et al.	Nov 1999	A
5980261	Mino et al.	Nov 1999	A
5999499	Pines et al.	Dec 1999	A
5999624	Hopkins	Dec 1999	A
6002720	Yurt	Dec 1999	A
6005599	Asai et al.	Dec 1999	A
6008735	Chiloyan et al.	Dec 1999	A
6009274	Fletcher	Dec 1999	A
6011758	Dockes et al.	Jan 2000	A
6018337	Peters	Jan 2000	A
6018726	Tsumura	Jan 2000	A
6021386	Davis	Feb 2000	A
6023705	Bellinger et al.	Feb 2000	A
6025868	Russo	Feb 2000	A
6034925	Wehmeyer	Mar 2000	A
6038591	Wolfe et al.	Mar 2000	A
6040829	Croy et al.	Mar 2000	A
6041354	Biliris et al.	Mar 2000	A
6049891	Inamoto	Apr 2000	A
6054987	Richardson	Apr 2000	A
6055573	Gardenswartz et al.	Apr 2000	A
6057874	Michaud	May 2000	A
6069672	Claassen	May 2000	A
6072982	Haddad	Jun 2000	A
6107937	Hamada	Aug 2000	A
6118450	Proehl et al.	Sep 2000	A
6124804	Kitao et al.	Sep 2000	A
6131088	Hill	Oct 2000	A
6131121	Mattaway et al.	Oct 2000	A
6134547	Huxley et al.	Oct 2000	A
6138150	Nichols et al.	Oct 2000	A
6148142	Anderson	Nov 2000	A
6151077	Vogel et al.	Nov 2000	A
6151634	Glaser	Nov 2000	A
6154207	Farris et al.	Nov 2000	A
6157935	Tran et al.	Dec 2000	A
6161059	Tedesco et al.	Dec 2000	A
6170060	Mott et al.	Jan 2001	B1
6173172	Masuda et al.	Jan 2001	B1
6175861	Williams, Jr. et al.	Jan 2001	B1
6182126	Nathan et al.	Jan 2001	B1
6185184	Mattaway et al.	Feb 2001	B1
6185619	Joffe et al.	Feb 2001	B1
6191780	Martin et al.	Feb 2001	B1
6192340	Abecassis	Feb 2001	B1
6195732	Adams et al.	Feb 2001	B1
6198408	Cohen	Mar 2001	B1
6202060	Tran	Mar 2001	B1
6209060	Machida	Mar 2001	B1
6212138	Kalis et al.	Apr 2001	B1
6216175	Sliger et al.	Apr 2001	B1
6216227	Goldstein et al.	Apr 2001	B1
6219692	Stiles	Apr 2001	B1
6223209	Watson	Apr 2001	B1
6226412	Schwab	May 2001	B1
6226715	Van Der Wolf et al.	May 2001	B1
6240550	Nathan et al.	May 2001	B1
6243725	Hempleman et al.	Jun 2001	B1
6247022	Yankowski	Jun 2001	B1
6256773	Bowman-Amuah	Jul 2001	B1
6262569	Carr et al.	Jul 2001	B1
6280327	Leifer et al.	Aug 2001	B1
6282709	Reha et al.	Aug 2001	B1
6288688	Hughes et al.	Sep 2001	B1
6288991	Kajiyama et al.	Sep 2001	B1
6289382	Bowman-Amuah	Sep 2001	B1
6292443	Awazu et al.	Sep 2001	B1
6298373	Burns et al.	Oct 2001	B1
6301710	Fujiwara	Oct 2001	B1
6302793	Fertitta et al.	Oct 2001	B1
6308204	Nathan et al.	Oct 2001	B1
6311214	Rhoads	Oct 2001	B1
6315572	Glaser	Nov 2001	B1
6323911	Schein et al.	Nov 2001	B1
6332025	Takahashi et al.	Dec 2001	B2
6336219	Nathan	Jan 2002	B1
6341166	Basel	Jan 2002	B1
6344862	Williams et al.	Feb 2002	B1
6346951	Mastronardi	Feb 2002	B1
6353820	Edwards et al.	Mar 2002	B1
6356971	Katz et al.	Mar 2002	B1
6359616	Ogura et al.	Mar 2002	B1
6359661	Nickum	Mar 2002	B1
6370580	Kriegsman	Apr 2002	B2
6381575	Martin et al.	Apr 2002	B1
6384737	Hsu et al.	May 2002	B1
6393584	McLaren et al.	May 2002	B1
6396480	Schindler et al.	May 2002	B1
6397189	Martin et al.	May 2002	B1
6407987	Abraham	Jun 2002	B1
6408435	Sato	Jun 2002	B1
6408437	Hendricks et al.	Jun 2002	B1
6421651	Tedesco	Jul 2002	B1
6425125	Fries et al.	Jul 2002	B1
6430537	Tedesco et al.	Aug 2002	B1
6430738	Gross et al.	Aug 2002	B1
6434678	Menzel	Aug 2002	B1
6438450	DiLorenzo	Aug 2002	B1
6442549	Schneider	Aug 2002	B1
6446080	Van Ryzin et al.	Sep 2002	B1
6446130	Grapes	Sep 2002	B1
6449688	Peters et al.	Sep 2002	B1
6470496	Kato et al.	Oct 2002	B1
6473794	Guheen et al.	Oct 2002	B1
6488508	Okamoto	Dec 2002	B2
6490432	Wegener	Dec 2002	B1
6490570	Numaoka	Dec 2002	B1
6493871	McGuire et al.	Dec 2002	B1
6496927	McGrane et al.	Dec 2002	B1
6498855	Kokkosoulis et al.	Dec 2002	B1
6522707	Brandstetter et al.	Feb 2003	B1
6535911	Miller et al.	Mar 2003	B1
6538558	Sakazume et al.	Mar 2003	B2
6543052	Ogasawara	Apr 2003	B1
6544122	Araki et al.	Apr 2003	B2
6549719	Mankovitz	Apr 2003	B2
D475029	Nathan et al.	May 2003	S
6560651	Katz et al.	May 2003	B2
6570507	Lee et al.	May 2003	B1
6571282	Bowman-Amuah	May 2003	B1
6577735	Bharat	Jun 2003	B1
6578051	Mastronardi et al.	Jun 2003	B1
6587403	Keller et al.	Jul 2003	B1
6590838	Gerlings et al.	Jul 2003	B1
6598230	Ballhorn	Jul 2003	B1
6622307	Ho	Sep 2003	B1
6628939	Paulsen	Sep 2003	B2
6629318	Radha et al.	Sep 2003	B1
6643620	Contolini et al.	Nov 2003	B1
6643690	Duursma et al.	Nov 2003	B2
6654801	Mann et al.	Nov 2003	B2
6658090	Harjunen et al.	Dec 2003	B1
6662231	Drosset et al.	Dec 2003	B1
6702585	Okamoto	Mar 2004	B2
6724974	Naruto et al.	Apr 2004	B2
6728824	Chen	Apr 2004	B1
6728956	Ono	Apr 2004	B2
6728966	Arsenault et al.	Apr 2004	B1
6744882	Gupta et al.	Jun 2004	B1
6751794	McCaleb et al.	Jun 2004	B1
6755744	Nathan et al.	Jun 2004	B1
6762585	Liao	Jul 2004	B2
6789215	Rupp et al.	Sep 2004	B1
6816578	Kredo et al.	Nov 2004	B1
6850252	Hoffberg	Feb 2005	B1
6898161	Nathan	May 2005	B1
6904592	Johnson	Jun 2005	B1
6920614	Schindler et al.	Jul 2005	B1
6928653	Ellis et al.	Aug 2005	B1
6934700	Ijdens et al.	Aug 2005	B1
6942574	LeMay et al.	Sep 2005	B1
6974076	Siegel	Dec 2005	B1
7024485	Dunning et al.	Apr 2006	B2
7073172	Chamberlain	Jul 2006	B2
7103583	Baum et al.	Sep 2006	B1
7107109	Nathan et al.	Sep 2006	B1
7111129	Percival	Sep 2006	B2
7114013	Bakke et al.	Sep 2006	B2
7124194	Nathan et al.	Oct 2006	B2
7181458	Higashi	Feb 2007	B1
7188352	Nathan et al.	Mar 2007	B2
7195157	Swartz et al.	Mar 2007	B2
7198571	LeMay et al.	Apr 2007	B2
7205471	Looney et al.	Apr 2007	B2
7206417	Nathan	Apr 2007	B2
7210141	Nathan et al.	Apr 2007	B1
7231656	Nathan	Jun 2007	B1
7237198	Chaney	Jun 2007	B1
7281652	Foss	Oct 2007	B2
7293277	Nathan	Nov 2007	B1
7356831	Nathan	Apr 2008	B2
7406529	Reed	Jul 2008	B2
7415707	Taguchi et al.	Aug 2008	B2
7418474	Schwab	Aug 2008	B2
7424731	Nathan et al.	Sep 2008	B1
7430736	Nguyen et al.	Sep 2008	B2
7433832	Bezos et al.	Oct 2008	B1
7448057	Nathan	Nov 2008	B1
7483958	Elabbady et al.	Jan 2009	B1
7500192	Mastronardi	Mar 2009	B2
7512632	Mastronardi et al.	Mar 2009	B2
7519442	Nathan et al.	Apr 2009	B2
7533182	Wurtzel et al.	May 2009	B2
7549919	Nathan et al.	Jun 2009	B1
7574727	Nathan et al.	Aug 2009	B2
7647613	Drakoulis et al.	Jan 2010	B2
7657910	McAulay	Feb 2010	B1
D616414	Nathan et al.	May 2010	S
7749083	Nathan et al.	Jul 2010	B2
7757264	Nathan	Jul 2010	B2
7761538	Lin et al.	Jul 2010	B2
7769756	Krikorian	Aug 2010	B2
7770165	Olson et al.	Aug 2010	B2
7778879	Nathan et al.	Aug 2010	B2
7783593	Espino	Aug 2010	B2
7783774	Nathan et al.	Aug 2010	B2
7793331	Nathan et al.	Sep 2010	B2
7819734	Nathan et al.	Oct 2010	B2
7822687	Brillon et al.	Oct 2010	B2
D629382	Nathan et al.	Dec 2010	S
D642553	Nathan et al.	Aug 2011	S
7996873	Nathan et al.	Aug 2011	B1
8015200	Seiflien et al.	Sep 2011	B2
8028318	Nathan	Sep 2011	B2
8032879	Nathan et al.	Oct 2011	B2
8037412	Nathan et al.	Oct 2011	B2
8052512	Nathan et al.	Nov 2011	B2
8103589	Nathan et al.	Jan 2012	B2
8151304	Nathan et al.	Apr 2012	B2
D665375	Garneau et al.	Aug 2012	S
8292712	Nathan et al.	Oct 2012	B2
8332895	Nathan et al.	Dec 2012	B2
8429530	Neuman et al.	Apr 2013	B2
9436356	Nathan et al.	Sep 2016	B2
20010016815	Takahashi et al.	Aug 2001	A1
20010023403	Martin et al.	Sep 2001	A1
20010030660	Zainoulline	Oct 2001	A1
20010030912	Kalis et al.	Oct 2001	A1
20010032121	Le	Oct 2001	A1
20010037367	Iyer	Nov 2001	A1
20010044725	Matsuda et al.	Nov 2001	A1
20020002079	Martin et al.	Jan 2002	A1
20020002483	Siegel et al.	Jan 2002	A1
20020113824	Myers	Aug 2002	A1
20020116476	Eyal et al.	Aug 2002	A1
20020118949	Jones et al.	Aug 2002	A1
20020120925	Logan	Aug 2002	A1
20020123331	Lehaff et al.	Sep 2002	A1
20020126141	Mastronardi	Sep 2002	A1
20020129036	Ho Yuen Lok et al.	Sep 2002	A1
20020162104	Raike et al.	Oct 2002	A1
20030004833	Pollak et al.	Jan 2003	A1
20030005099	Sven et al.	Jan 2003	A1
20030006911	Smith et al.	Jan 2003	A1
20030008703	Gauselmann	Jan 2003	A1
20030018740	Sonoda et al.	Jan 2003	A1
20030027120	Jean	Feb 2003	A1
20030031096	Nathan et al.	Feb 2003	A1
20030041093	Yamane et al.	Feb 2003	A1
20030065639	Fiennes et al.	Apr 2003	A1
20030074421	Kusano	Apr 2003	A1
20030076380	Yusef et al.	Apr 2003	A1
20030088538	Ballard	May 2003	A1
20030093790	Logan et al.	May 2003	A1
20030101450	Davidsson et al.	May 2003	A1
20030104865	Itkis et al.	Jun 2003	A1
20030108164	Laurin	Jun 2003	A1
20030135424	Davis et al.	Jul 2003	A1
20030144910	Flaherty et al.	Jul 2003	A1
20030176218	LeMay et al.	Sep 2003	A1
20030182414	O'Neill	Sep 2003	A1
20030191753	Hoch	Oct 2003	A1
20030208586	Mastronardi et al.	Nov 2003	A1
20030220944	Lyman Schottland	Nov 2003	A1
20030225834	Lee et al.	Dec 2003	A1
20040010800	Goci	Jan 2004	A1
20040025185	Goci et al.	Feb 2004	A1
20040085334	Reaney	May 2004	A1
20040103150	Ogdon et al.	May 2004	A1
20040145477	Easter	Jul 2004	A1
20040158555	Seedman et al.	Aug 2004	A1
20040204220	Fried et al.	Oct 2004	A1
20040205171	Nathan et al.	Oct 2004	A1
20040220926	Lamkin et al.	Nov 2004	A1
20050048816	Higgins	Mar 2005	A1
20050060405	Nathan et al.	Mar 2005	A1
20050073782	Nathan	Apr 2005	A1
20050086172	Stefik	Apr 2005	A1
20050111671	Nathan	May 2005	A1
20050125833	Nathan et al.	Jun 2005	A1
20050201254	Looney et al.	Sep 2005	A1
20050267819	Kaplan	Dec 2005	A1
20060018208	Nathan et al.	Jan 2006	A1
20060031896	Pulitzer	Feb 2006	A1
20060035707	Nguyen et al.	Feb 2006	A1
20060062094	Nathan et al.	Mar 2006	A1
20060143575	Sauermann	Jun 2006	A1
20060227673	Yamashita et al.	Oct 2006	A1
20060239131	Nathan et al.	Oct 2006	A1
20060293773	Nathan et al.	Dec 2006	A1
20070025701	Kawasaki et al.	Feb 2007	A1
20070086280	Cappello et al.	Apr 2007	A1
20070121430	Nathan	May 2007	A1
20070139410	Abe et al.	Jun 2007	A1
20070142022	Madonna et al.	Jun 2007	A1
20070160224	Nathan	Jul 2007	A1
20070204263	Nathan et al.	Aug 2007	A1
20070209053	Nathan	Sep 2007	A1
20070220052	Kudo et al.	Sep 2007	A1
20070247979	Brillon et al.	Oct 2007	A1
20080065925	Oliverio et al.	Mar 2008	A1
20080066016	Dowdy et al.	Mar 2008	A1
20080069545	Nathan et al.	Mar 2008	A1
20080077962	Nathan	Mar 2008	A1
20080086379	Dion et al.	Apr 2008	A1
20080096659	Kreloff et al.	Apr 2008	A1
20080137849	Nathan	Jun 2008	A1
20080155588	Roberts et al.	Jun 2008	A1
20080168807	Dion et al.	Jul 2008	A1
20080171594	Fedesna et al.	Jul 2008	A1
20080195443	Nathan et al.	Aug 2008	A1
20080198271	Malki	Aug 2008	A1
20080222199	Tiu et al.	Sep 2008	A1
20080239887	Tooker et al.	Oct 2008	A1
20080305738	Khedouri et al.	Dec 2008	A1
20090030802	Plotnick et al.	Jan 2009	A1
20090037969	Nathan et al.	Feb 2009	A1
20090042632	Guenster et al.	Feb 2009	A1
20090063976	Bull et al.	Mar 2009	A1
20090070341	Mastronardi et al.	Mar 2009	A1
20090091087	Wasmund	Apr 2009	A1
20090100092	Seiflein et al.	Apr 2009	A1
20090138111	Mastronardi	May 2009	A1
20090172565	Jackson et al.	Jul 2009	A1
20090177301	Hayes	Jul 2009	A1
20090241061	Asai et al.	Sep 2009	A1
20090265734	Dion et al.	Oct 2009	A1
20090282491	Nathan	Nov 2009	A1
20090287696	Galuten	Nov 2009	A1
20090307314	Smith et al.	Dec 2009	A1
20100042505	Straus	Feb 2010	A1
20100211818	Nathan et al.	Aug 2010	A1
20100241259	Nathan	Sep 2010	A1
20100247081	Victoria Pons	Sep 2010	A1
20100269066	Nathan	Oct 2010	A1
20100299232	Nathan et al.	Nov 2010	A1
20110066943	Brillon et al.	Mar 2011	A1
20110283236	Beaumier et al.	Nov 2011	A1
20110321026	Nathan et al.	Dec 2011	A1
20120009985	Nathan et al.	Jan 2012	A1
20120053713	Nathan	Mar 2012	A1
20120095910	Nathan et al.	Apr 2012	A1
20120105464	Franceus	May 2012	A1
20120143732	Nathan et al.	Jun 2012	A1
20120150614	Dion et al.	Jun 2012	A1
20120158531	Dion et al.	Jun 2012	A1
20120166965	Nathan et al.	Jun 2012	A1
20120240140	Nathan	Sep 2012	A1
20130021281	Tse et al.	Jan 2013	A1
20130040715	Nathan et al.	Feb 2013	A1
20130044995	Cappello et al.	Feb 2013	A1
20130070093	Rivera et al.	Mar 2013	A1
20130091054	Nathan et al.	Apr 2013	A1
20140026154	Nathan	Jan 2014	A1
20140304117	Nathan et al.	Oct 2014	A1
20160034873	Nathan et al.	Feb 2016	A1

Related Publications (1)

	Number	Date	Country
	20190303894 A1	Oct 2019	US

Provisional Applications (1)

	Number	Date	Country
	60410832	Sep 2002	US

Divisions (1)

	Number	Date	Country
Parent	13336866	Dec 2011	US
Child	14883885		US

Continuations (2)

	Number	Date	Country
Parent	14883885	Oct 2015	US
Child	16444816		US
Parent	11185974	Jul 2005	US
Child	13336866		US

Continuation in Parts (1)

	Number	Date	Country
Parent	10661811	Sep 2003	US
Child	11185974		US

Digital downloading jukebox system with central and local music servers

Information

Patent Number

Date Filed

Date Issued

Inventors

Original Assignees

Examiners

Agents

CPC

Field of Search

US

International Classifications

Term Extension

Abstract