WO2025194119A1 - Digital jukebox device integrated entertainment system - Google Patents

Abstract

Certain exemplary embodiments relate to entertainment systems and, more particularly, to systems that incorporate digital jukebox devices in an integrated entertainment system. The integrated entertainment system supports connected game devices, and a mobile app and a digital wallet provide seamless operations for users at venues having both jukeboxes and game devices.

Description

TITLE

DIGITAL JUKEBOX DEVICE INTEGRATED ENTERTAINMENT SYSTEM

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application 63/565,342 filed March 14, 2024, and U.S. Provisional Application No. 63/566,893 filed March 18, 2024, the entire contents of each of which are hereby incorporated by reference herein.

TECHNICAL FIELD

[0001] Certain exemplary embodiments relate to digital entertainment systems and, more particularly, certain exemplary embodiments relate to pay-for-play digital jukebox device integrated entertainment systems.

BACKGROUND

[0002] Digital jukeboxes provide users with the ability to select desired music for reproduction in a convenient and advantageous manner. Jukeboxes are often provided in commercial establishments, such as restaurants and bars, in order to provide desired music on demand for patrons thereof for a fee. An example of a digital jukebox system is shown in U.S. Patent No. 6,308,204, the entire disclosure of which is incorporated herein by reference. A leading provider of this type of jukebox systems is TouchTunes Music Company.

[0003] Digital jukeboxes have evolved over time to add functionality that makes them more user-friendly to patrons, to operators who may distribute the jukeboxes, and/or to venue owners and staff who operate the jukeboxes on a day-to-day basis. Numerous capabilities have been incorporated to improve the user experience in selecting and playing songs, to make it easier for users to quickly discover songs they like, and to allow venue staff to customize the jukebox according to the venue’s requirements that could change over time and location. Some jukeboxes incorporated support for karaoke and photo booth features integrated with the jukebox. Such improved jukeboxes are described in U.S. Patent No. 9,292,166 and U.S. Patent No. 10,719,149, the entire disclosures of which are incorporated herein by reference. [0004] With recent trends in technology, society and social and/or entertainment venues, a need for still further improving the services and entertainment choices offered to patrons of digital jukebox devices have arisen.

SUMMARY

[0005] An example embodiment provides an integrated entertainment system, comprising: a digital jukebox device; a game device; a handheld electronic device configured to execute an entertainment app; and a remote server system configured to communicate with the digital jukebox device, the game device, and the entertainment app on the handheld device. The entertainment app is configured to: in response to a fist input received on the handheld electronic device, submit a first play request for a song on the digital jukebox device, wherein the submitting the first play request includes providing a first requested payment; and in response to a second input received on the handheld electronic device, submit a second play request for a game to the game device, wherein the submitting the second play request includes providing a second requested payment.

[0006] An example embodiment provides a computer-readable storage medium having stored instructions of an entertainment app that, when executed by a handheld electronic device, causes the handheld electronic device to perform operations comprising: in response to a fist input received on the handheld electronic device, submitting a first play request for a song on a digital jukebox device, wherein the submitting the first play request includes providing a first requested payment; and in response to a second input received on the handheld electronic device, submitting a second play request for a game to a game device, wherein the submitting the second play request includes providing a second requested payment. The digital jukebox device, the game device, and the entertainment app on the handheld device communicate with a remote server system.

[0007] An example embodiment provides a method comprising: monitoring actions of respective users in relation to a digital jukebox device at a venue; determining, based on the monitoring, that the monitored actions of a first user exceeds a threshold; in response to the determining, displaying a confirmation button on a handheld electronic device of the first user; and in response to an input received on the confirmation button, changing one or more privileges for the first user for using the digital jukebox device. [0008] An example embodiment provides a method comprising: displaying, on a handheld electronic device of a first user, a listing of one or more songs in a queue of songs waiting to be played on a digital jukebox device; receiving, on the handheld electronic device, a request to upgrade a song in the queue from a regular play delay category to a lower play delay category; in response to receiving from the first user a payment corresponding to the request to upgrade: controlling a configuration of the queue to play the upgraded song; and enabling the first user to have increased visibility into the queue.

[0009] An example embodiment provides a method comprising: monitoring actions of users in relation to a digital jukebox device at a venue; determining, based on the monitoring, that the monitored actions are below a threshold; in response to the determining, displaying a confirmation button on one or more handheld electronic devices in the venue; and in response to an input received on the confirmation button displayed on one of the handheld electronic devices, transferring one or more credits or digital coupons to a digital wallet associated with the one of the handheld electronic devices.

[0010] An example embodiment provides a method comprising: determining respective musical characteristics of each of a plurality of venues, each venue having at least one pay-for- play digital jukebox device; determining respective musical characteristics of each of a plurality of persons; and based on matching the determined respective musical characteristics of each of a plurality of venues and the determined respective musical characteristics of each of a plurality of persons, generating an itinerary comprising two or more of the venues for visiting by the plurality of persons.

[0011] An example embodiment provides a method comprising: detecting, at a venue, a presence of at least one user having associated stored replay music and a desired condition of a play queue in a digital jukebox device at the venue; prompting on a handheld electronic device for the at least one user to confirm use of the stored replay music; and responsive to an input on the handheld electronic device, controlling the play queue to play the stored replay music.

[0012] The exemplary embodiments, aspects, and advantages disclosed herein may be provided in any suitable combination or sub-combination to achieve yet further exemplary embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS [0013] These and other features, aspects, and advantages of the instant invention will be further understood by review of the following detailed description of the exemplary embodiments when read in conjunction with the appended drawings, in which:

[0014] Figure 1 illustrates a digital jukebox device integrated entertainment system in accordance with some embodiments of this disclosure. The illustrated jukebox device integrated entertainment system enables patrons to interact with jukeboxes and gaming devices at a venue using the same mobile app in a seamless manner.

[0015] Figure 2A illustrates a portion of the system shown in Figure 1 that is related to payment and/or credit processing, in accordance with some embodiments of this disclosure.

[0016] Figure 2B and Figure 2C illustrates example data organizations for the systems shown in Figure 1 and Figure 2A in accordance with some embodiments.

[0017] Figure 3 is a flow diagram illustrating an accelerated on-boarding process for users to engage with the system shown in Figure 1, according to some embodiments.

[0018] Figure 4A illustrates an example mobile device display that provides a user with more visibility into the queue in accordance with some embodiments.

[0019] Figure 4B illustrates an example mobile device display that provides more visibility as to what has already played so that the user can verify his/her selections have been played in accordance with some embodiments.

[0020] Figures 5A-5D illustrate example mobile device displays of a wallet being used at a venue at which the user is present has music, darts and billiards in which the user can participate using the credits available in the user’ s digital entertainment wallet, according to some embodiments.

[0021] Figure 6 shows example screens of a mobile app facilitating music dedication group plays (left), shared credits (center), and polling to enhance the shared music experience, according to some embodiments.

[0022] Figure 7 schematically illustrates a process that may assist users in a group at a particular venue to remember the vibe at the venue by presenting the user with key moments of the evening and allowing the users to create a shareable artifact that users in the group can save to help in later recalling the venue’s vibe, playlists etc. according to some embodiments. [0023] Figures 8A and 8B show an example crowd reaction (e.g., heart emojis) to a currently playing song in real-time as they come in, on the mobile app and on the jukebox screen, respectively, according to some embodiments.

[0024] Figures 9 and 10 show mini-players displayed on users’ mobile handheld devices that enable each user to have more visibility into the play queue at a venue, whose requests are in the queue, when your own song request will play, and full visibility to the queue, according to some embodiments.

[0025] Figure 11 illustrates an example of artificial intelligence-powered landing page generation for mobile handheld devices to announce a key moment (e.g., last call) in the evening in real time as determined based on the user’s profile, according to some embodiments.

[0026] Figure 12 illustrates example displays on a mobile handheld device in some embodiments to enable a group to gather at a particular venue.

[0027] Figures 13A-13B illustrate a 3D music discovery screen according to some embodiments.

[0028] Figure 14A shows an example screen by which a user is allowed to add credit to an existing song request in order to upgrade that song request, according to some embodiments. [0029] Figure 14B shows an example screen by which a user can participate in the crowd reactions to the song currently being played by using a selected emoji to express his/her feelings about the song, according to some embodiments.

[0030] Figure 14C shows an example screen by which a user can assist another user make selections by participating in real-time polls, according to some embodiments.

[0031] Figure 14D shows an example screen by which the system can improve user engagement by presenting trivia quizzes, according to some embodiments.

[0032] Figure 15 shows reactions being added to song listings, in accordance with some embodiments.

[0033] Figure 16 shows a screen enabling the patron to share a recap of the reactions to song selections, in accordance with some embodiments.

[0034] Figure 17 shows a screen that provides top music genre filters that enable surfacing venue’s top music genres and lets users filter the map and places list to find locations matching their preferences, in accordance with some embodiments. [0035] Figure 18 shows live social feed displays feed of activities and interactions happening at the venue and within groups displayed on the mobile app, in accordance with some embodiments.

[0036] Figure 19 illustrates developing collaborative playlists where users can collaborate using the mobile app with friends to curate playlists, in accordance with some embodiments.

[0037] Figures 20-25 show flowcharts of processes associated with several features in accordance with some embodiments.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

[0038] This disclosure provides an integrated entertainment system that incorporates one or more pay-for-play digital jukebox device, other entertainment devices, and a mobile entertainment app for use by patrons. The jukebox and mobile entertainment app-enabled integrated entertainment system improves the utilization of jukeboxes and other entertainment devices at venues by providing features that, for example and without being limiting, enable patrons to more easily discover and play songs on jukeboxes, enable seamless and more convenient participation in the activities enabled by other entertainment devices at respective venues, enable the use of the same mobile entertainment app and the same digital entertainment wallet to be used for different activities (e.g., song play, darts, billiards, etc.) available at the venues, enable users to remain increasingly engaged in real-time during the entire time the user dwells at a venue, etc.

