JP6589087B2 - Content reproduction apparatus and computer program - Google Patents

Description

  The present invention relates to a content playback apparatus and a computer program for playing back content. The type of content to be played back in this specification is not limited to music, and may be content in various forms such as electronic book content, moving image content, and still image content.

  In recent years, mobile devices called smartphones that can communicate with the Internet anytime and anywhere by using mobile communication systems such as 3G and LTE have become widespread. A cloud-type music distribution service is provided that provides a streaming reproduction function for reproducing music data while sequentially downloading music data from other content servers. Furthermore, in recent years, flat-rate music distribution services are also becoming popular. With a flat-rate music distribution service, you can watch as many songs as you like, including new and old ones, with no restriction on viewing time, by paying a fixed service fee each month.

  In such a cloud-type music distribution service, there is no limit to the number of songs that can be played since there is no need to store the songs that you want to listen to in the built-in memory in the mobile device. Is not consumed for storing music data, so that it is possible to install many other application programs in a limited internal memory. As described above, the cloud-type music distribution service is very compatible with a mobile device in which the capacity of the built-in memory is limited and it is difficult to add the memory capacity later, such as a personal computer.

  However, this cloud-type music distribution service has a serious drawback. Because it is necessary to download music data sequentially from the server on the cloud during music playback, music is not available in places where 3G or LTE base stations are not in the vicinity of mobile devices and are displayed outside the service area. It becomes impossible to reproduce. Recently, in-house MVNO that does not have a mobile network but borrows a network from a mobile network operator (hereinafter referred to as MNO) that has another network and provides communication services under its own brand. Mobile Virtual Network Operator) can use mobile communications at a lower service charge than the MNO, instead of having an upper limit on the amount of mobile communication data that can be used every month. We are starting to provide communication services. Such a communication service that can save a monthly communication fee is called a cheap SIM.

  Such a low-cost SIM has an upper limit on the amount of mobile communication data that can be used every month, so it is not very compatible with a cloud-type music distribution service. This is because, for example, if the upper limit of the amount of mobile communication data that can be used during the month is reached during the month, music cannot be heard from that point until the end of the month. Therefore, in order to cope with such inconvenience, there is an increasing need for an offline playback function that allows music to be played by some method even when the mobile device is in an offline state where communication with the Internet is not possible. .

As a specific countermeasure for that, by downloading and storing only the music data of the specific music selected by the user to the built-in memory of the mobile device, even if the mobile device is offline, the built-in A technique for enabling reproduction of music stored in a memory is conceivable and already known (for example, see Patent Document 1).
Alternatively, as another countermeasure, by providing a so-called caching mechanism that copies the reproduced music data to the built-in memory of the portable device, it is stored in the cache memory even in a situation where communication with the Internet is not possible. Content cache technology that enables offline playback of music is also commonly used. The problem with this content cache method is that there is a limit to the amount of memory that can be used as a cache memory, so if you continue to add additional music data to the cache memory, the cache memory will eventually become full. Therefore, it becomes impossible to write music data any more. Least Recently Used as a cache management algorithm to determine which music should be left in the cache memory and which music should be discarded from the cache memory when such a situation occurs A method (hereinafter referred to as “LRU”), a least frequently used (hereinafter referred to as “LFU”) method that discards the least frequently used data, and the like are widely used as a cache memory management method.

JP 2013-77079 A

  However, in a cloud-type music playback application that has a function for downloading conventional music data, the music data of the music specified by the user manually is downloaded and stored in the internal memory of the mobile device. It was not too much. For example, assume that a user's favorite artist has released a new album. Users want to be able to play this new music even when they go to a place where radio waves from the base station do not reach the smartphone. If the user wants to save and download the music data of this new music that they are likely to hear well in the future, the user must manually perform an operation for downloading the music included in the album.

  As a further problem, there is a situation in which the user cannot continue to download such music data. This is because there is an upper limit on the capacity of the built-in memory of the mobile device, so that the upper limit of the memory capacity will be reached at some point, and music can no longer be downloaded. If the memory is full, the user needs to select music that is unlikely to be heard in the future and manually perform an operation for deleting those music data.

  That is, in a conventional cloud-type music playback application having a function of downloading music data, the user has to manage music data downloaded to the mobile terminal manually. The user needs to pay attention to things that have nothing to do with the direct purpose of listening to music, and in some cases the user has to manually manipulate to download new songs or delete old song data Therefore, there was a problem that the usability of the app was bad.

  Therefore, the present invention has been made in view of such problems, and the purpose of the present invention is to allow a user to play music by automating management of downloaded music data in a cloud-type music playing app. It is an object of the present invention to provide a new and improved content reproduction apparatus and computer program that can free from unnecessary work other than selecting music and improve the usability of a cloud-type music reproduction application.

  In addition, in a cloud-type music playback application having a music data caching function, the management of cache data is certainly automated, and there is no need for the user to manually download music data or delete old music. However, cache management algorithms such as the LRU method and LFU method that have been used in the past have fatal drawbacks. That is, the object of maintaining the usage history information (access date and time in the LRU method, access frequency in the LFU method) of each music data is limited to only the music data existing in the cache memory. For this reason, when a user happens to be there when he or she plays an old song that has no copy of the song data on the cache memory after a long time, the user probably plays the same song repeatedly in the near future. The old music data is cached even though it is unlikely. This is because, in the LRU method, the music reproduced by the user is the most recently used data at that time, so it is determined that the data should always be left in the cache memory with re-priority. In other words, the LRU method has a drawback that it does not consider the frequency of data access at all.

  On the other hand, the LFU system is similar to the present invention at first glance in that it considers the data access frequency. However, in the LFU method, the usage history information related to the data to be cached is limited to the data that exists in the cache memory, so the past access history information is not available for the most recently accessed data. Since there is no access frequency, the most recently accessed data always has the same operation as the LRU method of writing to the cache memory.

  This situation is also common to other cache management methods other than the LRU and LFU methods. That is, in the conventional cache management method, since there is no past access history information regarding data that does not exist in the cache memory, even if the access frequency for the most recently accessed data is low in the past, Always wrote to cache memory. As a result, in the cloud-type music playback application with the conventional caching function, when playing a song with low playback frequency, the music data of new music or quasi-new music is evicted from the cache. As a result, the amount of mobile communication data was wasted.

  On the other hand, the present invention is characterized in that the reproduction history information is maintained and managed for music that does not exist on the cache memory in addition to music that exists on the cache memory. Therefore, for music that can be referred to the playback history information, by considering the playback frequency and playback probability of each piece of music data, the streaming playback operation of simply playing back the song data downloaded from the content server on the cloud, and It is possible to appropriately switch between the download reproduction operation that is written and left in the non-volatile cache memory in preparation for later repeat reproduction. As a result, the present invention has a high cache hit rate and can save a valuable amount of mobile communication data as compared with a cloud-type music playback application having a conventional cache mechanism. An object of the present invention is to provide a new and improved content reproduction apparatus and computer program suitable for a communication service of a pay-per-use system represented by a low-priced SIM that has been widely used in recent years.

  In order to solve the above problem, according to a first aspect of the present invention, a content cache unit for storing content and playback frequency information for calculating the playback frequency of content registered in a content server on the cloud And a content cache management unit that manages the content cache unit. The content cache management unit includes content on the content server based on the playback frequency information of the content to be played back. Switching between an on-the-fly playback operation in which the content data is downloaded in real time while downloading the content data, and a download playback operation in which the content data downloaded from the content server is simultaneously played back while being written to the content cache unit. Ntsu playback device is provided.

  According to such a configuration, by switching between on-the-fly playback and download playback automatically according to the content playback frequency, when content that happens to be played back infrequently is played back, the content that is played back more frequently from the content cache. The situation of deleting can be prevented. As a result, the hit rate of the content cache is improved and the amount of communication data can be further saved. In this way, it is possible to provide a content playback apparatus that improves the usability of the cloud-type music playback application.

  In addition, since it is possible to prevent the data of a song that has been played after a long absence but is unlikely to be heard for a while from being stored in the cache, a memory with a limited number of rewrites (for example, NAND-Flash memory) (The mobile terminal becomes a malfunction and becomes unusable when the built-in NAND-Flash memory reaches the end of its life). As a result, the usable years of the mobile terminal can be extended.

  In order to solve the above problems, according to a second aspect of the present invention, a content cache unit for storing content and a playback probability prediction for predicting a playback probability of content registered in a content server on the cloud A content database that holds information, and a content cache management unit that manages the content cache unit, the content cache management unit on the content server based on the playback probability prediction information of the content to be played back Switching between an on-the-fly playback operation in which content is downloaded in real time and a download playback operation in which content data downloaded from the content server is simultaneously played while being written to the content cache unit. , The content reproduction apparatus is provided.

  According to this configuration, content with a high playback probability (for example, content with a new registration date and time (new music in terms of music) registered in the content server) is stored in the content cache, so that the content cache hit rate is improved and mobile content is improved. Communication bandwidth can be saved. On the other hand, since the old music that happens to be played after a long time is not cached, the content cache hit rate does not decrease by playing the old music. In this way, it is possible to provide a content playback apparatus that improves the usability of the cloud-type music playback application.

