Patent Application
20160134933
Traditionally, jukeboxes were large machines containing a collection of vinyl records or compact discs (CDs) and a record player or CD player to play songs selected by users. Because these jukeboxes were mainly located in public establishments, such as bars and restaurants, routinely updating conventional jukeboxes was a lengthy and cumbersome task, requiring servicemen to travel to each jukebox location to replace outdated recordings with up-to-date records or CDs.
The development of computer systems in jukeboxes provided a major advance in case of music management for jukeboxes because the songs in a jukebox are stored in digital format on a digital memory. Therefore, because jukeboxes no longer require cumbersome records or CDs, jukeboxes may be very small and may be located in a wide variety of public and private locations. Furthermore, jukeboxes are not limited to playing music, but may play songs, videos, and other forms of entertainment (“media content”).
Jukeboxes may be linked to one or more servers, which can optionally be located remotely, to download media content. Accordingly, most types of media content are available over a network at one or more servers of a data center for play by a user, even if the selected media content is not stored locally on the jukebox at the time of selection. More specifically, if the selected media content is not already stored locally on the jukebox, it can be downloaded from the servers over the network. However, due to its comparatively larger size, video content may take a considerably long period of time to download to a local jukebox upon selection by a user. As such, it is advantageous for videos to be readily available for use in a local cache of the jukebox. However, the storage capacity of the cache of a jukebox may only accommodate a finite amount of media content. As such, an administrator of a jukebox must choose which videos and other types of media content to download to the local cache of the jukebox for immediate play upon selection by a user. Such choices may be made based on a current popularity of the media content. However, having a human administrator perform such tasks is time consuming and imprecise. Accordingly, there is a need for a video caching system for automatically downloading the most popular videos to a jukebox's cache.
Systems and methods for managing a plurality of videos associated with one or more of a plurality of communicably coupled jukeboxes over a network, are described. In one embodiment, a first digital jukebox of the plurality of communicably coupled jukeboxes, ranks the plurality of videos according to a predetermined criteria. Based, at least in part, on the ranking, the first digital jukebox determines whether to store a video of the plurality of videos in a temporary cache of the first digital jukebox.
In another embodiment, a first digital jukebox of the plurality of communicably coupled jukeboxes ranks the plurality of videos based at least in part on a local popularity metric associated with each video and a network popularity metric associated with each video. The local popularity metric corresponds to a local play frequency of media content locally on the first digital jukebox. The network popularity metric corresponds to the play frequency of the media content on one or more second digital jukeboxes of the plurality of communicably coupled digital jukeboxes. The media content includes at least one of a song, an artist, and a genre related to each video. Based, at least in part, on the ranking of the video, the first digital jukebox determines whether to store a selected video of the plurality of videos, in a temporary cache of the first digital jukebox.
The foregoing summary, as well as the following detailed description of preferred embodiments of the invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there are shown in the drawings embodiments that are presently preferred. It should be understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown.
Certain terminology is used in the following description for convenience only and is not limiting. The words “right”, “left”, “lower”, and “upper” designate directions in the drawings to which reference is made. The terminology includes the above-listed words, derivatives thereof, and words of similar import. Additionally, the words “a” and “an”, as used in the claims and in the corresponding portions of the specification, mean “at least one.”
The jukebox 10 includes at least one digital memory 11 for storing a plurality of digital music files and information relating to the stored music files. The digital memory 11 can include a hard drive, a collection of hard drives, or any other type of memory capable of storing digital music files (e.g., RAM, DVD-RAM, DVD-RW, CD-RW, memory stick, memory cards (CF, SD, XD), jump drive, mp3 player, personal digital assistant, and cell phone). The digital memory 11 can optionally include a cache 11a and various data stores including a network data store 11b, music data store 11c, and a jukebox catalog data store 11d. The cache 11a and the various data stores, 11b, 11c, 11d may be physically separated or merely designated as separate storage sites. An additional hard drive 11e, known as the content drive, may also reside in the jukebox 10, in which the music video files and associated image files are located.
The jukebox 10 also has a display 21, which may display graphics, such as album covers, videos, or images, and also displays text, such as selection instructions and song titles. The display 21 may be in the form of a touch-screen, such that a user can make his selections by pressing points on the display 21. Alternatively, a user or administrator may enter selections or otherwise interact with the jukebox 10 using a user input device 19, which may include a keyboard, mouse, stylus, the display 21, or any other device capable of inputting information into the jukebox 10.
The jukebox 10 can also have a processor 12, a communication interface 13, and an audio output unit 14 coupled to at least one speaker 15 for replaying the songs. Speaker 15 may optionally be replaced by headphones, including but not limited to one or more wireless headphones, for private listening by one or more users. The audio output unit 14 may optionally be coupled to a wireless transmitter for transmission of the audio signal to a plurality of wireless audio receivers (not shown). The audio output unit 14 may include an audio card, a digital-to-analog converter, and means for decompressing compressed, digital files. The processor 12 may perform a variety of functions, including transferring the songs from the digital memory 11 to the audio output unit 14. The processor may also store information to the digital memory 11 to compile a database containing the number of times that each song is played on the jukebox 10.
The jukebox 10 may optionally include a money detector 17, such as a coin, bill, and/or credit card acceptor. The money detector 17 can include a device for electronic detection of a source of credit or money, such as a credit card or a device with a barcode, RFID tag, or any means for transferring payment information to computer jukebox 10.
It should be noted that the jukebox 10 may include other components and modules necessary to perform other functions associated with a jukebox. For example, other components and modules may be included to employ the jukebox menu navigation system as described in U.S. patent application Ser. No. 12/764,605, filed Apr. 21, 2010, the contents of which are incorporated herein in their entirety.
The jukebox 10 also includes a video cache system (“VCS”) 23 for management of the videos in the digital memory 11, and downloading of videos into the cache 11a. The VCS 23 includes a video cache manager (“VCM”) 25 and a network statistics module (“NSM”) 27. It should be noted that the various data stores may be a part of, or separate from the VCS 23. The NSM 27 uses network metrics to determine when to perform caching operations. Such network metrics include, but are not limited to, overall network data usage, network data usage for each video file download, and network data usage for each video image file download, each of which can be preferably measured in bytes per month. However, other units of measurement are contemplated in keeping with the spirit of the invention.
The NSM 27 includes logging functionality that monitors network traffic on network adapters in the jukebox. At preferably five minute time intervals, the NSM 27 computes a total count of bytes sent and received over the network adapters for the previous time interval. It should be noted that time intervals of other predetermined durations can be used as well. Such network traffic computations are stored as fields in a network traffic table in the network data store. Other network traffic data is stored in the network traffic table as well, an example of which is shown in the representative network traffic table below:
The NSM 27 includes a network statistics handler (not shown) configured to store and retrieve network usage data related to video caching operations. For example, the network statistics handler retrieves and logs video download network usage data for storage in one or more tables in the network data store 11b. Such video download network usage data includes details of each video download, such as a start time of each download, end time of each download, the size of each downloaded file, the time (e.g., in seconds) to complete each download, and the type of download (e.g., video media file, video image file, and the like). A summary of such usage data is shown in the table below:
The network statistics handler retrieves a list of network statistics records containing network metrics derived from the above network traffic and video download tables. Each network statistic record contains the following information:
As discussed in the above table, the billing period is calculated based on a user-supplied value that indicates the starting day of the month for the billing period, and may consist of any predetermined period of time starting and finishing on any day. By way of non-limiting example only, the billing period may run from 12:00 AM on the starting day through 11:59:59 PM on the day immediately prior to the starting day for the following month.
According to an embodiment of the present invention, available non-essential bandwidth may be calculated for each billing period. For each of the previous three billing periods, the NSM 27 calculates a number of essential bytes used. More specifically, the NSM 27 subtracts the total non-essential bandwidth usage (e.g., from the network statistics table) from the total bandwidth usage (e.g., from the video downloads table) for the billing period. If such bandwidth usage records are not available from the tables (e.g., for a least half of the total available days during the billing period, then a default value may be used to represent the count of essential bytes for the billing periods). The default value may be set to any size, such as, for example 1.7 gigabytes.
An average non-essential bandwidth is determined by calculating the average non-essential bandwidth values for each of the three billing periods calculated above. Lastly, an available non-essential bandwidth for a current billing period is determined by subtracting the average essential bandwidth usage from a user-supplied total bandwidth limit.
According to an embodiment of the present invention, the jukebox catalog 11d monitors and stores media content information including but not limited to, what media is available on the jukebox, popularity metrics for the media, and file system data about the media that has been locally cached. Such media content information is used to determine current video popularity, an exemplary method of which is depicted in
Turning now to
Referring now to
Embodiments of the present invention employ a ranking algorithm to predict the popularity of a video on a particular jukebox. By considering various factors, the ranking algorithm computes a projection of such future popularity of a given video. Accordingly, and as discussed above, the projection of future popularity of videos is used to determine videos to be downloaded to, or removed from, the jukebox cache 11a. The ranking algorithm is depicted in
At block 403, the VCM 25 normalizes the retrieved popularity metrics across all videos such that each popularity metric is represented on a scale of 0-100%, with the most popular category (e.g., local song, local artist, and the like) of each metric represented as 100%. On occasion, an album may be featured on one or more of the jukeboxes on the network, as indicated by a network librarian associated with the network of jukeboxes. A featured album may effect an increase in the popularity of a video associated with the featured album. As such, videos associated with featured albums in the jukebox catalog are assigned an additional metric called “featured popularity” (“PFeatured”), which may serve to reflect a projected increase in the popularity of such an associated video. For example, optionally at block 405, videos associated with featured albums are assigned a value of 66% (although other percentages may be used as well). Next, at block 407, the VCM 25 calculates a ratio (“RGenre”) of local genre popularity (“PGenre”) to network popularity (“NGenre”). Such a ratio may be calculated according to the formula: RGenre=PGenre/NGenre. From this ratio, additional metrics are measured at block 409, which include, but are not limited to: an adjusted network song popularity (“Asong=Nsong×RGenre”), an adjusted network artist popularity (“AArtist=NArtist×RGenre”), an adjusted network video popularity (“AVideo=NVideo×RGenre”), and an adjusted network featured popularity (“AFeatured=PFeatured×RGenre”).
In light of the disclosure, one of skill in the art may appreciate that one or more the above discussed metrics may be more significant to the popularity of a video. Embodiments of the present invention take such variations of significance into consideration by weighting the popularity metrics. More specifically, the video caching system applies weighting constants to each of the aforementioned popularity metrics. For example, the popularity of a song already stored locally on a jukebox (i.e., Ksong) may weigh more heavily on the overall ranking of the video than the popularity of a genre of a song already stored locally on a jukebox (i.e., KGenre). As such, the video caching system applies a weighting constant=100 to Ksong, and a weighting constant=0 to KGenre. An exemplary table of weighting constants, which may be applied to respective popularity metrics, is shown below:
It should be noted that the above list is by way of non-limiting example only. As such, each of the above listed constants may be assigned different values. Moreover, additional weighting constants may be implemented in still keeping with the spirit of the invention. Additionally, it may be advantageous to ensure that videos associated with songs flagged as part of a jukebox's local music collection be cached before videos not associated with the local music collection. Accordingly, such videos associated with locally stored songs may have a comparatively large value added to its rank (e.g., 2,000,000).
With the above determined popularity metrics and weighting constants, at block 411, the VCM preferably calculates a rank according to the following formula:
Rank=(PSong×KSong)+(PArtist×KArtist)+(PGenre×KGenre)+(NSong×KNetsong)+(NArtist×KNetArtist)+(NVideo×KNetVideo)+(ASong×KAdjSong)+(AArtist×KAdjArtist)+(AVideo×KAdjVideo)+(PFeatured×KFeatured)+(AFeatured×KAdjFeatured).
It should be noted that the above formula is by way of non-limited example only. As such, other factors, and expressions and values reflecting other factors, may be incorporated into the above formula. Further, some of the factors, expressions, and values listed in the above formula may be modified or removed from the above formula in still keeping with the spirit of the invention. Some additional factors that may be incorporated in the ranking algorithm are described in more detail below.
It should be noted that the above discussed factors incorporated in computing a projected rank are by way of non-limiting example only, and other factors may be added to the computation of the projected popularity rank in still keeping with the spirit of the invention. For example, the fact that a video may be designated as a feature may be taken into consideration. A network recency factor may be incorporated as well. More specifically, the network recency factor may be computed based on a length of time the video has been released on the jukebox network. Such a factor can be used to counteract any lack of network popularity available for a newly released hit by a popular artist. A release recency factor may be also be incorporated. More specifically, the release recency factor may be computed based on a length of time a video has been released to the world (otherwise known as the “street date”). Similar to the above discussed network recency factor, the release recency factor may be employed to boost new releases by popular artists.
The ranking algorithm may also consider certain artists favored by patrons of a particular jukebox. For example, patrons may manually designate (e.g., on the jukebox) an artists they particularly favor. Such a favored setting, or option, could be designated during setup of a particular jukebox. Accordingly, such favored artists may get a comparatively large increase in their ranking, akin to an increase applied to videos associated with locally stored songs, as discussed above.
An owner of a jukebox may manually provide a designation on the video itself. For example, the owner may flag a video that is available in the jukebox library, and provide a designation reflecting that the video should be downloaded to the jukebox. Such a designated video would also get a dramatic ranking boost similar to videos associated with locally stored songs.
Another factor that may be considered relates to patron video requests. For example, patron requests for a particular video may be tracked and aggregated based, at least in part, on indications sent from patrons using a user interface, such as the jukebox user interface or a mobile application or “app”, (such as AMI's BARLINK application), on a computing device. As used herein, a computing device may refer to a smart phone, a tablet, an e-reader, a mobile gaming console, a personal computer, an mp3 player, an iPod or any other device capable of interfacing with a network of jukeboxes. In some embodiments, ranking may also consider, as a factor, requests based on selections of the patrons of other jukeboxes. For example, in the instance that a patron makes a selection on a particular jukebox, the patron's previous requests (e.g., at other networked jukeboxes) may also be considered.
Embodiments of the present invention are not limited to the above discussed factors. For example, other factors may be instituted into the ranking algorithm in still keeping with the spirit of the invention.
As discussed above, music video files and their associated image files are stored on a content drive 11e separate from the rest of the content for the jukebox. In other embodiments, the video files an image files are stored on the same physical drive, but may be logically partitioned. Also stored on the content drive is a manifest which provides metadata information for all of the videos. The purpose of the manifest is to provide catalog information (including decryption keys for the video files) for the videos stored on the content drive so that content drives may be freely transferred between networked jukeboxes 10.
Each video file on the jukebox 10 has an entry in the manifest that is kept up to date with jukebox catalog changes and caching information. Additionally, there is a metadata entry for the manifest as a whole that contains a hash code for the manifest and the catalog version against which the manifest was built. All metadata information for the videos is stored as encrypted string information in the manifest with the exception of the manifest metadata (e.g. hash code and catalog version), which is stored as plain text.
The manifest is updated discretely as video and image files are downloaded and deleted during caching operations. The manifest is rebuilt as a whole whenever a new catalog is received from the server and integrated into the local jukebox database. Such manifest information is stored as follows:
A hash code for the video manifest is generated by creating a large text string of all of the ID and version information for the videos on the content drive. The specific method used is as follows:
Because the hash code is derived from catalog information stored in the jukebox catalog 11d, it can be re-computed at any time and compared with the hash code that is stored in the manifest on the content drive 11e. Any differences between the hash code from the manifest and the hash code computed from the jukebox catalog 11d will indicate that the content drive 11e is out of sync with the jukebox catalog 11d, which may be due to its being a content drive 11e that was transferred from another jukebox 10. When this condition is detected, the jukebox 10 will read all of the catalog information from the manifest on the content drive 11e and update its jukebox catalog 11d to bring the jukebox catalog 11d back into sync with the music video content that is available on the content drive 11e.
According to embodiments of the present invention, the VCM 25 is configured to operate on one or more jukeboxes supporting music video playback, and is automatically initiated upon startup of the jukebox. Even though the VCM 25 is initiated upon jukebox startup, video caching operations as discussed hereinthroughout commence upon cache timing requirements being satisfied. For example, a timer running on regular time intervals (e.g., one-minute intervals) starts upon activation of the VCM 25. Upon expiration of this timer, the VCM 25 determines whether cache timing requirements are met. Such cache timing requirements preferably include the following: (1) there are no video caching download operations currently in progress, (2) there are no video cache maintenance operations currently in progress, (3) the jukebox has a broadband network connection to the network, (4) the music video playback has been enabled by the jukebox, and (5) there is non-essential bandwidth available for the current billing period.
If the above requirements are satisfied, the VCM 25 determines whether it is time to download a video to the jukebox cache. For example, referring now to
Referring now to
Upon successful download of the video, at block 615, network usage data for the successful download is logged in the video downloads table as discussed above. Although not shown in
Periodic maintenance on the jukebox cache 11a may need to be performed to ensure there exists enough hard drive space in the jukebox cache 11a for the most popular videos. Turning now to
Images may also be associated with the videos played on a jukebox. A missing image retrieval technique may be employed to retrieve missing images associated with songs and videos. For such missing images, certain criteria are used to determine whether such missing images should be downloaded to the jukebox cache. Such criteria include whether the missing video images for videos that have already had their video media files downloaded may be eligible for downloading, and if the above discussed cache timing criteria. If such criteria are met, the subject missing image will be downloaded into the jukebox cache 11a, and the network usage data related to the download is logged and dispatched to the network statistics handler. Alternatively, if one of the criteria is not met, downloads for the remaining missing video images will be deferred until a subsequent operation of the video image retrieval process. Subsequently, the manifest on the content drive is updated to include metadata for any images that were downloaded, and a new hash code for the manifest on the content drive is generated and stored.
It will be appreciated by those skilled in the art that changes could be made to the embodiments described above without departing from the broad inventive concept thereof. It is understood, therefore, that this invention is not limited to the particular embodiments disclosed, but it is intended to cover modifications within the spirit and scope of the present invention as defined by the appended claims.
This application claims the benefit of U.S. Provisional Patent Application No. 62/077,745, filed on Nov. 10, 2014, entitled “Video Caching System and Method for a Jukebox,” the entire contents of which are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62077745 | Nov 2014 | US |