[0039] FIG. 1 shows an example digital jukebox device integrated entertainment system 100 according to some embodiments of this disclosure. System 100 integrates multiple entertainment venues 104 (e.g., venues 104a and 104b) through a central server system 102. Each entertainment venue 104a and 104b have one or more digital jukebox devices 108 (e.g., jukebox devices 108a and 108b) and one or more other types of entertainment devices such as, for example, digital dartboard devices 110 (e.g., digital dartboards 110a and 110b). A patron or other user at an entertainment venue may use one or more jukebox devices and/or one or more other types of entertainment devices such as the digital dartboard systems via an integrated mobile entertainment app on a handheld electronic device (also referred to herein as “handheld device”) such as, for example, a smartphone 106. For example, the patron is enabled to pay for song selections for a jukebox and to pay for games on another type of entertainment device at the venue, to manage credits available, to view and select songs, to view and select games or other activities etc. in the same integrated mobile entertainment app 107 on the same smartphone 106. The entertainment app 107, being a single app, provides the patron with a seamless experience (when compared to two or more apps each handling a respectively different set of features) at a venue while using jukeboxes and game devices at the venue.

[0040] System 100 includes a central server system 102 that comprises a master music catalog 114, which includes a library of audio content (typically music), as well as or alternatively audiovisual content (typically music and associated video or graphics), that can be downloaded and/or streamed therefrom to the remote digital jukebox devices 108 at the entertainment venues 104.

[0041] The central server system 102 also includes backend server processing logic to support various functions such as, for example, the mobile integrated entertainment app 107, jukeboxes 108, and game devices 110. For example, the music processing logic 112 includes server processing functionality to support for the music from music catalog 114 to be viewed and selected via the mobile entertainment app (also referred to as “entertainment app” or “mobile app”) 107 and/or any of the jukeboxes 108, and to have music and/or other audio/visual content to be played through jukeboxes 108, the game processing logic 126 includes the server processing functionality to support game devices 110 to be reserved for play and to be associated with the jukeboxes and other game devices at the same venue and/or at other venues, and the payment/credit processing logic 132 includes the server processing functionality to support for handling payment or credit related functions associated with the jukeboxes 108, game devices 110, and entertainment app 107.

[0042] A jukebox information database 116 has stored information regarding each of the jukeboxes 108 and a game device information database 130 has stored information regarding each of the game devices 110. A patron information database 118 stores information on each patron associated with the jukeboxes 108, game devices 110, and/or entertainment app 107. [0043] A patron music information database 120 stores information of each patron’s use of the jukeboxes 108 and entertainment app 107 in relation to jukeboxes, and a gamer information database 128 stores information each patron’s use of the game devices 110 and mobile app 107 in relation to game devices. [0044] Patron information database 118 stores information of each registered user such as name, contact information, credit card and/or bank account information, etc. In some embodiments, stored patron information includes patrons’ one or more external social networking site accounts in order to enable the patron to seamlessly share information (e.g., playlists, screen captures etc.) from the patron’s entertainment app 107 to the social media account of interest.

[0045] An operator information database 124 stores information regarding operators of the jukeboxes and/or game devices. In addition to operator identifying and contact information, this may also include information that can be used by the payment/credit processing logic 132 to process the operator’s share of revenue generated by the jukeboxes and game devices. A venue information database 122 stores information regarding each of the entertainment venues 104. Venue information may include venue name, address, location coordinates, owner information, and also profile and/or historical information about the use of jukeboxes and/or game devices at the venue.

[0046] A payment/credit facilitation information database 134 stores information regarding payments received and credits associated with venues, jukeboxes, and game devices. The information is used by the payment/credit processing logic 132 to communicate with each user’s entertainment app instantiation, jukeboxes at venues, and game devices at venues, in relation to users’ credit availability and credit usage.

[0047] Each of the jukebox devices are generally located in a bar, restaurant, club, or other desired location, and are operable to play music (e.g., from a suitable storage location such as, for example, from a local server, a central and potentially remote server, from local storage, etc.) in response to receiving a payment from a user, such as coins, bills, credit/debit card, other internet-enabled payment method, etc., and having one or more songs selected by the user for play. Jukebox device 108 typically includes a screen that presents information to the user and allows the user to select songs therefrom, as well as an audio system that plays the selected songs. The screen may also be used for displaying song-related video or graphics. The screen 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. [0048] Jukebox devices 108 (sometimes referred to herein as simply “jukeboxes”) are operable to communicate with the central server system 102 through a communications network, such as, for example, the Internet. The central server system 102 may be cloud-based. The jukeboxes 108 periodically communicate with the server system 102 in order to provide information to the server system 102 regarding the specific songs that have been played on the jukebox. The central server system 102 then uses this information, and other information, in order to determine the appropriate royalties and/or other payments that are owed for songs played on each jukebox. Thus, one advantage of this type 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 system 102 can also provide new songs to the jukebox 108 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 system in order to provide the songs and/or types of music that customers generally request at each jukebox location. As described in the abovereferenced U.S. Patent 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 advantage of this type 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 system 102.

[0049] As indicated above, jukebox devices 108 each may include a mass storage device, such as a hard drive, which stores 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 system 102. As a result, only a fraction of the songs stored on the central server are typically 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 system, but typically any one jukebox only stores a relatively small subset of the complete library of songs maintained by the central server at any one time.

[0050] The songs (and/or other data) may be digitized, compressed and encrypted by the central server system 102 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 may maintain 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 system. The jukeboxes may 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 of the jukebox device. In one exemplary embodiment, the jukebox devices have similar- structure and operation described in U.S. Patent No. 6,308,204 referenced above. Thus, the jukebox devices each may 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 for providing audio, a communication system for enabling the jukebox to communicate with the central server 102 through the communications network, and operating software, including a multitasking operating system, that controls the operation of the jukebox. Some jukeboxes 108 may further include one or more physical 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. Some jukeboxes may not include physical payment devices, but are configured so that songs are playable on the jukebox only upon submitting the required payments. The screen of the jukebox may be a touch screen that enables the user to input selections by touching the screen. [0051] Game devices 110 may include any of digital dartboard games, pool tables, card games, arcade games etc., that are connected to the central server system 102. At a particular venue, one or more game devices of any game device type may be located and connected to the integrated entertainment system 100. Some example game devices are soft-tip electronic darts platforms that provide for recreational and competitive play. In one example, without limitation, the “G3” series or “Galaxy 3” soft-tip electronic darts platforms produced by Arachnid, Inc.

(now part of TouchTunes Music Company, LLC) are connected to the integrated entertainment system 100 as game devices 110. [0052] In one exemplary embodiment, a game device has similar structure and operation described in U.S. Patent No. 8,894,068. The game devices each may 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 for providing audio, a communication system for enabling the jukebox to communicate with the central server system 102 through the communications network, and operating software, including a multitasking operating system, that controls the operation of the game device. Some game devices 110 may further include one or more physical 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. Some game devices may not include physical payment devices, but are configured so that games are playable on the game device only upon submitting the required payments. The screen of the game device may be a touch screen that enables the user to input selections by touching the screen.

[0053] It should be noted that each entertainment venue 104 may house any number of jukeboxes and any number of game devices. Some venues may not house game devices. Although only dartboard games are shown as examples of game devices, it should be noted that many other games such as, for example, billiards, cards, shuffleboard, etc. can have their own game stations connected to the integrated entertainment system 100. Example handheld devices may include smartphones, tablets, and other like portable devices. In some embodiments, a user’s handheld device, or more specifically the entertainment app executing on the handheld device can directly communicate with the jukeboxes and/or game devices at a venue, and can communicate with the central server system 102 either directly or via the jukeboxes or the game devices. In some embodiments, the entertainment apps do not directly communicate with the jukeboxes or game devices and can communicate with those only through the central server system 102.

[0054] FIG. 2A illustrates some aspects of the payment/credit processing logic 132 and the payment/credit facilitation information database 134 in more detail, according to some embodiments. As shown in FIG. 2A, the payment/credit facilitation information database 134 may include payment and/or credit purchase and use logs (e.g., credit log 202, transaction log 204), billing and payment information 206, and venue, jukebox device, game device, and operator information 208. The logs 202 and other stored information can be filtered to obtain the history of payment activities related to jukeboxes and/or game devices. The data 208 may be associated in the server memory with the respective databases for venue information, jukebox device information, game device information, operator information databases, etc. shown in FIG. 1.

[0055] A payment provider interface 212, partner proxy 214, partner gateway 216, mobile gateway 218, game command and control interface 220, and a jukeboxes command and control interface 222, enable the payment/credit facilitation information database 134 to communicate with other components of system 100 or with other systems. Payment provider interface 212 provides the functionality to interact with external credit/debit card processors (not shown in FIG. 2A). Partner proxy 214 and/or partner gateway 216 provide the functionality for the payment processing of system 100 to server music processing logic 112 and server game processing logic 126. The partner proxy 214 and/or partner gateway 216 also provide the functionality to provide credit information 217 to game devices 110 through game command and control 220 and to jukeboxes 108 through jukebox command and control 222 to facilitate the use of those devices by the patron 224. Its should be noted that in some embodiments, the jukebox and game devices accept credit types that are different from each other, and the system is configured to automatically perform the conversion from one to another.

[0056] The mobile gateway 218 enables the patron 224 to use the smartphone 106 to make payments to purchase credits and/or to transact credits. Each user’s smartphone 106 includes a digital entertainment wallet 109, that is implemented in association with the payment/credit facilitation information 134 and payment/credit processing logic 132 on the central server system 102, to hold the credits that can be used to engage with the jukeboxes and/or game devices at the venues. The digital entertainment wallet 109 may be incorporated in the entertainment app 107 and may store one or more credentials and some payment information on the handheld device 106. The payment/credit facilitation information 134 and payment/credit processing logic 132 on the central server system 102 provide the server-side storage and processing for the entertainment wallet 109 functionality. Secure implementation of digital entertainment wallet 109 and the associated central server system 102 may be implemented in accordance with known digital wallet technologies. In some implementations, the entertainment wallet 109 on the handheld device 106 is operable to accept a code and transmit that code to the payment/credit processing logic 132 on the central server system 102, and the payment/credit processing logic 132 can validate against a database or against an algorithm the validity of the code and, upon positive validation, the paymcnt/crcdit processing logic 132 is configured to allocate a monetary value or a credit value to the user entertainment wallet 109. The user entertainment wallet 109 and/or entertainment app 107 may be operable to browse content contained on the payment/credit processing information database 134 on the central server system 102 and the user entertainment wallet 109 may be further operable to select and pay for content using the monetary or the credit value, the central server system 102 may be operable to reduce the monetary or the credit value upon a selection by the entertainment app 107.