The present invention can be applied in various ways.
For example, in the content cache unit, data may be recorded separately for the top portion (for example, about 3 seconds) of each content and the remaining portion (or the whole). According to such a configuration, flexible control such as preferentially leaving the data at the beginning of the content can be performed, and the reproduction delay time at the start of content reproduction is shortened. If the head portion of the content exists in the content cache, it becomes possible to immediately start playback of the music when the user instructs playback of the music, thereby improving the usability of the device.

  Further, in the content cache unit, when the capacity is full, the remaining portion of each content may be deleted first. According to such a configuration, there is a high possibility that the top data of the content remains in the content cache. Therefore, there is a high possibility that the response when the music playback instruction is issued increases, and the usability of the device is improved.

  Further, the content cache unit separately manages the capacity of the head part cache for storing the head part of each content and the capacity of the remaining part cache for storing the remaining part of each content, and the capacity is full. In such a case, an unnecessary data deletion process may be performed independently in the head partial cache and the residual partial cache. According to such a configuration, there is a high possibility that the top data of the content remains in the content cache. Therefore, there is a high possibility that the response when the music playback instruction is issued increases, and the usability of the device is improved.

  In addition, the content cache unit includes a first content cache that stores content that is likely to be played back by the user most recently, and a second content cache that stores content that is likely to be played back by the user later. You may do it. For each of the first and second content caches, it is possible to employ an optimum data management method in accordance with the usage status of each content cache unit, so that cache data can be used effectively. In addition, for each of the first and second caches, it is possible to use an optimum data recording device according to the usage status of each cache, so that the device life is prevented from being consumed, and as a result, the life of the device is increased. be able to.

  Further, only the content related to the content being reproduced (for example, only the content of the album being reproduced) may be stored in the first content cache. According to such a configuration, it is possible to provide an operability of quickly responding when the user performs an operation of changing the content being reproduced (for example, the song being reproduced).

  The first content cache may be configured by a volatile memory such as a main memory as a data storage destination. According to such a configuration, the use of the main memory as the storage destination of the first content cache with the most frequent replacement of data makes it possible to reduce the lifetime of a device (for example, a NAND-Flash memory) used for the second content cache. It is possible to prevent wear and increase the life of the device.

  The data management unit in the first content cache may be a chunk unit obtained by further dividing one content (for example, one song). According to such a configuration, the content data can be prefetched up to the limit of the capacity of the first content cache, so that the cache capacity can be fully utilized. Accordingly, the length of the content that can be prefetched is increased accordingly, so that even when the download speed from the content server is temporarily reduced, it is possible to provide a device with less occurrence of playback interruption.

  The second content cache stores only content that is likely to be played back at a later date, and an algorithm for cache management in the second content cache is different from the first content cache. It may be. According to such a configuration, it is possible to employ an optimal cache management algorithm according to the usage status of the second content cache, so that the hit rate of the second content cache is further improved, resulting in a limited Internet. It is possible to save the communication data amount.

  Further, the second content cache may be configured by a nonvolatile memory configured by a NAND-Flash memory or the like as a data storage destination. According to such a configuration, even when the device is turned off or restarted, data in the second content cache that can be assigned a larger capacity than the first content cache is lost. Therefore, the cached data can be used more effectively. Therefore, a limited amount of Internet communication data is not wasted.

  The data management unit in the second content cache may be a content unit (for example, a song unit). According to such a configuration, it is possible to prevent an increase in the management data of the second content cache, and thus it becomes possible to cache a large number of music pieces in a memory having the same capacity. In addition, the frequency of rewriting data in the second content cache can be greatly reduced. There is a device-specific upper limit number of writes in the NAND-flash memory. By saving the rewrite frequency, it is possible to expect a significant increase in the lifetime of the device.

  The capacities of the first content cache and the second content cache may be set individually. According to such a configuration, since it is possible to select an optimal cache capacity according to the use situation / use environment of the user, for example, when a communication contract with an unlimited monthly communication volume is made, the second content The cache capacity is set to a very small amount, mainly using only the first content cache, thereby preventing music playback interruption when the communication speed temporarily decreases, and reducing the non-volatile memory capacity of the device. Unnecessary consumption can be prevented. Or, conversely, if you have a communication contract with an upper limit on the monthly communication volume, setting both the first content cache and the second content cache to a large amount prevents music playback interruptions and saves communication data volume. It is possible to enjoy both of the effects.

  The content database may hold integrated content list information obtained by integrating content list information of a plurality of content servers. According to such a configuration, even when the content storage destination is divided into a plurality of servers, the content to be reproduced can be selected from the centralized content list, so that the usability is improved. Further, the user can be released from the operation of selecting the content server in which the music to be reproduced is registered.

  The application examples of the present invention can be arbitrarily combined. Further, according to the present invention, there is provided a computer program for causing a computer to function as any one of the content playback devices described above.

  According to the present invention, in the cloud-type music playback application, the management of the downloaded music data is automated, so that the user is freed from unnecessary work other than selecting the music to be played back. A content playback device and a computer program capable of improving the usability of the user are provided. The other effects of the present invention will be described in the section for carrying out the invention below.

1 is a diagram schematically showing an overall configuration of a content reproduction system. It is a figure which shows the content of a content server. It is a figure which shows arrangement | positioning of the data in the 1st content cache L1. It is a figure which shows arrangement | positioning of non-volatile data. It is a figure which shows the content of a content database. It is a figure which shows the operation | movement at the time of on-the-fly reproduction. It is a figure which shows the operation | movement at the time of download reproduction | regeneration. It is a figure which shows the operation | movement at the time of cache reproduction | regeneration. It is a sequence diagram which shows operation | movement of one Embodiment of this invention. It is the figure which listed the example of the interface command. 3 is a flowchart showing a main thread of the main controller 110. 3 is a flowchart showing a UI processing thread of the main controller 110. 4 is a flowchart showing a playback processing thread of the main controller 110. 6 is a flowchart illustrating a main thread of the content cache management unit 190. 6 is a flowchart illustrating a prefetch thread of the content cache management unit 190. It is a flowchart which shows the next download chunk determination process. It is a flowchart which shows an empty chunk buffer search process. It is a flowchart which shows a cache reproduction | regeneration thread | sled. 6 is a flowchart showing a download / on-the-fly playback thread. It is a flowchart which shows a L2-H cache write process. It is a flowchart which shows a L2-E cache write process. It is a flowchart which shows the calculation process of a content reproduction frequency value. It is a flowchart which shows a content reproduction frequency value update process thread. It is a flowchart which shows the update process thread | sled of the content database 170. FIG. It is a flowchart which shows a directory search process. It is a flowchart which shows the unnecessary record deletion process of an artist table. It is a flowchart which shows the unnecessary record deletion process of an album table. It is a flowchart which shows the unnecessary record deletion process of a song table. It is a flowchart which shows the calculation process of a content reproduction probability estimated value. It is a flowchart which shows a content reproduction probability estimated value update process thread.

  Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. In addition, in this specification and drawing, about the component which has the substantially same function structure, duplication description is abbreviate | omitted by attaching | subjecting the same code | symbol.

(First embodiment)
First, the overall configuration of a content reproduction system to which the content reproduction apparatus 100 according to the present embodiment is applied will be described. FIG. 1 is a diagram schematically showing an overall configuration of a content reproduction system. As shown in FIG. 1, in the content reproduction system, the content server 10 and the content reproduction apparatus 100 can communicate via a network such as the Internet. Hereinafter, each component of the content reproduction system will be described in order.

(Content server 10)
The content server 10 is a server that stores and holds content data to be played back in the content playback device 100 described later by using storage (cloud storage) that exists on the cloud.

  The contents of content data stored / held in the content server 10 will be described with reference to FIG. FIG. 2 is a diagram illustrating a part of the contents of the content server 10. As shown in FIG. 2, the content data stored / held in the content server 10 includes an artist, an album name, a track number, a title, and a URL (Uniform Resource Locator) where the content is placed. Composed. In FIG. 2, three content data are represented by (a) to (c). These may be placed in one content server 10, or may be placed in different content servers as in the present embodiment.

  The relationship between the artist, album name, track number, title, and content URL in the content data is the same as a general one. In other words, for an artist, there may be one album name or two or more album names. For example, in the example of FIG. 2, two albums “Please please me” and “A hard day's night” correspond to the artist “The Beatles”. Also, album names and track numbers generally have a 1: multiple relationship. Each track has a title, and one content URL corresponds to each title.

  The content server 10 has been described above. Next, with reference to FIG. 1 again, the content reproduction apparatus 100 that is a characteristic component of the present embodiment will be described.

(Content Playback Device 100)
The content reproduction apparatus 100 is assumed to be a mobile device that is a device that a user can carry and move. As shown in FIG. 1, the content playback apparatus 100 includes a main controller 110, a network communication unit 120, an operation detection unit 130, a screen display unit 140, a music playback unit 150, a content cache unit 160, a content A database 170, a content database update unit 180, and a content cache management unit 190 are mainly provided. Hereinafter, each component of the content reproduction apparatus 100 will be described in order.

  The main controller 110 controls the entire content reproduction apparatus 100 and operates in cooperation with each component of the content reproduction apparatus 100 as shown in FIG. Note that the arrows in FIG. 1 are given for the sake of convenience. Some arrows do not operate in cooperation even if they are drawn, and some operate in cooperation even if no arrow is drawn. In the following description, the control subject is not clearly indicated for the operation / action performed by the control of the main controller 110.

  As a control characteristic of the present embodiment in the main controller 110, the main controller 110 operates in conjunction with a content cache management unit 190 described later to switch playback operations. Specifically, the main controller 110 operates in conjunction with the content cache management unit 190 to switch between the on-the-fly playback operation and the download playback operation. This point will be further described later.

  The network communication unit 120 is a functional unit that communicates with the content reproduction apparatus 100 via the Internet. The operation detection unit 130 detects an operation by the user of the content reproduction device 100. The operation by the user includes various operations such as an operation by a finger, an operation by a voice, and an operation by moving the content reproduction apparatus 100, for example. The screen display unit 140 is a screen that displays various types of information in the content reproduction apparatus 100. The music playback unit 150 is a functional unit that outputs sound.

  The network communication unit 120, the operation detection unit 130, the screen display unit 140, and the music playback unit 150 described here are general components in general-purpose mobile devices and music players, and can be easily understood by those skilled in the art. I will omit a more detailed explanation because I can. Needless to say, the content reproduction apparatus 100 may include other general components.

(Content cache storage unit 160)
The content cache unit 160 is a storage unit that stores a copy of content data. In the present embodiment, the content cache unit 160 includes a first content cache L1 and a second content cache L2.

  The content cache unit 160 includes a first content cache L1 that stores content that is most likely to be played back by the user, and a second content cache L2 that stores content that is likely to be played back by the user again at a later date. By adopting such a configuration, it becomes possible to adopt an optimum data management method according to the usage status of each content cache L1, L2 for each content cache L1, L2, so that cache data can be used effectively. Is possible.

  In addition, since it is possible to use an optimum data recording device corresponding to the usage status of each content cache for each of the content caches L1 and L2, it is possible to prevent consumption of the device life and consequently increase the life of the device. Can be planned. In the present embodiment, a case will be described in which a RAM (main memory) is used as the first content cache L1, and a NAND-flash memory is used as the second content cache L2.