[0057] A data lake 210 or other data store may be used to collect historical payment and credit related data as well as other data of system 100. The data in data lake 210 may be accessed by analysts, data scientists, artificial intelligence systems etc., to analyze patterns in the use of the jukeboxes and game devices by patrons. The analysis may be used to optimize the song availability, features, types of games, number and types of devices at respective venues, etc. that are made available at the respective venues.

[0058] FIG. 2B illustrates a schematic of data structures and their organization related to venues, devices, operators, and partners, in accordance with some embodiments. As shown in the entity-relation diagram in FIG. 2B, each venue 104 may be represented by a place entity 230, each partner with a partner entity 236, each operator with an operator entity 242, and each device with a device entity 238. Each place entity 230 is associated with one or more external location entities 232, one or more localized place entities 234, and one or more device entities 238. Each operator entity is associated with one or more external operator entities 244. Each device entity 238 is associated with one or more localized device entities 240. Each partner entity 236 is associated with one or more device entities 238 and one or more external operator entities 244. Each external operator entity is associated with one or more device entities 238.

[0059] The inclusion of LocalizedPlace and LocalizedDevice entities enable support for multiple customization options for places and devices, which can be a significant advantage for scenarios with customization needs. The separation of Partner and Operator entities allows for flexibility in managing different roles and responsibilities. A partner supplies devices to operators and operates backend infrastructure for connected devices, and an operator operates devices for places (venues). [0060] FIG. 2C illustrates a schematic of data structures and their organization related to some aspects of transactions and credits in the system 100, and the devices associated with their use. Each device object 252 is associated with transactions objects 250, credit options objects 254, and bulk credit options 256. Each device includes a device ID specific to the integrated entertainment system 100 and a separate device ID to accommodate a partner/operator assignment. Each device object also stores a QR code encoding its device ID. To facilitate efficient conversion of credits between the integrated entertainment system 100 and partner systems, the credit options object 254 associated with a device includes a specification of the unit cost in partner credits, and each transaction object 250 includes the cost of the transaction in entertainment wallet credits and partner credits.

[0061] As noted above in relation to FIG. 1, the integrated entertainment system 100 may include a entertainment app 107 that enables users to use both the one or more jukeboxes and one or more game devices at a particular venue. The entertainment app may require that users register before any use of the entertainment devices at the venue, or at least to enjoy certain features of the devices. In order to encourage user adoption of the entertainment app (e.g., entertainment app 107) that requires the user to sign up, it is important that the sign on process is fast and not unduly burdensome for the user. There arc conflicting objectives when on boarding the first-time user. Typically, it is considered that every effort must be made to capture that user’s identity and make them a returning customer. However, the friction introduced by demanding more data can be sufficiently annoying to dissuade any further action on the user’s part towards becoming a registered user. Some embodiments provide an onboarding process flow that progresses the user very rapidly from the app download stage to song selection with a minimal number of steps and the minimal delay.

[0062] According to some embodiments, a new user is able to play music on a jukebox device and/or join an activity on a game devices at a venue by simply signing up, checking into a venue, and then paying for and selecting a song to be played on a jukebox at that venue or selecting an activity to be performed at a game device at that venue. One or more steps such as, for example, genre selection, artists selections, picking an avatar etc. are configured as optional, enabling the user to skip such steps in order to speedup the process of being able to select and play music on the jukebox at the venue. The sign in may include obtaining a username and password from the user. Alternatively, in some embodiments, the sign in may be made more convenient to the user by prompting the user to, instead of providing user information, simply select an authentication mechanism, such as, for example, Google Authentication, Apple Sign-in, Facebook login, or other OAuth protocol (e.g., OAuth 2.0) option that the user already has in place. The checking-in to the location may be as simple as merely having the user identify/confirm the venue that the system already determined. The entertainment app on the mobile handheld device may automatically (e.g., using the mobile handheld device’s location identification and system knowledge of the venue) associate the user and the mobile handheld device with the venue, and merely request the user for confirmation. The confirmation may be primarily for purposes of giving the user a choice to actively indicate whether the user intends to be associated with the venue. The automatic location identification may be enabled or disabled for respective locations by having the mobile app check a configuration parameter in the system’s corresponding location data structure. For receiving payments, the mobile app may automatically detect what payment services have been configured on the mobile device for the user, and request the user to select and/or confirm one or more of the automatically identified payment services to be used by the mobile app. Upon determining a payment service for the user, the entertainment wallet such as that described in relation to FIG. 2A may be initialized. In order to facilitate the user’s convenient selection of a song or activity, the mobile app may dynamically determine the current vibe or mood at the venue and suggest one or more songs or activities that are consistent the determined vibe or mood at the venue. In some embodiments, based on a configuration setting, for example, in the location data structure corresponding to the venue, the user’ s entertainment wallet may be initialized with free credits to immediately engage the user in music or games. Otherwise, the user may purchase credits by providing a credits card or other online payment service, before selecting a song. FIG. 3 illustrates an onboarding flow 300, according to some embodiments. The shown onboarding flow illustrates typical onboarding steps such as genre selection, artist selection, and avatar picking being made optional to speed up the internal between app download and requesting a song. In some embodiments, checking into the venue and/or a jukebox at the venue is mandatory for a user and/or the user’s handheld device to be part of, or participate in, the integrated entertainment system 100 while at the venue (e.g., to play songs on jukeboxes at the venue and/or play games on connected game devices at the venue). [0063] By minimizing the amount of information that the user is required to enter, and simplifying the onboarding process, some embodiments provide for minimizing hurdles for users to individually participate in the use of jukebox devices and/or game devices at the venue.

[0064] Example embodiments are configured to take advantage of various flexibilities offered by smartphones and like handheld devices to advance music services provided through the jukebox, and to make more seamless and convenient the engagement by users at a venue with the jukeboxes and/or game devices at that venue.

[0065] Music jukeboxes have generally treated all users equally with the only prioritization being the ability to accelerate the play of a song by paying a premium. In some embodiments, during the onboarding process, or at some other stage, users are offered the option of self-identifying as a “DJ” - an individual who is happy to take on the role of setting the vibe/mood in a location. They may not be the person to plan an outing, but they are highly interested in influencing the music at a venue.

[0066] The system may propose a role as the DJ role to a patron when the patron checks into a venue and/or jukebox devices at the venue. For example, the system may analyze a patron’s historical song requests, request frequency, level of correlation with the patron’s requests with genre and/or vibe with the venues at which the requests were made, reactions/responses (e.g., credits sent to the patron, likes etc.) by other patrons to the patron’s selections, and a level of matching between the patron’s historical selections and the current venue’s vibe/mood. The proposal may be made by the system displaying a message on the patron’s mobile handheld device. In some embodiments, the DJ role may also be provided with capabilities to enable the patron to have control of the use by other patrons of gaming devices connected to the system and the same venue.

[0067] In addition, the system may monitor the users in a location and can propose DJ status to a user who plays music frequently and whose music choices align with the music played in the venue. The monitoring and analysis of the vibe/mood in order to identify potential DJ invitees at a venue may be performed, for example, in the backend music processing logic 112, based on all or some of the mobile app-enabled mobile devices that are determined to be at the venue during a particular time period. The determination as to whether to propose the DJ role to a user can be based on the user’s song selection in the particular time period, the user’s song selections at other times (e.g., the user’s historical song selections at the present venue and/or other venues), and the jukebox play queue contents during the particular time period. The user’s song selections can be compared to the jukebox play queue contents, and more specifically, the queue contents at the time the user selection was made, to determine the quality of the user’s song selection choices in relation to the real-time musical vibe in the venue. In some implementations, the system identifies users who are prolific jukebox music purchasers, for example, by determining whether any one or more of statistics such as the total number of songs requested by the user, total credits used on song requests, total number of venues visited, frequency of visits to venues, the number of songs requested and/or credits used for song requests on a single visit to a venue, and like, exceeds one or more predetermined thresholds. A second criteria for being identified as a DJ invitee may be the quality of the user’ s song requests in relation to the real-time conditions of the jukebox play queue as determined in real-time while the user is at a particular venue. In some implementations, the determination can be made by calculating a correlation score for the user’s song selection(s) in relation to the jukebox play queue at the time of each selection. The correlation score may be a measure of how the user selection(s) are consistent with one or more of the genre, artist, beat, instruments, mood, etc. of other songs in the play queue at each instant in time. In some implementations, the live reactions from other patrons of the venue, for example, as expressed by individual patrons by pressing a like button or the like that is associated with the currently playing song being displayed on each patron’s mobile device, can be used as a factor in the correlation score. In yet other implementations, such live reactions of other patrons to the user’s song selections can be used as a third criteria. The system may use any one or more of the criteria to select users who are to be invited to take a DJ role for the current venue. Yet another criteria for determining whether to invite a user to take a DJ role may be the number of users who are designated in the DJ role that are currently at the venue. The total number of users with DJ role designation concurrently present at the venue may be restricted in order to ensure that each designated DJ has reasonable access to the play queue, while also ensuring that patrons can individually directly submit song requests to the play queue. The proposal to the user can be made by initiating a popup message on the mobile device.

[0068] The DJ status (role) enables extra capabilities for music play such as receiving play credits from other patrons (e.g., by transferring credits from the entertainment wallet 109 of another patron to the entertainment wallet 109 of the DJ), and selecting and playing songs for them, receiving song and genre requests, arbitrating between multiple requests and even additional queue visibility and manipulation.

[0069] For example, as noted above, the DJ role may enable one or more screens for a user with that role to perform such actions such as, for example: select songs, playlists, genres, and/or artists; receive play credits from other patrons, and select/play songs for them; receive song and genre requests; arbitrate between multiple requests; have additional queue visibility and manipulation; and/or control or request configuration of other vibe/mood setting features (e.g., a jukebox device’s lighting arrangements, displayed imagery and/or advertisements etc.) for the venue. The system may be configured to enable patrons having the DJ role to have privileges to override and/or delay at least some song requests queued for playing on the venue’s jukebox device(s), to maintain a DJ-specific song/genre request queue that is separate from the jukebox device’s play queue and from which requests (e.g., song requests submitted to the DJ by other patrons) are selected by the DJ as requests for the jukebox device’s play queue.