(First content cache L1)
Hereinafter, the first content cache L1 will be described. First, the configuration of the first content cache L1 will be described, and further the features of the first content cache L1 will be described.

  As described above, the first content cache L1 is arranged on the RAM (main memory). As shown in FIG. 3, a partial area of the main memory is allocated as the first content cache data area 161. As shown in FIG. 3, an L1 cache management table 162 and an L1 cache chunk buffer 163 are arranged in the first content cache data area.

  As shown in FIG. 3, the L1 cache management table 162 includes a “chunk_id” field that is a chunk index, a “song_id” field that is a song index, and a number of chunks that constitute a song. "Chunk_no" field indicating whether the chunk is already sent, "used" field indicating that the chunk data has been sent, "chunk_start_time" field that is the start time of the chunk, and "chunk_end_time" field that is the end time of the chunk Consists of. Multiple chunks in the chunk_no field correspond to one song in the song_id field. The value of the chunk_id field is associated with the L1 cache chunk buffer 163.

  In the example shown in FIG. 3, there are a total of five chunk data in the first content cache L1. The chunks with “chunk_id” = 1 to 5 correspond to the chunk data for the top five pieces of the song with “song_id” = 1. For example, the chunk with “chunk_id” = 1 corresponds to the music data from 0 minute 0 second 00 to 0 minute 7 second 39 of the song with “song_id” = 1, and the chunk with “chunk_id” = 2 It corresponds to music data from 0 min 7 sec 39 to 0 min 12 sec 78 of the song of “song_id” = 1, and so on. In addition, chunks with “chunk_id” = 1 to 3 have been sent out, and if no other empty chunk buffer is found, it indicates that the chunk can be released.

  As shown in FIG. 3, the L1 cache chunk buffer 163 is an area in which chunks corresponding to the value of the chunk_id field are stored. The size of each chunk buffer is fixed at 64 KB.

  Only the content of the album being reproduced is stored in the first content cache L1. Thereby, when the user performs an operation of changing the reproduced music, it is possible to provide an operability of quickly responding.

  Further, as described above, the first content cache L1 is configured by a volatile memory such as a main memory as a data storage destination. By using the main memory with no limit on the number of rewrites as the storage destination of the first content cache L1 where the replacement of data is the most intense, it is possible to extend the life of the device.

  The data management unit in the first content cache L1 is a chunk unit obtained by further dividing one song. According to such a configuration, the content data can be prefetched up to the limit of the capacity of the first content cache L1, so that the cache capacity can be fully utilized effectively. Since the length of the content that can be pre-read increases accordingly, even when the download speed from the content server 10 temporarily decreases, it is possible to provide a device with less occurrence of playback interruption.

(Second content cache L2)
Hereinafter, the second content cache L2 will be described. First, the configuration of the second content cache L2 will be described, and further the features of the second content cache L2 will be described.

  Non-volatile data read / written by the content reproduction application is stored in a NAND-flash memory, which is a non-volatile memory device, in an example of the present embodiment. As shown in FIG. 4, a management data area 164 and an L2 cache content storage area 165 are arranged in the NAND-flash memory.

  In the management data area 164, as shown in FIG. 4, a content DB file 166 and an L2 cache management file 167 are arranged. In the content DB file 166, as shown in FIG. 4, a server table, an artist table, an album table, and a song table are written. As shown in FIG. 4, the L2-H cache management table and the L2-E cache management table are written in the L2 cache management file 167. Note that L2-H means the head portion (Head) of the second content cache L2, and L2-E means the entire second content cache L2.

  The L2-H cache management table includes an id field, a song_id field, a file field, and a score field. The file field of the L2-H cache management table is associated with a content head cache file described later. The L2-E cache management table includes an id field, a song_id field, a file field, and a score field. The file field of the L2-E cache management table is associated with a content cache file described later.

  As shown in FIG. 4, the L2 cache content storage area 165 includes an L2 content head part storage area L2-H and an entire L2 content storage area L2-E. The L2 content head part storage area L2-H is an area for storing the head part of content (L2 content) stored in the second content cache L2, and has a maximum size of 512 MB, for example. The entire L2 content storage area L2-E is an area for storing the entire content (L2 content) stored in the second content cache L2, and is, for example, a maximum of 4 GB.

  In the L2 content head part storage area L2-H, content head cache files 00001.head, 00002.head, 00003.head, 00004.head,... Are stored as shown in FIG. Each file size can be fixed at 64 KB. In this case, 512 MB ÷ 64 KB = maximum 8192 songs can be stored.

  In the entire L2 content storage area L2-E, content cache files 00001.cache, 00002cache, 00003.cache, 00004.cache,... Are stored as shown in FIG. Each file size is a variable length depending on the length of the content. For example, if the average file size of the content is 4 MB, the content can be stored up to about 4 GB ÷ 4 MB = 1024 songs at maximum.

  Only content that is highly likely to be played back at a later date is stored in the second content cache L2, and an algorithm for cache management in the second content cache L2 is different from that of the first content cache L1. Since it is possible to employ an optimal cache management algorithm according to the usage status of the second content cache L2, the hit rate of the second content cache L2 is further improved, resulting in a limited amount of Internet communication data. It is possible to save.

  In addition, as described above, the second content cache L2 is configured by a nonvolatile memory configured by a NAND-Flash memory or the like as a data storage destination. Loss of data in the second content cache L2 to which a larger capacity can be allocated compared to the first content cache L1 even when the content playback device 100 is turned off or restarted. Therefore, the cached data can be used more effectively. In this way, a limited amount of Internet communication data is not wasted.

  The data management unit in the second content cache L2 is a song unit. In this way, by performing management at a finer granularity than the first content cache L1, it is possible to prevent an increase in the management data of the second content cache L2, and therefore it is possible to cache more songs in the same capacity memory It becomes. In addition, the frequency of rewriting data in the second content cache L2 can be significantly reduced. There is a device-specific upper limit number of writes in the NAND-flash memory. By saving the rewrite frequency, it is possible to expect a significant increase in the lifetime of the device.

  The first content cache L1 and the second content cache L2 constituting the content cache unit 160 have been described above. Hereinafter, application examples of the first content cache L1 and the second content cache L2 will be described.

  In the content cache unit 160, data can be recorded separately for the top portion (for example, about 3 seconds) of each content and the remaining portion (or the whole) other than that. Flexible control such as preferentially leaving the data at the beginning of the content can be performed, and the playback delay time at the start of content playback is shortened. If the head portion of the content is present in the content cache unit 160, it is possible to immediately start playing the music when the user instructs the music to be played, which improves the usability of the device.

  Further, when data is recorded in the content cache unit 160 by dividing the head portion (for example, about 3 seconds) of the content and the whole (or the remaining portion excluding the head portion), the content cache unit 160 It is possible to increase the number of songs that can store only the beginning of the content, compared to the total number of songs that can be stored.

  For example, in a situation where only the top part of a certain song is cached and the whole is not cached, when the reproduction of the song is instructed, a request to download the entire song data is issued to the content server 10. At the same time, reproduction of the top data of the content in the content cache unit 160 is started. After that, when the time that is the sum of the network communication delay time (round trip) + the response time of the content server 10 elapses, the content data starts to arrive from the content server 10. By setting the length of the head portion of the content stored in the content cache unit 160 to be longer than the server response time, the content can be reproduced without interruption. In this embodiment, by setting the data size of the top part of the content to be the same as the chunk size of the second content cache L2, it is possible to prevent the content control processing performed by the content cache management unit from becoming complicated. .

Here, it demonstrates in contrast with a prior art. Conventionally, in order to reduce cache data, file data has been partially deleted. The partial deletion of the file data here means that the data is altered in a direction of reducing the quality of each content. For example, the following deletion has been performed.
Still image: Thins out pixels (decreases resolution).
・ Video: Thinning out frames (decreasing the frame rate (smoothness of video)).
-Image + Text: Delete the image and leave only text information.
-Audio: Converts stereo audio to monaural audio. Lower the bit rate (at the same time the sound quality deteriorates).
In this respect, according to the present embodiment, since the contents are deleted in the time direction while maintaining the quality of each content, the meaning of partial deletion is completely different. The effect obtained is completely different.

  Further, in the content cache unit 160, when the capacity is full, the remaining portion of each content (a portion other than the top data of the content) may be deleted first. Since there is a high possibility that the top data of the content remains in the content cache unit 160, there is a high possibility that the response when the music reproduction instruction is given increases, and the usability of the device is improved.

  In addition, the content cache unit 160 manages the capacity of the head part cache for storing the head part of each content separately from the capacity of the remaining part cache for storing the remaining part of each content, and the capacity becomes full. In such a case, the unnecessary data may be deleted independently from the head partial cache and the remaining partial cache. Since there is a high possibility that the top data of the content remains in the content cache unit 160, there is a high possibility that the response when the music reproduction instruction is given increases, and the usability of the device is improved.

Further, the capacities of the first content cache L1 and the second content cache L2 may be set individually. Since it is possible to select an optimal cache capacity according to the user's usage status and usage environment, the following usage is possible.
-For example, if you have a communication contract with unlimited monthly traffic, set the capacity of the second content cache L2 to a very small amount and use only the first content cache L1 temporarily. Therefore, it is possible to prevent interruption of music playback when the communication speed is lowered and to consume the nonvolatile memory capacity of the device unnecessarily.
-Or conversely, if you have a communication contract with an upper limit on the monthly traffic, setting both the first content cache L1 and the second content cache L2 to increase the music reproduction interruption effect and communication It is possible to enjoy both effects of saving data.

(Content database 170)
With reference to FIG. 1 again, the components of the content reproduction apparatus 100 will be described.
The content database 170 is a functional unit that holds reproduction history information and content freshness information related to content registered in the content server 10. The content database update unit 180 is a functional unit that updates the contents of the content database 170.

  Information held in the content database 170 will be described with reference to FIG. FIG. 5 is a diagram showing a part of the contents of the content database 170. The information held in the content database 170 includes the server table shown in FIG. 5A, the artist table shown in FIG. 5B, the album table shown in FIG. 5C, and FIG. The song table shown in FIG.

  The server table indicates the top URLs of the content servers 10, and in the example illustrated in FIG. 5A, the top URLs of the three content servers 10 are illustrated. As shown in FIG. 5B, the artist table includes an “id” field that is an identifier, a “name” field that is an artist name, and a “yomi” field that indicates the reading of the artist name. As shown in FIG. 5C, the album table includes an “id” field that is an identifier, an “artist_id” field, and a “title” field that is the title name of the album. Here, the “artist_id” field corresponds to the “id” field of the artist table.

  As shown in FIG. 5D, the song table includes an “id” field that is an identifier, an “album_id” field that is an album identifier, a “trackno” field that represents a track number in the album, A “title” field that represents the title, a “server_id” field corresponding to the server table, a “path” field that represents the location of the song on the content server, and a “filesize” field that represents the length of the song data in bytes. , “Write_date” field that records the date and time when this song was written to the content server, “play_date1” field that records the date and time when this song was last played, and the date and time when this song was last played And “play_date2” field for recording.