[0070] In an implementation, when a user is designated in the DJ role, the system may configure data structures on the servers 102 so that the designated DJ can initialize a temporary DJ song queue with one or more songs. The designated DJ may then transmit a message to other patrons at the venue, a description of the DJ song queue, and the patrons can be enabled submit song requests to the DJ song queue. The designated DJ may accept or deny such requests. When a song request is accepted and the DJ song queue is updated by adding the accepted song and a predetermined amount of credits is transferred from the requesting user’ s entertainment wallet to the designated DJ’s entertainment wallet. The designated DJ may submit the songs in the DJ song queue to the jukebox play queue one at a time, multiple at a time, or all at once.

[0071] As a benefit offered to the DJ role, the jukebox may implement a discounted credit amount for each song request from the DJ, may guarantee playing a series of requested songs in a consecutive series, and may offer extended visibility to the jukebox play queue so that the DJ can better plan his or her song requests.

[0072] In addition to the DJ role, individuals can have other roles that would enable unique features that make them better able to influence outings, ongoing music or game play, tournaments, and challenges. Examples of personas provided in some embodiments include: The Planner -gets DJ and vibe-setter to entertainment venue; The reliable - a jukebox user’s biggest ally because of reliability to attend event; The DJ - true music lover; and The Vibe-Setter - centered on making around them comfortable and happy. Each of the above personas may be a system defined “role” that is selectable by a uscr/patron upon the onboarding process, and/or when checking in to a venue or jukebox device(s) at the venue. As described in relation to the DJ role, each role may have a particular set of capabilities that are enabled by the system for users who are assigned that role. In a similar manner, for other roles too, patrons may be provided with unique sets of capabilities to control one or more aspects of the jukebox device at a venue and optionally other electronic game devices connected to the jukebox device(s) or the system. [0073] Jukeboxes load music into a queue that is susceptible to a variety of queue prioritization changes, mechanical failure and even venue staff (e.g., bartender) intervention, all of which could cause or unfairly delay the playing of a song. Existing jukeboxes lack a system that establishes accountability for the music system and offers play certainty or a refund. Some embodiments of the present disclosure provide such a guarantee. The guarantee may be provided to all users or only to a selected set of patrons. For example, and without limitation, the guarantee may be provided based on a patron’s subscription level, roles, frequency of attendance at the venue and/or other venues of the system, or the amount (e.g., in credits) paid for the song. [0074] In addition, many songs are played but because of delay or distraction, the patron is unaware of the contract being fulfilled. A system that advises and/or reports on pending play and successful completion would assure patrons to have confidence in their requested music being played on the jukebox. The presence of a music play guarantee improves the play experience for mobile app users and enable providing a guaranteed play (e.g., a “you pay, we play”) feature to patrons. For example and without limitation, queued songs for which the guarantee applies may be associated with a maximum allowable delay and the system may, in addition to ensuring that those songs will remain in the queue despite incoming requests from patrons or DJs, also control the queue to ensure that they are played with a delay less than the associated maximum allowable delay.

[0075] FIG. 4A illustrates an example display that provides a user with more visibility into the queue, and FIG. 4B illustrates an example display that provides more visibility as to what has already played so that the user can verify his/her selections have been played. The screen 401 shown in FIG. 4A may be displayed when the patron views the current play queue and selects an enqueued request such as, for example, the Song 3 of Artist 3 shown on screen 402. Screen 402 shows the amount of music credit 403, an image 404 representing the song, the song name 405, the artist name 406, and version/license information 407. Screen 402 additionally shows actions 408 (upgrade actions) available for the patron to promote the selected song in the queue. The illustrated action options 408 include an option to play the selected song next, and option to play the selected song within 30 minutes, and an option to play the selected song within 60 minutes. The patron is provided with the particular amounts of credits that would cost for each promotion option. The selected option may be highlighted. Additionally, a confirmation button 410 may be displayed with the selected option and/or the cost of the selected option may be clearly shown on the confirmation button to ensure that the patron is fully informed of the selected action and the associated cost.

[0076] In some embodiments, the central server system 102 determines the upgrade actions that are available and therefore can be presented to a particular user and communicates that information to the particular user’s entertainment app. More specifically, in order to guarantee play within a predetermined maximum delay for a particular song request, the server system may control the number of new song upgrades accepted to the queue. This number may be determined based on the remaining time of the predetermined maximum delay for the particular song and further based upon other queued song requests that have less time remaining on their respective maximum delay commitments. Thus, the central server system may periodically communicate to the entertainment apps, or the entertainment apps may query the central server system 102, regarding the upgrade options that can be presented to the user. For example, in some instances, the upgrade to “play next” may be unavailable, but “play in the next 60 minutes” may be available.

[0077] FIG. 4B shows a screen 412 that enables a patron to view the jukebox queue and the status of his/her requests on the mobile app. Screen 412 displays the patron’s recently played songs 413 and the patron’s upcoming song requests 414 that are still in the play queue. The patron can scroll the list up/down in order to view the entire history for his/her song requests for the present visit to the venue. Screen 412 may be dynamically updated as enqueued songs are played on the jukebox.

[0078] There have been many rewards systems in place on jukeboxes to incent reuse of the system by offering credits that reduce the future cost of song play to patrons. The idea is to provide some music credit that will entice a patron to use the mobile application to interact with the systems or approach the jukebox and ideally consume more than the reward system. [0079] There is a need to provide for spontaneous rewards for users who are using the system to improve the experience and promote recommendations to other patrons. This gamification of the interaction based on music, artist, time, venue, and a variety of other factors can make the process of selecting music, searching for music or commenting on music more fun and inspire repeated usage.

[0080] The award of a benefit could also be an opportunity to announce to others in the venue or are considering going to the venue of the award.

[0081] The system may, for example, be configured to continuously or at intervals monitor the current vibe/mood and patron engagement level at a venue according to certain predetermined criteria. When such criteria indicates that the vibe/mood and/or patron engagement may benefit from improvement, in response, the system may choose a bonus or benefit to be offered. For example, a patron who requested one of the last few played songs may be offered the bonus or benefit by announcing on the display and/speakers of the jukebox device and/or by transmitting a message to the patron’s mobile handheld device.

[0082] Venues may participate in a variety of cross location gameplay. Trivia games, card nights, shuffleboard, 50/50 draws, door prizes, “chase-the-ace” charity pools, video and arcade best score nights, pool and snooker nights, dart games and dart leagues all may require some form of individual monetary contribution. For card games perhaps this is an ante, for pool it can be a placeholder and for darts it can be entry into a particular league game or tournament. However, there is a benefit to the venues who are hosting these events, individually and collectively, to maintain a common reinforcing participation incentive.

[0083] Some embodiments take advantage of an opportunity to provide the equivalent of a night out or fun currency that eases the participation music play, and in gameplay and eliminates the need for cash or coins, while providing incentives to the participant, potential benefits to the participant’ s group or team, and a digital revenue pool that can be shared between the hosting venue stakeholders, league or tournament organizers and other ecosystem suppliers.

[0084] According to some embodiments individual patrons may each possess a digital entertainment wallet (e.g., entertainment wallet 109) on the system which could contain currency and credits as well as digital tickets or coupons for participation in ecosystem events.

[0085] According to some embodiments the system may be configured to control jukebox devices and/or other electronic game devices across several venues to conduct activities (e.g., such those mentioned above), or enable patrons at multiple venues to participate in such activities conducted at one venue. In yet other embodiments patrons may participate in such activities without being at, or checking into, another location with a jukebox device in the integrated entertainment system. According to some embodiments, although the activity may take place at one venue, the system may control jukebox devices etc. at other venues at which participating patrons are present and/or participating patrons’ mobile handheld devices to inform and/or engage patrons who are not at the one venue.

[0086] FIGs. 5A-5D show an example of an entertainment wallet (e.g., entertainment wallet 109) being used in a scenario such as that described above in some embodiments. FIGs. 5A and 5B show that a particular venue (Place 3 Tavern) 504 at which the user is present has music, darts and bil 1 iards in which the user can participate using the credits available (e.g., shown top right). The pay-for-play entertainment actions available at the current venue are shown as separate tabs (e.g., music 505, darts 506, billiards 507) on screen 502. In some implementations, each of the darts games and billiards games can be engaged in by the user by simply scanning a QR code next to the dart board/billiards table. The credit available 503 is shown at the top right of screen 502. Other functions of the mobile app may be navigated to by using any of the options displayed on a navigation area 510 on the screen.

[0087] FIG. 5A shows the darts 506 tab, listing the darts options 509 that are available to the patron. For each darts game available at the venue, an identifier 511 for the game. The current waiting line status to play the game 512, and a confirmation button 513 may be shown. In the first available dart game, BullShooter #1, the status 512 of the waiting line indicates that there is no waiting line and the patron can play now. In the event that the game is available immediately for the patron’s possible use, the conform button 513 may be selected to scan a QR code that may be attached on or near the dart game. Scanning the QR code may automatically bring up the option for the user to pay for the game and to start the game upon successful payment. The waiting line status for that game is then updated so that all patrons are informed of the current status. As shown on screen 502, the second dart game, BullShooter #2, is shown with an indication of the waiting line is non-empty (e.g., that someone is using the dart game at present) and an option for the user to choose to be notified when the game becomes available. FIG. 5B shows screen 514 that may be displayed when the patron selects the billiards tab 507 on screen 502. FIG. 5D shows an example of presenting the user with an opportunity to participate in any of several darts leagues. Such information as to the real time availability of dynamically formed leagues may be determined by the system based only on local information at the current venue of the patron and/or based on multiple venues. The available options can be displayed on a popup screen 522 that is displayed on the screen 520 when the user selects an appropriate tab for a sport, For example, when the patron selects the darts 506 tab, the popup display 522 may be overlaid on screen 502 (shown in FIG. 5A) to provide the patron with the opportunity to play individual dart games that are locally available at the venue, or group games that may include participants from multiple venues as well as group games at the current venue. Alternatively, FIG. 5C shows an example screen 515 of music selections that can be made by the user for song play on the venue’s jukebox device(s). Screen 515 may be displayed when the music tab 505 is selected. Screen 515 provides a search input area 516 where the patron can input song names, album names, and/or artist names, etc. to search for available music. Screen 515 may also display the currently determined top songs 518 and the currently determined top artists 519. [0088] In some embodiments, a group party capability provides a collection of features that together facilitate, encourage, and support group curation of the music of the moment. The capability supports people coming together to connect over a shared music experience. This feature may have properties such as: social/public; shared control; focused on about how the song makes everyone feel; and optimized for a specific moment in time in a specific place with a specific group of people. The feature provides an ability for a group of patrons to share and see the queue characterized by music features by number of supporters and a variety of other perspectives all of which combine to diffuse the act of promoting a single song and to encourage individuals whose song choices may not have been embraced by the rest of the group to continue to offer their suggestions.