The reproduction frequency value can be calculated by the following program, for example. The score value indicates the reproduction frequency, and the larger the value, the higher the reproduction frequency.
if play_date2! = ""
then
diff = max (play_date1-play_date2, now_date-play_date1)
score = max (365-diff, 0) / 365 * 100
else
score = -1

  Here, the values of (play_date1-play_date2) and (now_date-play_date1) are calculated in units of days. For example, when a certain content is first played back at 10:00 on December 1, 2015 and the same content is played back at 22:00 just 12 hours later, the calculated value of (play_date1-play_date2) is 0. .5. The score value calculated by the above program is approximately 100 when, for example, the same content is reproduced twice in succession. On the other hand, the score value decreases as the number of days difference between play_date1 and play_date2 increases. When the number of days difference reaches 365 days, the score value becomes zero. Also, even if the difference in days between play_date1 and play_date2 is small, the score value also decreases as the difference in days between now_date and play_date1 increases. This is because even if a certain content has been played repeatedly many times in the past, if many days have passed since the last playback of the content, the playback frequency of the content is considered to have decreased. Because it is. It is determined that the higher the score value, the higher the frequency of content playback, but the absolute score value itself has no particular meaning.

  The content database 170 has been described above. The content database 170 can hold various information other than the above. For example, the content database 170 may hold integrated content list information obtained by integrating content list information of a plurality of content servers (for example, a plurality of content servers having the same configuration as the content server 10). According to such a configuration, even when the content storage destination is divided into a plurality of servers, the content to be reproduced can be selected from the centralized content list, so that the usability is improved. Further, the user can be released from the operation of selecting the content server in which the music to be reproduced is registered.

(Content cache management unit 190)
The content cache management unit 190 is a functional unit that manages the content cache unit 160. The content cache management unit 190 implements an on-the-fly playback operation and a download playback operation by cooperating with the main controller 110. That is, the content cache management unit 190 switches between the on-the-fly playback operation and the download playback operation according to the playback frequency information of the content to be played back.

  The content reproduction operation will be described with reference to FIGS. 6-8, the broken line in a figure shows the flow of content data. As shown in FIG. 6, the on-the-fly playback operation is an operation for playing back in real time while downloading the content data on the content server 10 to the first content cache L1.

  In addition, as shown in FIG. 7, the download / playback operation is an operation of simultaneously playing the content data downloaded from the content server 10 to the first content cache L1 while copying it to the second content cache L2. Note that the content data is written in the second content cache L2 by performing the download reproduction operation. The content data written in the second content cache L2 can be reproduced by the cache reproduction operation.

  As shown in FIG. 8, the cache playback operation enables playback of content even when network communication cannot be performed by using content data written in the second content cache L2. It is an operation.

  Next, the operation of the content cache management unit 190 in this embodiment will be described in comparison with the prior art.

  In the prior art, depending on whether or not the content to be reproduced exists in the content cache, either the reproduction of the download data (= writing to the content cache) or the reproduction of the cache data (= reading of the content cache) Was moving. Here, the reproduction of the download data is classified into one of a download reproduction method and a streaming reproduction method, if further classified.

  The download reproduction method is a reproduction method in which the downloaded content data is first written in the content cache, and when the download of one song is completed, the reproduction of the downloaded content is started. The streaming playback method is a playback method for playing back the downloaded content at the same time as downloading the content data. Regardless of which playback method is used, it is necessary to always write the content data to be played back to the content cache.

  Here, let us consider a case where content having a high reproduction frequency is written in the content cache and a content having a low reproduction frequency and no cache data exists in the content cache. If there is enough free space for the content data downloaded in the content cache, the downloaded data is simply written into the content cache, and there is no problem.

  On the other hand, if there is not enough free space in the content cache, the LRU method first deletes the most recently played content among all the content existing in the content cache, and then downloads the downloaded content to the content cache. Will write to. However, as a result, it happened that at some point it was played back, but in the long run, content with a low playback frequency would kick out content with a high playback frequency from the content cache. For this reason, the hit rate of the content cache is lowered, and as a result, the amount of communication data is wasted. The main factor causing such an operation is that the content reproduction history information (reproduction date / time, number of reproductions / reproduction frequency, etc.) is maintained only for the content existing in the content cache. .

  On the other hand, in the content cache management unit 190 of this embodiment, in addition to whether or not the content to be reproduced exists in the content cache unit 160, the reproduction frequency value of the content to be reproduced and the content of each content in the content cache unit 160 By comparing the reproduction frequency values, either on-the-fly reproduction (the second content cache L2 is not used) (FIG. 6) or download reproduction (FIG. 7) is performed.

  That is, in this embodiment, when the playback target content does not exist in the content cache unit 160, if the playback frequency value of the playback target content is relatively low, on-the-fly playback (FIG. 6) is performed. Conversely, when the reproduction frequency value is high, download reproduction (FIG. 7) is performed as in the conventional case.

  As described above, in on-the-fly playback, playback is performed while downloading content, but the downloaded content is not written to the nonvolatile second content cache L2. With the introduction of this on-the-fly playback, it is possible to prevent a situation in which content with a higher playback frequency is deleted from the second content cache L2 by accidentally playing back a content with a lower playback frequency. As a result, the hit rate of the second content cache L2 is improved, and the amount of communication data can be further saved.

  In the present embodiment, the content history information (reproduction date / time / number of reproduction / reproduction frequency, etc.) to be maintained can be all content existing in the content server 10. If there are a plurality of content servers (cloud storage), it is possible to maintain and manage the reproduction history information for all the contents integrated with the contents held by each content server.

However, it is not always necessary that the content reproduction history information (reproduction date / time / number of reproductions / reproduction frequency, etc.) is maintained, and it can be considered as follows.
Content held in content cache unit 160: A
-All contents registered in the content server 10: B
-Content holding playback frequency information: X
In this case, the reproduction frequency condition may be held under such a condition that the relationship of “A <X ≦ B” is satisfied.

(Operation of the first embodiment)
Next, the operation of this embodiment will be described with reference to FIGS. FIG. 9 is a sequence diagram showing the operation of the present embodiment. FIG. 10 is a list of examples of interface commands exchanged between components in the sequence of FIG. FIGS. 11 to 28 are flowcharts showing details of main threads in FIG. Hereinafter, the flowcharts of FIGS. 11 to 28 will be described with reference to FIGS. 9 and 10.

<Main thread: Fig. 11>
The main thread of the main controller 110 will be described with reference to FIG. First, execution of the playback processing thread of the main controller 110 is started (step S102). This process will be described later with reference to FIG. Subsequently, execution of the UI processing thread of the main controller 110 is started (step S104). This process will be described later with reference to FIG. Furthermore, the execution of the main thread of the content cache management unit 190 is started (step S106). This process will be described later with reference to FIG.

  In addition, it supplements about a thread here. In the case of a subroutine that has been frequently used in the past, for example, when a subroutine is called from a main routine, the execution of the subroutine is stopped while the subroutine is being executed while the subroutine is being executed. When finished, the operation of the main routine is resumed. That is, in the case of a subroutine, the calling process (in this example, the main routine) and the called process (in this example, the subroutine) are not executed at the same time. On the other hand, in the case of a thread, for example, when an instruction to start execution of another thread is issued from the main thread, the process on the call side (main thread in this example) and the process on the called side (in this example, another thread) are performed concurrently. There is a difference that it is executed.

  Subsequently, it is determined whether or not to update the content reproduction frequency value (or the reproduction probability expected value) (step S108). Note that in the second embodiment described later, the content reproduction frequency value is read as the reproduction probability expected value. The same applies hereinafter.) As a specific execution timing of this determination, for example, it can be automatically executed about once a day. This is because the “current date and time” is referred to when calculating the content reproduction frequency value (or reproduction probability expected value) (hereinafter referred to as “score”), and the score value changes with the passage of time. However, even if this update process is performed too frequently, it will only use up the battery of the mobile device unnecessarily, so consider the balance between battery consumption and keeping the score value as correct as possible. Must be set.

  If the content playback frequency value (or predicted playback probability value) is to be updated as a result of the determination in step S108, execution of an update processing thread for the content playback frequency value (or predicted playback probability value) is started (step S110). Then, the process returns to step S108.

  On the other hand, if the content reproduction frequency value (or the reproduction probability expected value) is not updated as a result of the determination in step S108, it is determined whether to update the content database 170 (step S112). As a specific execution timing of this determination, for example, it may be automatically executed about once a month, or may be executed when the user manually instructs “update of the content database 170”. In order to update the content database 170, it is necessary to access content files on the content server 10 via the Internet. Therefore, if the content database 170 is updated unnecessarily, valuable mobile communication data amount is wasted. End up. Therefore, it is highly likely that the automatic execution of this update process is not a preferable operation for a user who uses a communication service with an upper limit on the amount of mobile communication data. Therefore, it is preferable to provide a setting unit for determining whether or not to automatically update the content database 170 so that the user can select it.

  If the content database 170 is updated as a result of the determination in step S112, execution of the update processing thread of the content database 170 is started (step S114). Then, the process returns to step S108. On the other hand, if the content database 170 is not updated as a result of the determination in step S112, the process directly returns to step S108.

<UI processing thread (FIG. 12)>
The UI processing thread of the main controller 110 activated in step S104 of FIG. 11 will be described with reference to FIG.

  First, an artist list is obtained by referring to the artist table of the content database 170 (step S202). The SQL sentence at this time is as shown in FIG. Then, the artist list is displayed on the screen display unit 140 (step S204). Then, it waits for an artist to be selected (step S206). When a certain artist is selected, an album whose artist_id matches the artist selected by the user is searched in the album table to obtain an album list (step S208). The SQL sentence at this time is as shown in FIG. Then, the album list is displayed on the screen display unit 140 (step S210).

  If “return to the previous screen” is selected (step S212), the process returns to step S202. If “Return to previous screen” is not selected and a certain album is not selected (step S214), the process returns to step S212. If a certain album is selected, album_id is selected by the user in the song table. Is retrieved to obtain a song list (step S216). The SQL sentence at this time is as shown in FIG. Then, the song list is displayed on the screen display unit 140 (step S218).

  When “return to the previous screen” is selected (step S220), the process returns to step S208. If “return to the previous screen” is not selected and playback of a certain song is not instructed (step S222), the process returns to step S220. If playback of a certain song is instructed, based on the selected album and the selected song Then, a playlist notification is created (step S224). Further, a playlist notification is issued to the reproduction processing thread (step S226). The playlist notification contents at this time are as shown in FIG. Then, a reproduction start request is issued to the reproduction processing thread (step S228). The content of the reproduction start request at this time is as shown in FIG.

<Reproduction processing thread (FIG. 13)>
The reproduction processing thread of the main controller 110 activated in step S102 of FIG. 11 described above will be described with reference to FIG.

  First, a request message from another module / thread is received (step S302). It is determined whether a request message has been received (step S304). If not received, the process returns to step S302. If received, the message content is determined (step S306). The message content is any one of “playlist request”, “reproduction start request”, “reproduction stop request”, and “content reproduction end notification”, and the following processing is performed according to the message content.

  If the message is “playlist notification”, a playlist notification is issued to the main thread of the content cache management unit 190 (step S308). The playlist notification contents at this time are as shown in FIG. If the message is a “reproduction start request”, the reproduction of the content is started by calling the sound reproduction API provided by the sound service and passing the URL of the content to be reproduced (step S310). The sound service acquires content data to be played back by issuing a “GET” request to the content cache management unit using the http protocol. The content request contents at this time are as shown in FIG. If the message is “reproduction stop request”, the sound reproduction API is called to stop the reproduction of the content (step S312).

  If the message is a “content reproduction end notification”, it is determined whether reproduction of all contents in the playlist has been completed (step S314). When the reproduction of all the contents of the playlist is completed, the process returns to step S302. If the reproduction of all the contents in the playlist has not been completed, a playlist in which the content to be reproduced is changed to the next content is created (step S316). Further, the play list is notified to the main thread of the content cache management unit 190 (step S318), the sound reproduction API is called, and the URL of the next content to be reproduced is passed to start reproduction of the next content (step S318). S320).

  The operation of the main controller 110 has been described above. Hereinafter, the operation of the content cache management unit 190 will be described.

<Main thread: Fig. 14>
First, execution of the prefetch thread of the content cache management unit 190 is started (step S402). This process will be described later with reference to FIG. Next, a request message from another module / thread is received (step S404). While the request message is not received, the process returns to step S404. When the request message is received, the content of the message is determined (step S408).

  If the content of the message is “playlist notification”, the song existing in the second content cache L2 is removed from the song_list [] of the playlist notification, and a content prefetch request is created (step S410). Then, a content prefetch request is issued to the prefetch thread (step S412). The content prefetch request content at this time is as shown in FIG.

On the other hand, if the content of the message is “content request”, first, the following operation is performed on the record whose id in the song table matches req_song_id (step S414).
play_date2 ← play_date1
play_date1 ← current date and time Note that req_song_id referred to here means a value obtained by converting a character string of <req_song_id> included in the URL of FIG.

  Subsequently, it is determined whether the entire requested content exists in the second content cache L2 (step S416). If the requested content is entirely present in the second content cache L2, the execution of the cache playback thread is started (step S418). This operation will be described later with reference to FIG. Then, the process returns to step S404. On the other hand, when the entire requested content does not exist in the second content cache L2, the execution of the download / on-the-fly playback thread is started (step S420). This operation will be described later with reference to FIG. Then, the process returns to step S404.

<Prefetch thread: FIG. 15>
The prefetch thread activated in step S402 in FIG. 11 described above will be described with reference to FIG. First, a request message from another module / thread is received (step S502). Then, it is determined whether a request message has been received (step S504).

  If a request message is received in step S504, the message content is determined (step S506). If the message content is “download completion notification”, the downloaded data is written to the chunk buffer of chunk_id = cur_chunk_id (step S508). This operation corresponds to the operation (1) in FIGS. And it progresses to step S526 mentioned later.

On the other hand, if the message content is “content prefetch request”, first, the following processing is performed, and the index value in song_list [] of the next song to be downloaded is set to next_song_index (step S510).
next_song_index ← play_index
next_chunk_no ← 1
Then, it is determined whether the chunk data of the content is being downloaded (step S512). If not being downloaded, the process proceeds to step S526 described later. If the download is in progress, the next download chunk determination process is first performed in order to confirm whether or not the prefetched content has been changed (step S514). This process will be described later with reference to FIG.

  Next, it is determined whether next_song_id = cur_song_id (step S516). If next_song_id = cur_song_id, it is further determined whether next_chunk_id = cur_chunk_id (step S518). It is determined that there is no error, and the process returns to step S502. If next_song_id = cur_song_id is not satisfied in step S516, or if next_chunk_id = cur_chunk_id is not satisfied in step S518, it is determined that the prefetched content has been changed, and the chunk data download is interrupted (step S520). Then, the chunk buffer of chunk_id = cur_chunk_id in which halfway content data being downloaded may be written is cleared (step S522). And it progresses to step S526 mentioned later.

  The case where the request message is received in step S504 has been described above. On the other hand, if no request message is received in step S504, it is determined whether chunk data is being downloaded (step S524). If the chunk data is being downloaded, the process returns to step S502. If the chunk data is not being downloaded, the process proceeds to step S526 below.

  In step S526, next download chunk determination processing is performed (step S526). This process will be described later with reference to FIG. Then, it is determined whether there is a chunk to be downloaded (step S528). If there is no chunk to be downloaded, the process returns to step S502. If there is a chunk to be downloaded, an empty chunk buffer search process is performed (step S530). This process will be described later with reference to FIG.

Subsequently, it is determined whether an empty chunk buffer has been found (step S532). If no empty chunk buffer is found, the process returns to step S502. If an empty chunk buffer is found, downloading of chunk data is started (step S534). The download request contents at this time are as shown in FIG. Then, the following processing is performed (step S536), and song_id and chunk_no of the currently downloaded content are stored in cur_song_id / cur_chunk_no.
cur_song_id ← next_song_id
cur_chunk_no ← next_chunk_no

<Next download chunk determination processing: FIG. 16>
The subroutine of the next download chunk determination process called from steps S514 and S526 will be described with reference to FIG.

  First, by setting next_song_id <-song_list [next_song_index], the song_id of the next downloaded song is set to next_song_id (step S602). Then, the L1 cache management table 162 is searched to search for a chunk satisfying the conditions of song_id = next_song_id, chunk_no = next_chunk_no (step S604). The next_song_index referred to here refers to the next_song_index set in step S510. Moreover, song_list [] indicates the parameter song_list [] in FIG.

  Subsequently, it is determined whether there is a chunk that meets the condition (step S606). If the chunk does not exist, it is determined that the next chunk to be downloaded is a chunk corresponding to next_song_id and next_chunk_no, and the process returns to the original step (step S514 or step S526) from this subroutine. If a chunk exists, chunk_no ← chunk_no + 1 is set to advance to the next chunk of the same content (step S608).

Then, it is determined whether or not the end of the content has been reached (step S610). If the end of content has not been reached, the process returns to step S604. When the end of the content is reached, the following processing is performed in order to advance to the next content to be reproduced in the playlist (step S612).
next_song_index ← next_song_index + 1
next_chunk_no ← 1

  Then, it is determined whether there is a next song in song_list [] (step S614). If there is a next song, the process returns to step S602. If there is no next song, it is determined that there are no more chunks to be downloaded, and next_song_id = 0 is returned as the execution result of the next download chunk determination process (step S616).

<Free chunk buffer search processing: FIG. 17>
A subroutine of empty chunk buffer search processing called from step S530 will be described with reference to FIG.

  First, an unused chunk buffer is searched from the L1 cache management table 162 (step S702). Then, it is determined whether there is an unused chunk buffer (step S704). If there is an unused chunk buffer, chunk_id of the found unused chunk buffer is returned (step S706). Then, the subroutine is terminated and the process returns to the original step (step S530).

  On the other hand, if there is no unused chunk buffer in step S704, the chunk belonging to the content not included in the prefetched content list is extracted from the L1 cache management table 162, and the chunk_id of the corresponding chunk buffer is chunk_id_list [ ] (Step S708). Then, it is determined whether chunk_id_list [] is empty (step S710). If chunk_id_list [] is not empty, the process proceeds to step S728 described later.

  If chunk_id_list [] is empty in step S710, the chunk belonging to the reproduced content is extracted from the L1 cache management table 162, and the chunk_id of the corresponding chunk buffer is stored in the chunk_id_list [] array (step S710). S712). Then, it is determined whether chunk_id_list [] is empty (step S714). If chunk_id_list [] is not empty, the process proceeds to step S730 to be described later. In the example of FIG. 10 (h), the reproduced content here is the second song (play_index = 2) to be reproduced next, so the first song (song_id = 1) in song_list [] ) Only applies to played content.

  On the other hand, if chunk_id_list [] is empty in step S714, a chunk belonging to unplayed content and having a playback order after the next downloaded chunk is extracted from the L1 cache management table 162, and the corresponding chunk buffer is extracted. Are stored in the array of chunk_id_list [] (step S716). Then, it is determined whether chunk_id_list [] is empty (step S718). If chunk_id_list [] is not empty, the process proceeds to step S730 to be described later. In the example of FIG. 10 (h), the unreproduced content mentioned here is the second song (play_index = 2) to be reproduced next, so all the songs after the third song in song_list [] Corresponds to unplayed content. Further, it is possible to know which chunk is to be downloaded next by referring to next_song_id holding the song_id of the song to be downloaded next and next_chunk_no holding the chunk number to be downloaded next.

  If chunk_id_list [] is empty in step S718, it is determined whether the next download chunk is a content being played back. Specifically, this determination can be made based on whether the values of next_song_id and req_song_id are equal. Note that req_song_id corresponds to the value acquired in step S414 (step S720). If the next downloaded chunk is the content being played back, the chunk that belongs to the content being played back and whose used field is “1” is extracted from the L1 cache management table 162, and the chunk_id of the corresponding chunk buffer is chunk_id_list. It stores in the array of [] (step S722). Then, it is determined whether or not chunk_id_list [] is empty (step S724). If chunk_id_list [] is not empty, the process proceeds to step S730 to be described later.

  If the next downloaded chunk is not the content being played back in step S720 or if chunk_id_list [] is empty in step S724, “0” (no empty chunk buffer) is returned as the search result of the empty chunk (step S726). Then, the subroutine is terminated and the process returns to the original step (step S530).

  As described above, the case has been described in which no search is made in the available chunk buffer at the time of any of the search in steps S708 / S712 / S716 / S722. On the other hand, if any of the available chunk buffers is found during the search in any of steps S708 / S712 / S716 / S722, the following operation is performed.

  First, if a chunk buffer that can be used at the time of the search in step S708 is found, the chunk_id_list [] is searched for the chunk with the oldest write_date, and its song_id is set to target_song_id (step S728). As a result, among the contents having cache data in the L1 cache, the song_id of the most recently reproduced content is set as the target_song_id. And it progresses to step S734 mentioned later.

  In addition, when a chunk buffer that can be used at the time of the search in steps S712 / S716 / S722 is found, the chunk_id value stored in chunk_id_list [] is converted to song_id by referring to the L1 cache management table and duplicated. The result of deleting the data is stored in song_id_list [] (step S730). Then, the song_id whose download order is farthest from the content being downloaded from the song_id_list [] is set to the target_song_id (step S732). Then, the process proceeds to step S734.

  In step S734, chunks whose song_id matches target_song_id are extracted from chunk_id_list [], and the chunk_id of the chunk having the largest chunk_no is set to free_chunk_id (step S734). As a result, among the chunk data constituting the most recently played content in the L1 cache, the chunk_id of the last chunk in the content is set to free_chunk_id.

  Next, the record corresponding to free_chunk_id is cleared in the L1 cache management table (step S736), and the chunk buffer corresponding to free_chunk_id is further cleared in the L1 cache chunk buffer. It can be used as an empty chunk (step S738). Next, free_chunk_id is returned as an empty chunk search result (step S740). Then, the subroutine is terminated, and the process returns to the original step (step S530).