[0089] This constant and, in some embodiments, real-time, balancing of individuals desires and group collective with the focus on participation represents a significant change from the existing jukebox state of the art where queues are either arbitrary or are exposed simply as song titles. The addition of musicology information and rich facts about the song to the queue may affect the musical momentum in the location, and may create a true sense of musical participation in the moment.

[0090] A variety of functional instruments are included: shared credits (e.g., the center image in FIG. 6), music dedications group plays (e.g., the left image in FIG. 6), and creative use of polling will enhance the shared music experience (e.g., the right image in FIG. 6). Dedications associated with the song that is being currently played can be displayed on the screen (e.g., screen 604) of the jukebox device(s) at the venue and may display profile pictures of the requester and the patron dedicated to. A screen similar to screen 604 may be displayed on the mobile app for the donee and/or donor, and may additionally be viewable for other patrons who choose to view details of the currently playing song.

[0091] When a donor patron seeks to share one or more credits, digital tokens, coupons, etc. (e.g., from a digital entertainment wallet as described above) with a donee patron, a message may be displayed on the donee patron’s mobile handheld device informing of the sharing and enabling the donee to accept or decline the share. Screen 602, for example, enable the donor patron view and/or choose another patron at the current venue or another venue, and to send some amount of credits to that other patron.

[0092] Requests for group play inputs, such as that shown on the screen 606, can be shown on the mobile handheld device of patrons at the venue to display the polls with selectable choices and with the current statistics associated with the respective choices being displayed real-time.

[0093] There often are great moments or stretches of time in a location that are memorable and represent a playlist that would be fun to play again. Music replay feature according to some embodiments allows a patron to recall a time from a venue and see the playlist for a previous time. Playlists can be recalled by selecting a location and date/time. FIG. 7 schematically illustrates some embodiments that may assist users in a group at a particular venue to remember the vibe at the venue by presenting the user with key moments of the evening and allowing the users to create a shareable artifact that users in the group can save to help in later recalling the venue’s vibe, playlists etc. Then the playlist can be trimmed by the patron and submitted as a proposed playlist for the current location of the patron, or simply queued.

[0094] Venues may selectively enter music replay mode, thereby allowing patrons to then join the play group. For example, the system may determine, based on user profiles of patrons at a particular venue and optionally one or more other factors such as the vibe of the venue, that the venue has a sufficient number of patrons that have saved replay artifacts from previous visits and may in response prompt the venue staff and/or jukebox device(s) to initiate a music replay period to encourage crowd participation. [0095] Upon a signal from the venue staff or automatically from a jukebox at the venue when prompted by the central server system, for example, when the venue’s jukebox queue is not highly populated and/or no guaranteed play requests are currently enqueued, one or more users who are determined to have saved replay artifacts may be invited to replay one or the replay artifacts on the jukebox. It should be noted that, before a replay artifact is queued to be played, the central server system and/or the jukebox should ensure that the replay does not interfere with any guaranteed play commitments. This is particularly relevant since replay artifacts may consist of more than one song request.

[0096] Crowd reactions are an exciting way to gamify the play of music. Crowd support of songs in the queue or those that are playing allow patrons to be more involved in the music even if they themselves have not requested/played or selected the songs.

[0097] In some embodiments, users can support a song through vote tokens. Vote tokens can be distributed to users based on a variety of criteria, including, for example, song plays, app usage, participation in games or promotions, purchased credits, and patron rewards, and their distribution can be managed to keep participation fair and fun. The visibility of a song battle within the app, on connected TV screens, and the Jukebox display can give others the incentive to participate in the battle and to perhaps play or promote a song themselves. A song battle may be initiated at various stages in the playing of songs. For example, crowd reactions to currently playing songs can be used to rank the songs played during a particular period in terms of popularity, crowd reactions to songs in the queue can be used as a factor in determining a song’s place in the queue or how fast a song advances in the queue, and/or crowd reactions to two or more songs can be used to determine which of the two or more songs are selected to be submitted to the play queue or to a playlist. Song battles can be displayed in real-time within the entertainment app for users, on connected TV screens at the venue, and the Jukebox display.

[0098] In addition, it is interesting and engaging for individuals to characterize the song with reactions that can include icons, emojis, phrases from popular culture and text that is entered on their respective handheld devices. All of such characterizations may serve to further classify the song and can be stored by the system as counterpoint to the other song or songs in the battle. This is an instrument to crowd source new meta-data on a song, and in aggregate for the location. [0099] Crowd reactions to songs played can also be an important data set when analyzing the venue and ranking venues for an individual or group who is/arc planning an outing.

[00100] FIG. 8A shows an example crowd reaction (e.g., characterized by heart emojis) to a currently playing song. Screen 802 shows a graphic 804 of the currently playing song and its associated information (e.g., song name, artist). Screen 802 also shows the requester 803 of the song as “Person 7”. The patron is able to select the like button 807 to express his/her positive sentiment for the currently playing song. The patron may view the positive sentiments flowing in from other patrons by emojis 806 displayed flowing on the screen. The overall current sentiment for the song can be displayed in a status or engagement score indicator 805. The system may calculate the engagement score based on historical data, such as, for example, the popularity of songs played at the same venue in the presence of a similar crowd size. FIG. 8B shows such reactions in real-time as they come in, on the jukebox screen 812. The current total number of likes 813 received may be displayed in association with a graphic (e.g., heart emoji) 814 that indicates the sentiment. In some embodiments, based on the crowd reaction drawn by a song being played, the requester of the song may be awarded a bonus or benefit (e.g., a free token to advance one song to “play next”) by the system, and the user may be notified of the award by a popup message on the user’s entertainment app.

[00101] FIGs. 9 and 10 illustrate mini-players displayed on users’ handheld devices that enable each user to have more visibility into the play queue at a venue, whose requests are in the queue, when your own song request will play, and full visibility to the queue. FIG. 9, for example, shows mini-player 902 at one point in time, overlaid on the mobile app display, showing that the patron’s selected song “Song 17” by has 5 more songs in the queue before it. Mini-player 904 shows another instant in time where the patron is notified that the selected song will play shortly, in a certain number of minutes.

[00102] FIG. 10 shows the screen when the selected song is being played. The screen may also display other details about the queue such as recently played songs, total number of songs played in the session, number of songs in the queue, etc. These features improve the social feel at a venue.

[00103] In some embodiments, the accumulated plays of a venue together is considered to reflect the music affinity of patrons at that venue. The patterns of music play, the mix of genres and the time of popularity creates a musical characterization, or as referred herein a “music DNA” of a location. The same analysis may be made on a user by examining their play and venue history. This will allow venues to be ranked for a specific user as their likelihood of a music match.

[00104] Another method of determining the music DNA of a location according to some embodiments is to combine the musical tastes of patrons who frequent the location. The individual music tastes of patrons when combined with their dwell times in the location provides a powerful extrapolation of the vibe in a location. This can be highly important as patrons may infrequently play music when compared to the number of times and duration that they are physically within a location. Another possible weighting method used in some embodiments considers the timeslots that patrons are in the location allowing for a popularity index to calculate the likelihood of a good crowd.

[00105] A further extension of this music matching is to allow a group of friends to blend their collective music DNA and consider venues that are most likely to match their musical tastes. For example, according to some embodiments, a user can use the entertainment app to input some initial data such as, for example, the projected group of patrons, a geographic area, date and time, and optionally one or more genre or other preference, and the system may calculate a collective music DNA for the projected group and determine one or more venues to be suggested based on matching the venues’ music DNA (optionally for particular dates and times) and the group’s collective music DNA.

[00106] In some embodiments, the music DNA of a venue can also include participation in other activities such as playing pool, darts, shuffleboard, trivia, card games or Karaoke. The availability of these other pastimes adds to the venue’s music DNA, and can be used to match against a user’s known behaviors and preferences. For example, the system may maintain, for each user, historical information on the use of electronic game devices that are available at venues and that are connectable to the jukebox devices at the venues.

[00107] In some embodiments, the music DNA of an entity is implemented as a multidimensional vector in which each dimension is a property of the entity such as, for example, the entity’s propensity to play songs of a particular genre, propensity to play songs of a particular time period, the entity’s propensity to play songs of a particular artist, musical engagement during a particular time of day, etc. Each dimension may be assigned a corresponding normalized score for the entity. With the increase in the number of dimensions, the granularity and representative accuracy of the entity’s music DNA may improve. In such implementations, matches between entities (c.g., between users, between users and venues) can be determined by the distance, in multidimensional space, between the music DNA of the respective entities. Some implementations may bias the matches towards to desired properties by weighting some dimensions differently from others.

[00108] In some embodiments artificial intelligence-powered home pages (or as landing pages) can be provided to users where various choices (e.g., preferred music content types, preferred categories/genres, etc.) can be presented using behavioral profile-based widget soiling. Additionally, real-time sorting of song, artist, and playlist recommendations (e.g., using the behavior of the user, other users at the venue, similar users, and venue (and venue staff)) can be used for improved and personalized recommendations to users on their handheld devices, and to support the user in decision making. For example, in implementations in which a patron’s home page upon starting the entertainment app displays one or more of a set of artists, set of songs, set of playlists, set of genres, etc., the real-time behavioral profile-based widget sorting can be used to arrange the ordering of those widgets in accordance with the most current behavioral patterns of that patron. In some other implementations, in addition to the patron’s behavior patterns and profile, the behavior patterns and profiles of other users at the venue, members of the venue staff, and users with similar tastes to the patron, can be considered in generating the recommendations and/or ordering of the recommendations for the patron’s landing screen.