By sequentially performing the empty chunk buffer search process in this way, the empty chunk buffer is searched as a result of the following priority.
Priority 1: Unused chunk buffer Priority 2: Chunk buffer corresponding to content not included in the pre-read content list Priority 3: Chunk buffer corresponding to played content included in the pre-read content list Priority 4: Chunk buffer corresponding to unplayed content included in the pre-read content list, the chunk buffer having the playback order after the next downloaded chunk Priority 5: In the chunk buffer corresponding to the content being played back Then, the chunk buffer to which chunk data has been sent as a response to the content request (however, the search for priority 5 is performed only when the next downloaded chunk is currently being played back)

  Here, the priority 5 is determined when the length of the song is very long and the entire content data for one song cannot be stored in the L1 cache, the prefetched content data fills the L1 cache chunk buffer. In other words, the content is prepared in order to prevent the content from being prefetched any further, and as a result, the content exceeding the size of the L1 cache cannot be reproduced.

<Cache playback thread: FIG. 18>
The cache playback thread described in step S418 will be described with reference to FIG. The requested content is read from the second content cache L2, and sent as a response to the content request (step S812). This operation corresponds to the operation (4) in FIG.

<Download / on-the-fly playback thread: Fig. 19>
The download / on-the-fly playback thread described in step S420 will be described with reference to FIG. First, play_chunk_no ← 1 is set (step S902). Then, it is determined whether or not play_chunk_no = 1 (step S904). If play_chunk_no = 1 is not true, the process proceeds to step S910 described later. If play_chunk_no = 1, it is determined whether data corresponding to req_song_id exists in the L2-H cache (see FIG. 4) (step S906). When the data corresponding to req_song_id does not exist in the L2-H cache, the process proceeds to step S910 described later. If the data corresponding to req_song_id exists in the L2-H cache, the data at the beginning of the content is read from the L2-H cache and sent as a response to the content request (step S908). And it progresses to step S922 mentioned later.

  In step S910 described above, the L1 cache management table 162 is searched to find a chunk of song_id = req_song_id, chunk_no = play_chunk_no, and the found chunk_id is set to play_chunk_id (step S910). And it is judged whether the chunk was found (step S912). If no chunk is found, the process returns to step S910. If a chunk is found, it is determined whether play_chunk_no = 1 (step S914).

  If play_chunk_no = 1 is not true, the process proceeds to step S918. If play_chunk_no = 1, a write process to the L2-H cache is performed (step S916). This operation will be described later with reference to FIG. Then, the process proceeds to step S918. In step S918, chunk data corresponding to play_chunk_id is sent as a response to the content request (step S918). This operation corresponds to the operation (2) in FIGS. Then, the used field of the record corresponding to play_chunk_id in the L1 cache management table 162 is set to 1 (step S920).

  In S922 described above, it is determined whether an error has occurred during transmission of the response data (step S922). If an error occurs, the subroutine is terminated and the original step is returned. If no error has occurred, chunk_no ← chunk_no + 1 is set (step S924). Then, it is determined whether transmission of all chunks for one song has been completed (step S926). If transmission of all chunks for one song has not been completed, the process returns to step S904. When transmission of all chunks for one song is completed, L2-E cache write processing is performed (step S928). This operation will be described later with reference to FIG. Then, the subroutine ends and the process returns to the original step.

  The switching between the download reproduction operation and the on-the-fly reproduction operation is performed by copying the content data downloaded from the content server from the first content cache L1 to the second content cache L2 in the L2-H cache write processing or the L2-E cache write processing. Depending on whether or not download playback or on-the-fly playback is selected.

<L2-H cache write processing: FIG. 20>
The subroutine of the L2-H cache write process called from step S916 in FIG. 19 will be described with reference to FIG. First, it is determined whether the first chunk of the content being played fits in the free space of the L2-H cache (step S1002). If it falls within the free space, the process proceeds to step S1016. If it does not fit in the free space, the following processing is performed.

  First, the reproduction frequency value (or reproduction probability expected value) (score) of the content being reproduced is calculated (step S1004). This operation will be described later with reference to FIG. Then, out of all the contents existing in the L2-H cache, all contents having a score lower than the content being reproduced are extracted, and the song_id / score / filesize pair of the extracted contents is stored in the array of delete_candidate []. Store (step S1006). Next, the contents of delete_candidate [] are sorted in ascending order of score (step S1008). Then, it is determined how many songs from the beginning of delete_candidate [] can be deleted and the beginning of the content being reproduced can be stored in the L2-H cache, and the song_id of the content that needs to be deleted is stored in delete_song_id [] (Step S1010).

  Next, it is determined whether even if all songs of delete_candidate [] are deleted, they do not fit in the L2-H cache (step S1012). If it does not fit in the L2-H cache, the subroutine ends and the process returns to the original step (step S916). If it fits in the L2-H cache, the content specified by delete_song_id [] is deleted from the L2-H cache (step S1014). Then, the process proceeds to step S1016.

  In step S1016 described above, only the first chunk of the content being reproduced is read from the first content cache L1 and written to the L2-H cache (step S1016). This operation corresponds to the operation (3) in FIG. When step S1016 is finally executed in the L2-H cache write process, the download reproduction operation is performed. Conversely, if step S1016 is not executed, an on-the-fly reproduction operation is performed.

<L2-E cache write processing: FIG. 21>
The subroutine of the L2-E cache write process called from step S928 in FIG. 19 will be described with reference to FIG. First, it is determined whether the entire content being played fits in the free capacity of the L2-E cache (step S1102). If it falls within the free space, the process proceeds to step S1116. If it does not fit in the free space, the following processing is performed.

  First, the reproduction frequency value (or reproduction probability expected value) (score) of the content being reproduced is calculated (step S1104). This operation will be described later with reference to FIG. Then, out of all the contents existing in the L2-E cache, all contents whose score is lower than the contents being reproduced are extracted, and the song_id / score / filesize pair of the extracted contents is stored in the array of delete_candidate []. Store (step S1106). Next, the contents of delete_candidate [] are sorted in ascending order of score (step S1108). Then, it is determined how many songs are deleted from the beginning of delete_candidate [] and the content being reproduced can be stored in the L2-E cache, and the song_id of the content that needs to be deleted is stored in delete_song_id [] (step S1108). ).

  Next, it is determined whether or not all songs in delete_candidate [] can be stored in the L2-E cache even if they are deleted (step S1112). If it does not fit in the L2-E cache, the subroutine ends and the process returns to the original step (step S928). If it fits in the L2-E cache, the content specified by delete_song_id [] is deleted from the L2-E cache (step S1114). Then, the process proceeds to step S1116.

  In step S1116 described above, all chunk data corresponding to the content being reproduced is read from the first content cache L1, and the combined data is written in the L2-E cache (step S1116). This operation corresponds to the operation (3) in FIG. When step S1116 is finally executed in the L2-E cache write process, the download reproduction operation is performed. Conversely, if step S1116 is not executed, the on-the-fly reproduction operation is performed.

<Content Reproduction Frequency Value Calculation Processing: FIG. 22>
A subroutine of the above-described content reproduction frequency value calculation process will be described with reference to FIG. First, the current date is set in now_date (step S1202).
now_date ← current date Then, it is determined whether date information exists in play_date2 (step S1204). If date information does not exist in play_date2, score ← −1 is set (step S1206). And it progresses to step S1212 mentioned later.

On the other hand, if date information exists in play_date2, the following processing is performed (steps S1208 and S1210).
diff ← max (play_date1- play_date2, now_date-play_date1)
score ← max (365-diff, 0) / 365 * 100
Then, the process proceeds to step S1212.

  In step S1212, the score value is returned (step S1212). Then, the subroutine ends and the process returns to the original step.

<Content reproduction frequency value update processing thread: FIG. 23>
The content reproduction frequency value update processing thread activated in step S110 of FIG. 11 described above will be described with reference to FIG. First, id ← 1 is set (step S1302). Then, the record corresponding to id is extracted from the L2-H cache management table, and its song_id is obtained (step S1304).

  Next, it is determined whether or not song_id is empty (step S1306). If song_id is empty, the process proceeds to step S1316 described below. If song_id is not empty, a record whose id matches song_id is found from the song table of the content database 170, and the reproduction history information of the content is obtained (step S1308). Then, it is determined whether date information exists in play_date2 (step S1310). If there is no date information in play_date2, the process immediately proceeds to step S1316 described later.

  If date information exists in play_date2, a content reproduction frequency value (score) is calculated (step S1312). Then, the score field of this record is updated (step S1314). Then, the process proceeds to step S1316.

  In step S1316, id ← id + 1 is set (step S1316). Then, it is determined whether processing of all records is completed (step S1318). If all the records have not been processed, the process returns to step S1304. When all the records have been processed, the same processing as described above is performed for the L2-E cache management table.

  The operation of the content cache management unit 190 has been described above. Hereinafter, the operation of the content database update unit 180 will be described.

<Update Thread for Content Database 170: FIG. 24>
The update processing thread of the content database 170 will be described with reference to FIG. First, an array of artist_exist [], album_exist [], song_exist [] is secured on the main memory (step S1402). Then, artist_exist [], album_exist [], and song_exist [] are cleared to 0 (step S1404).

  In the following order, directory search processing (search target = root directory) (step S1406), unnecessary record deletion processing: artist table (step S1408), unnecessary record deletion processing: album table (step S1410), unnecessary record deletion processing: song table ( Step S1412) is performed. These processes will be described later with reference to FIGS. Finally, artist_exist [], album_exist [] and song_exist [] are released (step S1414).

<Directory search processing: FIG. 25>
The directory search process will be described with reference to FIG.
First, a search for a file / directory existing in a search target directory is started (step S1502). Then, the next file name or directory name is obtained (step S1504). Then, it is determined whether or not the file was found (step S1506). If the found directory is not a file but a directory, directory search processing is executed on the directory by recursive calling (step S1508). If the file is found, proceed to the following process.

  First, the contents of the content file are read to obtain artist / album / title / trackno (step S1510). Next, it is determined whether or not the artist acquired from the content file is a new artist (step S1512). If the artist is a new artist, a new record is added to the artist table, and the id of the added record is set to artist_id (step S1514). If it is not a new artist, the artist table is searched to find a record with a matching artist name, and its artist_id is obtained (step S1516). Then, artist_exist [artist_id] ← 1 is set (step S1518).

  Next, it is determined whether the album acquired from the content file is a new album (step S1520). If it is a new album, a new record is added to the album table, and the id of the added record is set to album_id (step S1522). If the album is not a new album, the album table is searched to find a record whose artist_id and album name match, and the album_id is obtained (step S1524). Thereafter, album_exist [album_id] ← 1 is set (step S1526).

  Next, it is determined whether the title acquired from the content file is a new song (step S1528). If it is a new song, a new record is added to the song table, and the id of the added record is set to song_id (step S1530). If it is not a new song, the aong table is searched to find a record whose title matches artist_id / album_id, and the song_id is obtained (step S1532). Thereafter, song_exist [song_id] ← 1 is set (step S1534).

  Finally, it is determined whether the directory search is completed (step S1536). If the directory search has not ended, the process returns to step S1504. When the directory search is completed, the subroutine ends and the process returns to the original step.

<Unnecessary record deletion processing: artist table: FIG. 26>
The unnecessary record deletion processing subroutine called from step S1408 of FIG. 24 will be described with reference to FIG.
First, id ← 1 is set (step S1602). Then, it is determined whether artist_exist [id] = 0 (step S1604). If artist_exist [id] = 0 is not satisfied, the process immediately proceeds to step S1608. If artist_exist [id] = 0, the record corresponding to id in the artist table is cleared (step S1606), and the process proceeds to step S1608.

  In step S1608, id ← id + 1 is set (step S1608). Finally, it is determined whether processing of all records has been completed (step S1610). If all the records have not been processed, the process returns to step S1604. If all the records have been processed, the subroutine ends and the process returns to the original step (step S1408).

<Unnecessary record deletion processing: album table: FIG. 27>
A subroutine for deleting unnecessary records in the album table called from step S1410 in FIG. 24 will be described with reference to FIG.
First, id ← 1 is set (step S1702). Then, it is determined whether album_exist [id] = 0 (step S1704). If album_exist [id] = 0 is not satisfied, the process immediately proceeds to step S1708. If album_exist [id] = 0, the record corresponding to id in the album table is cleared (step S1706), and the process proceeds to step S1708.

  In step S1708, id ← id + 1 is set (step S1708). Finally, it is determined whether processing of all records is completed (step S1710). If all the records have not been processed, the process returns to step S1704. If all the records have been processed, the subroutine ends and the process returns to the original step (step S1410).

<Unnecessary record deletion processing: song table: FIG. 28>
The subroutine for the unnecessary record deletion processing of the song table called from step S1412 in FIG. 24 will be described with reference to FIG.
First, id ← 1 is set (step S1802). Then, it is determined whether or not song_exist [id] = 0 (step S1804). If song_exist [id] is not 0, the process immediately proceeds to step S1808. If song_exist [id] = 0, the record corresponding to id in the song table is cleared (step S1806), and the process proceeds to step S1808.

  In step S1808, id ← id + 1 is set (step S1808). Finally, it is determined whether all records have been processed (step S1810). If all the records have not been processed, the process returns to step S1804. If all the records have been processed, the subroutine ends and the process returns to the original step (step S1412).

(Effects of the first embodiment)
As described above, according to the present embodiment, by switching automatically between on-the-fly playback and download playback according to the content playback frequency, by playing content with low playback frequency by chance, the playback frequency is increased. It is possible to prevent a situation in which a high content is deleted from the content cache unit 160. As a result, the hit rate of the content cache unit 160 is improved, and the amount of communication data can be further saved. In this way, it is possible to provide the content reproduction apparatus 100 that improves the usability of the cloud-type music reproduction application.

  In addition, since it is possible to prevent the music data that has been played after a long absence but is unlikely to be heard for a while from being stored in the content cache unit 160, a memory with a limited number of rewrites (for example, NAND-Flash) The number of times of writing to the memory) can be suppressed (in addition, the mobile terminal becomes a failure state and becomes unusable when the built-in NAND-Flash memory reaches the end of its life). As a result, the usable years of the mobile terminal can be extended.

  The content reproduction apparatus 100 described above can cause a computer to function as the content reproduction apparatus 100 by applying a program to the computer. This computer program can be distributed in the form recorded on an arbitrary recording medium, and can be distributed via the network or distributed in other forms.

(Second Embodiment)
Next, a second embodiment of the present invention will be described. In the present embodiment, the description will focus on differences from the first embodiment, and the same reference numerals are used to designate substantially the same contents as in the first embodiment, thereby providing a duplicate description. Is omitted.

  In the first embodiment, whether to perform download reproduction or on-the-fly reproduction is determined based on the content reproduction frequency. In the present embodiment, for this determination, an expected value (probability of reproduction probability) of the probability that the content is reproduced again is used. Hereinafter, as an example of the predicted reproduction probability, a case will be described in which determination is made based on the date and time (content freshness information) when the content is registered in the content server 10 in addition to the reproduction frequency of each content.

  The reproduction probability prediction information of the present embodiment is a further development of the reproduction frequency information of the first embodiment. Fields “write_date”, “play_date1”, and “play_date2” exist in the structure of the song table shown in FIG. “Write_date” holds the date and time (content freshness information) when the content was registered in the content server. Therefore, valid values are written in the “write_date” fields of all contents. On the other hand, when the content is registered in the content server 10, the contents of the “play_date1” and “play_date2” fields are empty. When a certain content is reproduced, the content of “play_date1” is copied to “play_date2”, and the date and time at the time of reproduction is written to “play_date1”. Therefore, when the content registered in the content server 10 is reproduced for the first time, a valid value is written only in “play_date1”, and “play_date2” is empty.

In the first embodiment, the reproduction frequency information is
-Content that has never been played: score = -1
・ Content played for the first time: score = -1
-Content played more than once: score = 100-0
Will be calculated. Therefore, in the first embodiment, with respect to content that can be played back more than once and that can be played back, information with higher playback frequency is preferentially stored in the content cache unit 160. Operation can be realized.

  However, when a new content (new music in the case of music) is newly registered in the content server 10 and then the content is reproduced for the first time, the score value is calculated to be the lowest -1. Therefore, since the score value of the content does not exceed the score value of any old content for which the reproduction frequency can be obtained while being registered in the content server 10, the new content is reproduced for the first time as a result. In such a case, the content is never stored in the content cache unit 160, and is only stored in the content cache unit 160 when the content is reproduced for the second time. For this reason, there is a possibility that a limited communication band is wasted.