[00109] This real-time sorting can also be useful in announcing key moments during an evening (e.g., FIG. 11 announcing “last call” 1104 on user’s home screens 1102) and announcing relevant information regarding a user’s friends/contacts or persons of interest at the venue (e.g., announcing checking in of persons of interest at the same venue). For example, another use of the real-time sorting may be, when a patron with certain known music tastes checks in to the venue, some other users/patrons may be alerted on their respective entertainment apps that a person with such known music tastes have checked in and provide them with the ability to submit requests to play songs in consideration of that patron. For example, when patron A checks in to a particular venue and the system discerns from patron A’s profile and/or music selection history that patron A is a fan of the artist Rihanna, the system may popup windows on the mobile devices of some patrons or other users (e.g., patrons in a DJ role, venue staff, etc.) to provide them with the opportunity to submit songs for that fan of Rihanna by, for example, presenting those patrons or other users with music recommendations for songs by Rihanna or other artist that arc often associated with Rihanna.

[00110] Some embodiments consider the music DNA of patrons and the characteristics of venues to propose venues as best matches for a particular patron. The characteristics considered for a venue may include the music DNA of the venue, other activity options (e.g., pool, darts, shuffleboard, trivia, card games or Karaoke) at the venue, location popularity at the venue, dwell times at the venue and other venue data such as those obtained from social media sites, crowd sourcing, venue online presence and data gathered from other users with the entertainment app. Recommendations based on effective best-match considerations may be helpful to an individual who is planning a night out, or for several individuals to share in an outing plan. For example, when the user is shown a list of potential venues to be visited, rather than arranging them simply in the order of increasing distance, some embodiments may additionally consider the level of match between the user’s music DNA and that of the respective venues.

[00111] The ability for the system to observe the aggregate groups of people and their individual recommendations enables the system to detect momentum of people and anticipate the popularity of location in the future.

[00112] According to some embodiments, the evening planning (or outing planning) feature is an opportunity for venues to offer promotions and incentives to potential patrons through the entertainment app and for that to be a criterion for promoting a location. In addition, in some embodiments, this is an opportunity for venues to pay the music app provider to have their venue promoted in ranking.

[00113] For example, in an embodiment, the user may use the entertainment app to stall the outing planning process by selecting one or more of the user’s friends to be invited for the outing. The backend processing logic of the entertainment app may then create the outing group with the members as selected by the user and provide each member with the ability to share music recommendations, playlist recommendations etc. with the other members. The members may be enabled to add songs to and remove songs from a collaboratively constructed playlist among the members, and may also individually vote on each song in the playlist to express their respective preferences.

[00114] The entertainment app may also enable the members of the outing group to collaboratively make an informed decision on where to go for the outing. FIG. 12 illustrates example displays that can be presented to the user in some embodiments to enable a group to gather at a particular venue. Location recommendations may be based on location vibe and group mood considerations. The location vibe can be based on crowd-sourced poll questions (e.g., to receive real-time user feedback) at respective venues to have real-time determinations of a venue’s vibe/mood. The outing group members’ mood can be similarly determined by real-time polling. In some embodiments, the venue vibe can be determined based on the venue’s location DNA discussed above, in such cases, the venue recommendations can be based on matching the location DNA of respective venues to the music DNA of the members of the group. FIG. 12 on the left shows a listing of venues ordered according to how well they match the outing group. In the illustrated example, each member of the group can select a preferred venue and the finally determined venue, in the illustrated event the Juno Bar, is the venue that receives the most members’ preference. In some implementations, the system may generate an entire itinerary of multiple venues for the evening. The right side of FIG. 12 shows an example three venue itinerary ordered in the order of the preferences, and optionally other considerations as the geographic locations of the respective venues and various venue- specific factors, can be provided to the members of the group.

[00115] The outing feature may include other features, such as, for example, the members in the outing group being notified on their entertainment apps of other group member arrivals at the venue, a facility in some embodiments for the group members to request the venue jukebox device(s) to play an entrance song for the group at a particular time, are some such additional features.

[00116] In order to increase the revenue that a jukebox generates, making the most desired or popular songs available on the jukebox over time may be seen as an advantage. If customers cannot find songs they like on the jukebox, usage of the jukebox (and the revenue generated thereby) can decrease. Efficient music selection option presentation and music discovery can be challenging. Particularly, when the users of the entertainment app would typically use a smartphone or other handheld device (e.g., instead of the larger jukebox screen, etc.) to select the music, presenting the vast range of music choices available so that the user is able to find a song for any time, mood or location in an efficient manner becomes a challenge. If the user is compelled by the design to search through a large number of pages or screens, the user may get frustrated in the effort. One embodiment presents music in a 3D form with icons representing music choices. The icons could be album covers, images of the artist or other emblematic photos. The music may be be organized chronologically along the Z axis with the opportunity to divide genres horizontally along the z-axis. The idea, according to some embodiments, being that by scrolling upwards the viewing window would present popular music options within the current genre by time of their release period and in addition, along with the popular music choices would be facts about music and popular culture that occurred in the time span. Rather than an absolute directory (e.g., a directory selected from an available catalog according to preconfigured criteria) the music discovery would present iconic or popular songs from the era that are network-wide or are tailored to the music DNA of a location. In some embodiments, the music DNA of the location may automatically evolve and change over time in accordance with the crowd in attendance at the location and their participation. In some embodiments, the system may automatically and in real-time determine the location’s music DNA based on the current queue of songs and may adapt the songs presented at the location for 3D music discovery. The interactive imagery being presented to inspire a patron to explore that artist, album, or song. A variety of visual treatments can orient the viewer into a particular genre or era. For example: pop songs in the center, moving left would cross over into country and moving right could move into rock. The displayed choices of genres, eras, etc. may be selected and/or ordered in accordance with the particular patron’s historical selections of music and/or venues. FIGs. 13A-13B illustrate example presentation screens according to some embodiments. In the examples screens, while the music is ordered in time-period in the z-direction, the genres are arranged in the x- direction. The y-direction may be ordered according to artist, or provide alphabetical ordering. This screen layout enables the user to engage in music discovery using a dynamic directory of music that evolves in accordance with the changing of the music DNA of the particular venue and/or the system of venues.

[00117] As also noted above, in some embodiments a more dynamic queue with different visibility perspectives provides additional motivations to a venue’s patrons for participation. Attributes such as time, genre, band density, short term “blue light specials” and a variety of other time-based incentives can illicit interest and contribution from a potentially passive audience. To improve patron engagement, some embodiments provide for dynamically adapting the cost for a song to be played in accordance with the demand at a particular time, and/or display a countdown timer next indicating the time at which the patron’s requested song will play. Information such as dynamically changing amount of credits for requested songs, and the countdown timer may be displayed on the patron’s handheld device.

[00118] According to some embodiments, the entertainment app enables a user planning an evening to quickly join a group of other users (e.g., nearby users, contacts, etc.) and pick a fun username. The entertainment app may then present the user with options for other entertainment app users to follow and provide playlist/song recommendations. For example, a screen may be displayed that, for a selected venue, shows a row of icons for respective other users to follow and second row of recommended playlists. Thereafter, taking into consideration any follows etc., the system may present the user with suggestions for song choices. The user may view more detailed information about songs (e.g., artist, song title, version, number of likes, a level of match with the user and/or group, popularity, lyrics, etc.) before selecting a song to submit to the play queue. Choices may be presented along with the amount of credit required for each selection. In some embodiments, the user may be provided with visibility to queue details, such as by showing the queued songs and the requesters, crowd reactions to songs, etc. The user may select a request already in the queue (e.g., a request by another user), and add credit to that song request so that it can be advanced in playing order in the queue (FIG. 14A, “Fast pass”). The fast pass feature gamifies the play queue and enables users to participate in the action at a lower cost. The user can at any time participate in the crowd reactions to the song currently being played by using a selected emoji to express his/her feelings about the song, and such expressions are displayed in real-time (FIG. 14B). The user may also assist another user make selections by participating in real-time polls (FIG. 14C). The poll may show the popularity of each choice in real-time as other users vote on the poll. User engagement improving means such as trivia quizzes and the like can be presented by the system to the user (FIG. 14D), and a leaderboard or the like can be displayed on user devices and/or connected display devices at the venue. The content and the timings of trivia quizzes etc. can be controlled by the system at the central servers and/or by the bar staff at the venue to be presented to users at optimal times considering both the mood at the venue (e.g., determined in accordance with the collective music choices at the venue, crowd characteristics, etc.) and the individual user’s mood (e.g., determined based on the user’s music selections and venue choices). At the end of the evening the system may generate one or more images (e.g., primarily screen captures of the user’s handheld device with the entertainment app running in the foreground) and present to the user (e.g., similar to as described in relation to FIG. 7). The user may share one or more of the images with others in the group and/or may save one or more of the images along with the user’s playlist choices during the evening for later replay (e.g., music replay) at any venue.

[00119] Song listings displayed on the user’s handheld device can be annotated with user reactions to the songs. FIG. 15 shows reactions being added to song listings of songs recently played. The reactions may be indicated by the various emojis 1504 received and a total of reactions 1507 for each of several recently played songs displayed on screen 1502. In some embodiments, the listing on screen 1502 of the handheld device of a patron is a listing of the patron’s song requests that have been played.

[00120] FIG. 16 illustrates a screen enabling the patron to share a recap of the reactions to song selections. For example, screen 1602 is a recap of the patron’s song request in terms of the user reactions it received, its popularity compared to the other songs played at the venue in the same session, and compared to another time period (e.g., all time) for the venue. A share button (e.g., shown at the top of screen 1602) enables the patron to quickly share the recap shown on screen 1602 with selected other users.