In this regard, the predicted reproduction probability of the present embodiment is calculated by the following program. The score value indicates the reproduction probability, and the larger the value, the higher the reproduction probability.
if play_date2! = ""
then
diff = max (play_date1-play_date2, now_date-play_date1)
score = max (365-diff, 0) / 365 * 100
else
score = -1
diff = now_date-write_date
bonus = max (30-diff, 0) / 30 * 100
score = score + bonus

  The bonus value is a bonus score added to the score value, and is calculated according to the difference in days between the date and time “write_date” when the new content is registered in the content server 10 and the current date and time “now_date”. A value of ~ 0. When the content is reproduced within 30 days after the content is registered in the content server 10, a bonus value corresponding to the number of days difference between “write_date” and “now_date” is calculated. The bonus value is 100 when a new content is registered, and the bonus value decreases as the number of days elapses. The bonus value becomes 0 when 30 days elapse.

  As described above, in this embodiment, the period during which the bonus value is generated is set to 30 days, but this means that new content is still played only once within one month after registration in the content server. Even if there is no history, since the reproduction probability value score is a positive value, the possibility of being stored in the content cache unit 160 increases. However, in the case where there is only one reproduction history even after one month has elapsed after registration of new content, the bonus value is not added. This allows content caches to be played indefinitely for content that the user has played only once and never played back repeatedly (this is probably content that does not match the user's preferences and is not willing to repeat) It is possible to prevent the portion 160 from being left. As a result, the limited capacity of the content cache unit 160 can be used effectively.

  Next, differences from the prior art will be described. In the prior art, when the content cache is full, the content to be deleted is determined based on the date and time when the content was written to the content cache.

  On the other hand, in the present embodiment, when selecting the content to be deleted when the content cache unit 160 is full, in addition to the reproduction frequency of each content, the date and time (content freshness information) when the content was registered in the content server 10 is displayed. It is characterized by being used as a judgment condition. For example, assume that a new song is released and the content data is added to the content server 10. At this time, a record indicating the new song (data for one row in the table) is added to the song table (FIG. 5D) of the content database 160, and the registration date and time of the content is stored in “write_date” of the record. Is written. “Play_date1” and “play_date2” remain blank.

  Next, when the reproduction of this new song is instructed, the date and time at that time is written in “play_date1”. In the present embodiment, as the reproduction frequency of each content, the difference between “play_date1” and “play_date2” and the difference between “now_date” and “play_date1” are compared, and a value calculated from the larger difference value is used. However, when a new song is played for the first time, since a valid value is not written in “play_data2”, it is not possible to obtain the playback frequency of that song. In the first embodiment, content whose playback frequency cannot be calculated is handled as “playback frequency = minimum”. This is because it is not possible to judge whether the content played for the first time at a certain time is likely to be played again and again many times later.

  By handling content whose playback frequency is not required as "playback frequency = low", the old cache (which is unlikely to play the song immediately) is played in a content cache. On the other hand, it is possible to avoid adverse effects caused by writing to the unit 160, but when a new song is played for the first time, the song cannot be written to the content cache unit 160. In general, it is considered that a new song has a higher possibility of being played repeatedly than an old score. Therefore, in order to increase the hit rate of the content cache unit 160, when the new song is played for the first time, the song data is stored in the content cache unit 160 It is desirable to perform an operation of writing to

  In the second embodiment, when “play_date2” of the music to be played is blank, a new score degree value is obtained from the values of “write_date” and “now_date”, and the playback probability is based on the playback frequency value and the new score degree value. By implementing the function of calculating the expected value and comparing the predicted playback probability of the newly played song and the song in the content cache unit 160, the operation of writing the first played new song to the content cache unit 160 is realized. Yes.

(Operation of Second Embodiment)
Next, the operation of the present embodiment will be described with reference mainly to FIGS.
The operation of the present embodiment differs from the operation of the first embodiment (FIGS. 9 to 28) in the following points, and can be the same in other points. That is, in this embodiment, instead of the content reproduction frequency value calculation process (FIG. 22) of the first embodiment, the content reproduction probability expected value calculation process shown in FIG. 29 is performed. Further, instead of the content reproduction frequency value update processing thread (FIG. 23) of the first embodiment, a content reproduction probability expected value update processing thread shown in FIG. 30 is executed. Hereinafter, it demonstrates in order.

<Calculation processing of predicted content reproduction probability: FIG. 29>
The process for calculating the predicted content reproduction probability will be described with reference to FIG. First, the current date is set in now_date (step S1902). Then, it is determined whether date information exists in play_date2 (step S1904). If date information does not exist in play_date2, -1 is set in score (step S1906). And it progresses to step S1916 mentioned later.

On the other hand, if date information exists in play_date2, the following processing is performed (steps S1908 and S1910).
diff ← max (play_date1- play_date2, now_date-play_date1)
score ← max (365-diff, 0) / 365 * 100
Then, the process proceeds to step S1916.

After step S1916, the following processing is performed (steps S1916, S1918, S1920).
diff ← now_date-write_date
bonus ← max (30-diff, 0) / 30 * 100
score ← score + bonus
Then, the process proceeds to step S1922. In step S1922, the score value is returned (step S1922).

<Content Reproduction Probability Expected Value Update Processing Thread: FIG. 30>
The content reproduction probability expected value update processing thread activated in step S114 of FIG. 11 described above will be described with reference to FIG.
First, id ← 1 is set (step S2002). Then, the record corresponding to id is extracted from the L2-H cache management table, and its song_id is obtained (step S2004).

  Next, it is determined whether or not song_id is empty (step S2006). If song_id is empty, the process proceeds to step S2016 described later. If song_id is not empty, a record corresponding to song_id is extracted from the song table of the content database 170, and content history information is extracted (step S2008).

  In step S2012, a predicted content reproduction probability (score) is calculated (step S2012). Then, the score field of the record corresponding to id is updated (step S2014). Then, the process proceeds to step S2016.

  In step S2016, id ← id + 1 is set (step S2016). Then, it is determined whether or not the processing of all records has been completed (step S2018). If all the records have not been processed, the process returns to step S2004. When all the records have been processed, the same processing as described above is performed on the L2-E cache management table.

Hereinafter, a more specific example will be described.
In this embodiment, the date and time (write_date) when the content was written to the content server 10 is used as the content freshness information. Here, for example, consider a case where a certain content is registered in the content server 10 in the following manner.

・ It is assumed that a certain content is released as a new score on December 25, 2015. Release date (1) of content at this time: 2015/12/25.
-On January 15, 2016, the user of the content playback apparatus purchased the content online and saved the downloaded content data in the HDD in the user PC. The file update date / time at this time: 2016/1/15, and the file creation date / time: 2016/1/15.
-On February 1, 2016, the content file stored in the HDD of the user PC was copied to the content server 10. File update date and time (2) at this time: 2016/1/15, file creation date and time (3): 2016/2/1.

  In the above example, the date and time when this content was written to the content server 10 is 2016/2/1 of the above file creation date and time (3).

  When the content server 10 is privately constructed by the user of the content reproduction apparatus, the content registered in the content server 10 is managed based on the user's intention. It is assumed that a user obtains old music data released 20 years ago by some method and registers the content file in the content server 10. In this case, it is probable that the user has registered the content file in the content server 10 that he / she manages, probably because he / she wanted to hear the content. In other words, the content is a novel piece of music equivalent to a new score for this user, and it is likely that the content is likely to be reproduced in the near future.

  In the present embodiment, by using the date and time when the content file is registered in the content server 10 as content freshness information as described above, it is simply determined that the reproduction probability of the music is high because the release date of the music is recent. It is possible to calculate the content reproduction probability that is more in line with the user's feelings than the device.

  The information used as the content freshness information is not limited to the file creation date (3) described above, but is the file update date (2) indicating the date and time when the user obtained the content file, or the content release date ( It is also possible to use 1).

(Effect of 2nd Embodiment)
As described above, according to the present embodiment, there is a high possibility that content (new music in terms of music) with a new registration date and time in the content server 10 is stored in the content cache unit 160. The hit rate is improved, and the mobile communication band can be saved. On the other hand, since the old music that happens to be played after a long time is not cached, the hit rate of the content cache unit 160 is not lowered by playing the old music.

  As mentioned above, although preferred embodiment of this invention was described referring an accompanying drawing, it cannot be overemphasized that this invention is not limited to this example. It will be apparent to those skilled in the art that various changes and modifications can be made within the scope of the claims, and these are naturally within the technical scope of the present invention. Understood.

  For example, in the first embodiment, specific examples and programs for obtaining the reproduction frequency value have been described, but the present invention is not limited to this. As long as the information represents the content reproduction frequency, the reproduction frequency value can be obtained from arbitrary information.

  In the second embodiment, as an example of the predicted playback probability, the case where the content is calculated based on the date and time (content freshness information) registered in the content server 10 and the playback history information of the content has been described. The present invention is not limited to this. As long as the information can predict the reproduction probability, the reproduction probability prediction value can be obtained from arbitrary information.

  Moreover, although the said embodiment demonstrated the mobile device which has a semiconductor memory as the content reproduction apparatus 100, this invention is not limited to this. For example, a semiconductor memory type content playback device from which a semiconductor memory is removed (a so-called cloud type content playback device), an in-vehicle music playback device, a stationary network audio player, or a television with a music playback function In addition, the present invention can be applied to an electronic book reader.

  The present invention can be used for a content reproduction apparatus and a computer program for reproducing content.

DESCRIPTION OF SYMBOLS 10 Content server 100 Content reproduction apparatus 110 Main controller 120 Network communication part 130 Operation detection part 140 Screen display part 150 Music reproduction part 160 Content cache part L1 1st content cache L2 2nd content cache 170 Content database 180 Content database update part 190 Content cache management department

Claims (15)

A content cache unit for storing content;
A content database for holding reproduction frequency information for calculating the reproduction frequency of content registered in a content server on the cloud;
A content cache management unit for managing the content cache unit;
With
The content cache management unit
Based on the playback frequency information of the content to be played back, on-the-fly playback operation for playing back the content on the content server in real time and simultaneously writing the content data downloaded from the content server into the content cache unit A content reproduction apparatus, characterized by switching between a download reproduction operation for performing reproduction. A content cache unit for storing content;
A content database that holds reproduction probability prediction information for predicting the reproduction probability of content registered in a content server on the cloud;
A content cache management unit for managing the content cache unit;
With
The content cache management unit
Based on the reproduction probability prediction information of the content to be reproduced, on-the-fly reproduction operation for reproducing the content on the content server in real time, and writing the content data downloaded from the content server to the content cache unit A content playback apparatus that switches between a download playback operation that performs playback simultaneously.   3. The content reproduction apparatus according to claim 1, wherein the content cache unit records data separately for a head portion of each content and a remaining portion other than that.   4. The content reproduction apparatus according to claim 3, wherein, in the content cache unit, when the capacity becomes full, the remaining portion of each content is deleted first. In the content cache unit,
The capacity of the head part cache for storing the head part of each content and the capacity of the remaining part cache for storing the remaining part of each content are separately managed,
4. The content reproducing apparatus according to claim 3, wherein when the capacity is full, the unnecessary data is deleted independently in the head partial cache and the remaining partial cache. The content cache unit
A first content cache for storing content most likely to be played by the user most recently;
A second content cache for storing content that the user is likely to play again at a later date;
The content playback apparatus according to claim 1, wherein the content playback apparatus includes:   The content reproduction apparatus according to claim 6, wherein only content related to the content being reproduced is stored in the first content cache.   8. The content reproduction apparatus according to claim 7, wherein the first content cache is configured by a volatile memory.   8. The content reproduction apparatus according to claim 7, wherein the data management unit in the first content cache is a chunk unit obtained by further dividing one content. In the second content cache, only content that is likely to be played back at a later date is stored,
The content playback apparatus according to any one of claims 6 to 9, wherein an algorithm different from that of the first content cache is adopted as a cache management algorithm in the second content cache.   The content reproduction apparatus according to claim 10, wherein the second content cache is configured by a nonvolatile memory as a data storage destination.   12. The content reproduction apparatus according to claim 10, wherein a data management unit in the second content cache is a content unit.   The content reproduction apparatus according to any one of claims 6 to 12, wherein capacities of the first content cache and the second content cache can be individually set.   The content playback apparatus according to claim 1, wherein the content database holds integrated content list information obtained by integrating content list information of a plurality of content servers.   A computer program for causing a computer to function as the content reproduction apparatus according to claim 1.