[00121] FIG. 17 shows an example screen 1702 that provides music genre filters that enable surfacing venues’ top music genres and lets users filter the map and places list to find locations matching their preferences. A pulldown list may list a plurality of nearby venues, for example, in the order of distance from the user. The listed locations may be displayed in a map 1704 of the area. The pulldown list may be filtered using a filter 1706. In the illustration, a filter 1706 of music genres is shown. As shown, the filter is set to select venues that at least have categorized as having the electronic genre and rock genre. Each venue on the list can be shown with the distance, the top genres, and the song that is currently playing. Other filters and/or other filter criteria can be used instead or in addition to the genre filter shown.

[00122] In some embodiments, the venues may provide a live feed that can be received by the entertainment app on users’ handheld devices. The venue’s live feed may be received by the entertainment app via the central server system. FIG. 18 shows a live social feed that displays on screen 1802 a feed of activities and interactions happening at the venue and within groups. Including showing other checked-in users 1804, live polls 1806, dedications, trivia 1808, etc.

[00123] FIG. 19 shows screens 1902 and 1912 that are examples of collaborative playlists where users can collaborate with friends to curate playlists. Screen 1902 shows the construction of the collaborative playlist being started by a first user among a group of users. Screen 1912 shows a second user from the group adding a song to the playlist, and group members voting for or against the added song. The percentage of the group members voting and the vote distribution may be shown in real-time. The screens may also show the level of user reactions among the group members for the playlist being constructed (shown at the bottom right in screens 1902 and 1912). A share button may be provided to facilitate sharing of the collaborative playlist.

[00124] In some embodiments, dynamic pricing having peak and discount values for regular' plays are implemented. The dynamic pricing may incorporate credit fractionalization. This may allow cost-conscious users to play songs at a discount while enabling the venue to maximize revenue during peak times. The system may determine peak and non-peak times on a per venue basis based on the number of users checking in and/or the frequency of song requests received. The pricing may be based on a measure of the venue’s current propensity to spend, that can be calculated by the system periodically or continuously in real-time during certain periods. The venue’s propensity to spend may be determined based on one or more of the historical behavior of same day and time period revenue from jukeboxes and/or other connected game devices, individual patrons’ current spending behavior and historical spending behavior, number of patrons at the venue, and other factors such as whether or not certain events are ongoing at the venue. In some embodiments, machine learning is used to continuously reconfigure the pricing to maximize revenue during certain periods.

[00125] Song upgrade features (e.g., the “fast pass”, play within a fixed delay, etc. discussed above) allows a patron to upgrade their song, or another patron’s song, from regular to fast pass. The requestor of the song is notified about the queue position change. This allows users to get their (or other patrons’) songs played faster, improving engagement.

[00126] According to an embodiment, an integrated entertainment system comprising a digital jukebox device, a game device, a handheld electronic device configured to execute an entertainment app, and a remote server system configured to communicate with the digital jukebox device, the game device, and the entertainment app on the handheld device, are provided. The entertainment app is configured to: in response to a fist input received on the handheld electronic device, submit a first play request for a song on the digital jukebox device, wherein the submitting the first play request includes providing a first requested payment; and in response to a second input received on the handheld electronic device, submit a second play request for a game to the game device, wherein the submitting the second play request includes providing a second requested payment. The first requested payment and the second requested payment may be provided in a first type of credits and a second type of credits, respectively, and the first type of credits and the second type of credits are different. The first requested payment and the second requested payment may be provided from the same digital wallet.

[00127] The entertainment app may be further configured to: in response to a third input received on the handheld electronic device, submit a third play request for a song on the digital jukebox device, wherein the submitting the third play request includes providing a third requested payment in the first type of credits, wherein the providing the third requested payment in the first type of credits comprises automatically converting one or more credits of the second type of credits to the first type of credits. Before performing the automatically converting, the one or more credits of the second type of credits may be credited to a digital wallet in response to the game on the game device.

[00128] The entertainment app may be one app. The digital jukebox device and the game device may be pay-for-play devices. The digital jukebox device and the game device each may include a respective payment device. The digital jukebox device and the game device may be in the same venue, and wherein the entertainment app may be further configured to, before submitting the first payment and the second payment, check into the same venue.

[00129] FIG. 20 shows a flowchart 2000 of an example entertainment app (e.g., entertainment app 107) process, according to some embodiments.

[00130] The process of flowchart 2000 may begin at 2002. At 2002, in response to a fist input received on the handheld electronic device, the entertainment app submits a first play request for a song on a digital jukebox device, wherein the submitting the first play request includes providing a first requested payment.

[00131] At 2004, in response to a second input received on the handheld electronic device, the entertainment app submits a second play request for a game to a game device, wherein the submitting the second play request includes providing a second requested payment. The digital jukebox device, the game device, and the entertainment app on the handheld device, all communicate with a remote server system.

[00132] The first requested payment and the second requested payment may be provided in a first type of credits and a second type of credits, respectively, and the first type of credits and the second type of credits are different. The first requested payment and the second requested payment arc provided from the same digital wallet.

[00133] The entertainment app may be further configured to: in response to a third input received on the handheld electronic device, submit a third play request for a song on the digital jukebox device, wherein the submitting the third play request includes providing a third requested payment in the first type of credits, wherein the providing the third requested payment in the first type of credits comprises automatically converting one or more credits of the second type of credits to the first type of credits. For example, the jukebox may accept only jukebox credits and the game device may accept only game credits. The automatic conversion may include converting from the jukebox credits to the game credits or vice versa. Before performing the automatically converting, the one or more credits of the second type of credits may be credited to a digital wallet in response to the game on the game device.

[00134] The entertainment app may be one app. The digital jukebox device and the game device may be pay-for-play devices. The digital jukebox device and the game device each may include a respective payment device. The digital jukebox device and the game device may be in the same venue, and wherein the entertainment app may be further configured to, before submitting the first payment and the second payment, check into the same venue.

[00135] FIG. 21 shows a flowchart 2100 of a process for the system (e.g., the integrated entertainment system 100) to associate roles to certain users based on user behavior and configure the system to facilitate such user’s assigned role, according to some embodiments. [00136] The process of flowchart 2100 may begin at 2102. At 2102, the system monitors actions of respective users in relation to a digital jukebox device at a venue. In one embodiment, this process may operate to assign the DI role to a user as described above. The monitoring may include monitoring users at the venue based on their song play requests, and interactions with the songs being currently played.

[00137] At 2104, the system determines, based on the monitoring, that the monitored actions of a first user exceeds a threshold. Thresholds for such engagement levels as noted above may be preconfigured. The system may periodically test the high performing users against the thresholds. [00138] At 2106, in response to the determining, the system displays a confirmation button on a handheld electronic device of the first user. When a user is identified as a potential candidate for the DJ role, the system may push an invitation to DJ message to that user’s handheld device.

[00139] At 2108, in response to an input received on the confirmation button, changing one or more privileges for the first user for using the digital jukebox device. When the user accepts the invitation to DJ, the system may configure the user’s data structures to note the change of role, and may configure the system to provide increased privileges to the user, such as, for example, the capability to receive song requests from other users, to build a playlist from received song requests, and to submit to the jukebox. The DJ role is described above. Roles other than DJ are also configurable.

[00140] The process may further include, for one or more song requests in the playlist, transferring a respectively determined amount of credits from a digital wallet of a second user to the digital wallet of the first user. The monitored actions of respective users in relation to the digital jukebox device at the venue may include at least one of requests for songs and interactions with songs played on the jukebox.

[00141] FIG. 22 shows a flowchart 2200 of a process that enables a user to upgrade a song queued for playing on a jukebox, according to some embodiments.

[00142] The process of flowchart 2200 may begin at 2202. At 2202, the system displays, on a handheld electronic device of a first user, a listing of one or more songs in a queue of songs waiting to be played on a digital jukebox device. This may be displayed in response to a request by the first user.

[00143] At 2204, the system receives, on the handheld electronic device, a request to upgrade a song in the queue from a regular play delay category to a lower play delay category. The first user may choose to upgrade his own song request in the queue, or the song request of another user. The upgrade request may be at one of several levels of upgrade. Upgrade of songs may be performed in a manner described above in relation to, for example, FIG. 4A or FIG. 14A.

[00144] At 2206, in response to receiving from the first user a payment corresponding to the request to upgrade, the system controls a configuration of the queue to play the upgraded song, and enables the first user to have increased visibility into the queue. As discussed above, depending on the constraints imposed on the rest of the queue by the first user’s song upgrade request, the system may control the queue to ensure that the upgraded song is played on the jukebox within the agreed constraints. Subsequently, the first user may be provided with enhanced access to the play queue (and recently played songs list) so that the first user can know that the upgrade request was honored.

[00145] FIG. 23 shows a flowchart 2300 of a process by which the system (e.g., the integrated entertainment system 100) encourages user engagement at entertainment venues, according to some embodiments.

[00146] The process of flowchart 2300 may begin at 2302. At 2302, the system monitors actions of users in relation to a digital jukebox device at a venue. The system may, for example, be configured to continuously or at intervals monitor the current vibe/mood and patron engagement level at a venue according to certain predetermined criteria. The patron engagement may be measured based on total song requests, frequency of song requests, reactions to songs being played etc.

[00147] At 2304, the system determines, based on the monitoring, that the monitored actions are below a threshold. For example, predetermined thresholds may be configured for any of a number of song requests, frequency of song requests, reactions, etc. for certain crowd sizes. Thus, the system (e.g., the jukebox and/or the central server system) can determine when the calculated engagement level is below a predetermined threshold.

[00148] At 2306, in response to the determining, the system displays a confirmation button on one or more handheld electronic devices in the venue. The system may select one or more patrons to whom an invitation is sent regarding an award. In one embodiment, the patron with the highest song requests may be invited.

[00149] At 2308, in response to an input received on the confirmation button displayed on one of the handheld electronic devices, the system transfers one or more credits or digital coupons to a digital wallet associated with the one of the handheld electronic devices. If the invited user agrees to accept the award offer, the award (e.g., a number of credits, a digital coupon redeemable for credit, etc.) can be transferred to the entertainment wallet of the user.

[00150] FIG. 24 shows a flowchart of a process 2400 for a system (e.g., the integrated entertainment system 100) to match entertainment venues with patrons, according to some embodiments.

[00151] The process of flowchart 2400 may begin at 2402. At 2402, the system determines respective musical characteristics of each of a plurality of venues, each venue having at least one pay-for-play digital jukebox device. In some embodiments, the respective musical characteristics can be determined as each venue’s music DNA. As described above.

[00152] At 2404, the system determines respective musical characteristics of each of a plurality of persons. In some embodiments, the respective musical characteristics can be determined as each venue’s music DNA. As described above.

[00153] At 2406, based on matching the determined respective musical characteristics of each of a plurality of venues and the determined respective musical characteristics of each of a plurality of persons, the system generates an itinerary comprising two or more of the venues for visiting by the plurality of persons. In some embodiments, the matching may be made by calculating a aggregated music DNA for the plurality of persons, and matching the aggregated music DNA to the music DNA of the respective venues. The best match venue may be the first stop in the itinerary. An example itinerary generation for an evening out for a group of persons was described above in relation to FIG. 12.

[00154] FIG. 25 shows a flowchart 2500 of a process associated with a replay feature in an integrated entertainment system (e.g., integrated entertainment system 100), according to some embodiments.

[00155] The process of flowchart 2500 may begin at 2502. At 2502, the system detects, at a venue, a presence of at least one user having associated stored replay music and a desired condition of a play queue in a digital jukebox device at the venue.

[00156] As described above, a user may generate and store a music replay at the end (or at another point in time) of an evening attended at a venue in the integrated entertainment system 100. The central server system 102, for example, can determine whether any user at a venue has previously stored replay music. This information may be stored in the central server system 102. When the user checks in to a venue, a determination made as to whether or not the user has music replays stored. The central server system may notify the jukebox device of this determination.

[00157] The jukebox device and/or the central server system may also detect time periods when the jukebox’s play queue is able to accommodate a music replay. For example, such a period may be detected when only a few songs enqueued for play, or when there are no enqueued songs that have a play guarantee within a short time. [00158] Thus, the jukebox and/or the central server system can detect a time instant when the queue can accommodate a music replay, and there is at least one user at the venue with a previously stored music replay.

[00159] At 2504, the system prompts, on a handheld electronic device, for the at least one user to confirm use of the stored replay music. For example, this may include pushing a message to the entertainment app running on the user’s handheld device.

[00160] At 2506, responsive to an input on the handheld electronic device, controlling the play queue to play the stored replay music. When the user confirms that the music replay can be played on the jukebox, the stored replay music is loaded to the queue and played. Typically, the music replay would include more than a single song. Therefore, the jukebox and/or the central server system may need to actively control the queue to ensure that any play guarantees are satisfied.

[00161] The above described embodiments are example embodiments of the present disclosure, and do not limit the disclosure. It will be understood that, within the scope of this disclosure, features of the described embodiments can be combined in combinations other than those described above.

[00162] According to certain exemplary embodiments, jukebox devices with user interfaces, and/or systems with such jukebox devices are provided. Similarly, according to certain exemplary embodiments, non-transitory computer readable storage mediums tangibly store programs that, when executed, implement the methods described herein.

[00163] It will be appreciated that the use cases presented herein are provided by way of example and without limitation. Other flowcharts and use cases are possible in connection with different exemplary embodiments, implementations, and/or uses of this invention.

[00164] Certain exemplary embodiments relate to an out-of-home entertainment center comprising at least one digital jukebox device which may be coupled with at least one Internetbased messaging system and/or a social networking site and coupled with a central server system, the central server system being connected to the out of home entertainment center by a wired or wireless local area network or through the Internet. The use of some of the entertainment center services may cause the entertainment center to send messages to at least one Internet-based messaging system. Connecting the system through the Internet may require a user to input a code to the remote device that uniquely identifies the entertainment center. [00165] The present disclosure has used certain terms that should not be interpreted as limiting the invention to a particular embodiment, hardware components and configurations, software configurations, etc. For example, many features and examples have been described in relation to their existence within a bar, pub, or other entertainment environment. However, it will be appreciated that the features present in the exemplary embodiments of the present invention are adaptable for use in any venue where a jukebox (or multiple jukeboxes) may be located. Similarly, while certain features and functions are described with reference to usage by “users,” “owners,” “operators,” “patrons,” etc., it will be appreciated that these terms are generic and may, in most cases, be used interchangeably depending on the embodiment chosen and the feature employed. For example, while it may be advantageous to limit the initial song selection to owners and/or operators, in certain exemplary embodiments, patrons may play a role in the initial song selection.

[00166] Still further, particular hardware combinations and configurations are disclosed that represent only one way in which the embodiments may be constructed. Central server system may, in some exemplary embodiments, comprise one or more servers acting together or separately to coherently provide the full range of services necessary to enable a functioning jukebox. For example, a cluster of servers may comprise a virtual central server, with one server providing media, another tracking membership, another tracking payments and credits, another tracking connected devices, still another processing licensing, etc.

[00167] Also, although the term “song” has been used sometimes in the above-description, this term is not intended to be limiting to the scope of the invention, and any instance or instances of media (e.g., song, video, song/video combination, data, information etc.) can be used in any embodiment herein and still fall within the intended scope of the invention.

[00168] Lastly, it will be appreciated that the screen shots and software arrangements presented herein are only one exemplary method for organizing and displaying the features disclosed herein. Other configurations are possible and are therefore contemplated herein. [00169] 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

WHAT IS CLAIMED IS:

1. An integrated entertainment system, comprising: a digital jukebox device; a game device; a handheld electronic device configured to execute an entertainment app; and a remote server system configured to communicate with the digital jukebox device, the game device, and the entertainment app on the handheld device, wherein the entertainment app is configured to: in response to a fist input received on the handheld electronic device, submit a first play request for a song on the digital jukebox device, wherein the submitting the first play request includes providing a first requested payment; and in response to a second input received on the handheld electronic device, submit a second play request for a game to the game device, wherein the submitting the second play request includes providing a second requested payment.

2. The integrated entertainment system according to claim 1, wherein the first requested payment and the second requested payment are provided in a first type of credits and a second type of credits, respectively, and the first type of credits and the second type of credits are different.

3. The integrated entertainment system according to claim 2, wherein the first requested payment and the second requested payment are provided from a same digital wallet

4. The integrated entertainment system according to claim 2, wherein the entertainment app is further configured to: in response to a third input received on the handheld electronic device, submit a third play request for a song on the digital jukebox device, wherein the submitting the third play request includes providing a third requested payment in the first type of credits, and wherein the providing the third requested payment in the first type of credits comprises automatically converting one or more credits of the second type of credits to the first type of credits.

5. The integrated entertainment system according to claim 4, wherein, before the automatically converting, the one or more credits of the second type of credits are credited to a digital wallet in response to the game on the game device.

6. The integrated entertainment system according to claim 4, wherein at least one of the first requested payment, the second requested payment, or the third requested payment, is determined based on a dynamic pricing calculation based on a characteristic of the venue.

7. The integrated entertainment system according to claim 1, wherein the entertainment app is one app.

8. The integrated entertainment system according to claim 1, wherein the digital jukebox device and the game device are pay-for-play devices.

9. The integrated entertainment system according to claim 8, wherein the digital jukebox device and the game device each includes a respective payment device.

10. The integrated entertainment system according to claim 1, wherein the digital jukebox device and the game device are in a same venue, and wherein the entertainment app is further configured to, before submitting the first payment and the second payment, check into the same venue.

11 . A computer-readable storage medium having stored instractions of an entertainment app that, when executed by a handheld electronic device, causes the handheld electronic device to perform operations comprising: in response to a fist input received on the handheld electronic device, submitting a first play request for a song on a digital jukebox device, wherein the submitting the first play request includes providing a first requested payment; and in response to a second input received on the handheld electronic device, submitting a second play request for a game to a game device, wherein the submitting the second play request includes providing a second requested payment, wherein the digital jukebox device, the game device, and the entertainment app on the handheld device communicate with a remote server system.

12. A method comprising: monitoring actions of respective users in relation to a digital jukebox device at a venue; determining, based on the monitoring, that the monitored actions of a first user exceeds a threshold; in response to the determining, displaying a confirmation button on a handheld electronic device of the first user; and in response to an input received on the confirmation button, changing one or more privileges for the first user for using the digital jukebox device.

13. The method according to claim 12, wherein the one or more privileges includes a capability to assemble a playlist of song requests from a plurality of second users, and to submit the assembled playlist to the digital jukebox device.

14. The method according to claim 13, wherein the method further comprises: for one or more song requests in the playlist, transferring a respectively determined amount of credits from a digital wallet of a second user to the digital wallet of the first user.

1 . The method according to claim 12, wherein the actions of respective users in relation to the digital jukebox device at the venue comprises at least one of requests for songs and interactions with songs played on the jukebox.

16. A method comprising: displaying, on a handheld electronic device of a first user, a listing of one or more songs in a queue of songs waiting to be played on a digital jukebox device; receiving, on the handheld electronic device, a request to upgrade a song in the queue from a regular play delay category to a lower play delay category; in response to receiving from the first user a payment corresponding to the request to upgrade: controlling a configuration of the queue to play the upgraded song; and enabling the first user to have increased visibility into the queue.

17. A method comprising: monitoring actions of users in relation to a digital jukebox device at a venue; determining, based on the monitoring, that the monitored actions are below a threshold; in response to the determining, displaying a confirmation button on one or more handheld electronic devices in the venue; and in response to an input received on the confirmation button displayed on one of the handheld electronic devices, transferring one or more credits or digital coupons to a digital wallet associated with the one of the handheld electronic devices.

18. A method comprising: determining respective musical characteristics of each of a plurality of venues, each venue having at least one pay-for-play digital jukebox device; determining respective musical characteristics of each of a plurality of persons; and based on matching the determined respective musical characteristics of each of a plurality of venues and the determined respective musical characteristics of each of a plurality of persons, generating an itinerary comprising two or more of the venues for visiting by the plurality of persons.

9. A method comprising: detecting, at a venue, a presence of at least one user having associated stored replay music and a desired condition of a play queue in a digital jukebox device at the venue; prompting on a handheld electronic device for the at least one user to confirm use of the stored replay music; and responsive to an input on the handheld electronic device, controlling the play queue to play the stored replay music.