Patent Publication Number: US-11030283-B2

Title: Media content management

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of and claims the benefit of U.S. patent application Ser. No. 16/681,598, filed Nov. 12, 2019, titled “SYSTEMS AND METHODS FOR CONTENT METADATA MANAGEMENT,” which is a continuation-in-part of and claims the benefit of U.S. patent application Ser. No. 15/831,128, filed Dec. 4, 2017, titled “DIGITAL VAULT FOR MUSIC OWNERS,” which is a continuation-in-part of and claims the benefit of U.S. patent application Ser. No. 15/430,871, issued as U.S. Pat. No. 9,836,619, filed Feb. 13, 2017, titled “DIGITAL VAULT FOR MUSIC OWNERS,” each of which is hereby incorporated by reference in their entirety as if reproduced in full below. This application also claims the benefit of U.S. Patent Application No. 62/872,348, filed on Jul. 10, 2019, titled “SYSTEMS AND METHODS FOR CONTENT METADATA MANAGEMENT,” which is which is incorporated herein by reference in its entirety. 
    
    
     TECHNICAL FIELD 
     The disclosed technology relates generally to media content files, and more particularly, some embodiments relate to containers for media content and associated content metadata. 
     DESCRIPTION OF THE RELATED ART 
     The recording industry has struggled for many years with problems associated with keeping track of records associated with audio recordings. Record labels, licensing companies, publishers and other industry participants have been known to spend months, and sometimes years, tracking down music rights information and other records associated with audio recordings. Also, the industry in general and the artist themselves have often struggled with keeping track of who contributed to the creation of a song or who should otherwise have certain rights. These issues are not limited to audio recordings and can span other media content as well. 
     The foregoing issues can lead to difficulties when licensing content for use by third parties, difficulties recognizing and compensating artists for their contribution to content, difficulties with version control for content items, and difficulties keeping track of pertinent content information in general. 
     The media content industry has yet to arrive at an acceptable solution, leading to critical data being lost or untraceable and in some cases the loss of rights. Current manual techniques for addressing metadata have proven unsuccessful as oftentimes metadata is either lost or incomplete, or not collected in the first place. Participants such as content creators and publishers are also often unaware of the types of information that needs to be collected and maintained along with their content. Accordingly, much time is often spent after the fact attempting to locate and gather this information. In some instances, the information is no longer available due to the amount of time that has passed. 
     BRIEF SUMMARY OF EMBODIMENTS 
     According to various embodiments of the disclosed technology, systems and methods may be implemented to create, manage and share one or more content items, along with metadata or other related files associated with those content items such as, for example, in a portable physical file that can be exported. The system may be implemented to create a container to contain one or more content items and associated metadata. The system may be further implemented to verify the completeness of metadata files associated with content items in the containers, alert appropriate users if specified metadata files are missing from a container, and allow users to update the metadata to complete the containers. 
     Some or all of the metadata information pertaining to a song/single, EP or album (or other content) can be shared, copied or transferred by generating a container file that includes the media file (e.g., audio/video), metadata and all other related assets encapsulated in one secure file. Information and assets may be stored either directly in the file or using an identifier or link that identifies the data stored on a server. Information and assets can also be viewed and managed either through a web portal and application utilizing a network connection to a server, or via native application on a user device that will access and update the data stored in the file or a combination of both. 
     Various embodiments can be implemented to address problems in the media content industry such as keeping track of records regarding items such as, for example, creators and co-collaborators, performers and other artists, media rights information, version control, copyright information, recognition of rights information, and so on. Embodiments may be implemented to effectively track all who contributed to an item of media content and capture the nature of their contribution. This can help to avoid issues with recognizing the wrong individuals or failing to recognize actual contributors. Embodiments provide systems and methods to solve problems in the industry that have yet to be solved and to accomplish this using novel processes for receipt, management, sharing and tracking of media content items and their associated metadata including, for example, novel files and file structures, novel data capture and storage techniques, novel metadata checking, and so on. 
     Other features and aspects of the disclosed technology will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate, by way of example, the features in accordance with embodiments of the disclosed technology. The summary is not intended to limit the scope of any inventions described herein, which are defined solely by the claims attached hereto. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The technology disclosed herein, in accordance with one or more various embodiments, is described in detail with reference to the following figures. The drawings are provided for purposes of illustration only and merely depict typical or example embodiments of the disclosed technology. These drawings are provided to facilitate the reader&#39;s understanding of the disclosed technology and shall not be considered limiting of the breadth, scope, or applicability thereof. It should be noted that for clarity and ease of illustration these drawings are not necessarily made to scale. 
         FIG. 1  illustrates an example diagram of a system for controlled distribution of digital music. 
         FIG. 2  illustrates an example block diagram of a digital vault for music owners. 
         FIG. 3  illustrates an example flowchart of a method of a music owner controlling distribution of music. 
         FIG. 4  illustrates an example flowchart of a method of a reviewing user receiving controlled distribution of music. 
         FIG. 5  illustrates an example block diagram of a computing device. 
         FIG. 6  illustrates an example container-based content management system in accordance with one embodiment. 
         FIG. 7  illustrates a high level example of a creator accessing a content management system to create and store a container file in accordance with one embodiment. 
         FIG. 8  illustrates an example process for content management using a container file in accordance with one embodiment. 
         FIG. 9  illustrates an example creation of a content container in accordance with one embodiment. 
         FIG. 10  illustrates an example process for creating a container in accordance with one embodiment. 
         FIG. 11  illustrates an example UI for an application for a content management system in accordance with one embodiment. 
         FIG. 12  illustrates an example UI for a container viewer in accordance with one embodiment. 
         FIG. 13  illustrates an example scenario of collaborative music creation in a cloud environment in accordance with one embodiment. 
         FIG. 14  illustrates an example process for collaborative music creation in accordance with the example of  FIG. 13 . 
         FIG. 15  illustrates an example scenario of music creation in a local environment in accordance with one embodiment. 
         FIG. 16  illustrates an example process for music creation in accordance with the example of  FIG. 15 . 
         FIG. 17  illustrates an example scenario of hybrid music creation in which multiple creators create content in a cloud-based environment and another collaborator performs content creation in a local environment. 
         FIG. 18  illustrates an example description of a descriptor file for contents of a container in accordance with one embodiment 
         FIG. 19  illustrates an example of a container stored in a data store in accordance with one embodiment. 
         FIG. 20  illustrates an example file structure that can be used for a container file  612  in accordance with one embodiment. 
         FIG. 21  illustrates examples of different forms of container storage. At  1332 , a fully encapsulated container  612  is illustrated. 
     
    
    
     The figures are not exhaustive and do not limit the disclosure or the disclosed embodiments to the precise form disclosed. 
     DETAILED DESCRIPTION OF THE EMBODIMENTS 
     According to various embodiments of the disclosed technology, systems and methods may be implemented to create, manage and share one or more content items, along with metadata or other related files associated with those content items such as, for example, in a portable physical file that can be exported. The content items may include, for example, recorded audio files, video files, images, or other electronically capturable or storable content. The file, or container, in which a content item and its associated files are kept may be maintained, for example, as a portable, physical file (e.g., on a flash drive, on a disk, or as a file in memory or on disk on a server or other computing system) that the owner can share with others. 
     The information stored in the container may be one or more content items of various types and related files themselves, it may be in the form of links to the data or files stored elsewhere, it may be a link to third party data or services, or it may be a combination of the foregoing. Third party data and services might include, for example, the IRS, streaming services (e.g., Spotify, Pandora, etc.), Performance Rights Organizations (PROs), Soundexchange, the Copyright Office, or other third party resources. The container can be secured such as, for example, by encrypting the files stored on the container or otherwise using access-control techniques to keep the file and its contents from being accessed by unintended recipients. 
     Embodiments also provide an interface for the user to view, play or edit the data within the container. For example, a UI can allow a custodian of the container (e.g., the author(s) of the content, publisher, recipient with designated permissions, or other recognized user to provide an updated content file, access and play back the content file, modify the content file, add or remove the associated files or other metadata and otherwise edit the associated files or other metadata. Embodiments may also be implemented to track and validate any changes made to the container or the data contained therein. 
     The content management system may be implemented as separate components or as an integrated system, with all components in one location or application. A content or asset creation and management platform can be used to facilitate creation of the content and management of the created content. This can be an application that may be downloaded to or downloadable by users to run on their own devices, or it may be an application supported by a cloud-based platform. A content editor allowing operation such as viewing content, reading content, editing content and so on may also be provided as a downloadable app or as an app presented by a cloud-based solution. This can include one or more components (or other apps) for file reading, content viewing/playing, content editing, and so on. A content or asset sharing application can be used to allow the asset to be shared in a secure and controlled manner. For example, a transportable container can be provided to contain the content and associated metadata, and the container may be secured to allow content items to be transported to other users. As noted above, the container may include the files themselves, links to the files, or a combination of the foregoing. 
     The container may be securely stored locally, on a portable storage device, or on a cloud-based storage device. The content management system may maintain pointers to file location so that all local updates can be populated to files on a cloud server as well. 
     Controls may be implemented to allow only owners or admins to make changes to the container items to help maintain integrity of the data. A mechanism can be provided such that if a user doesn&#39;t have permission to make changes, they can enter their suggested changes into the system. The system can then send a notification of the change request to the proper users who will view and approve or disapprove the requested changes. Access and modification activities may be tracked along with notifications being sent (based on notification settings). Where multiple approvals are required, for approval may be based on various rules such as majority required, unanimous consent required, and so on. 
     Embodiments of the systems and methods disclosed herein represent an improvement over conventional solutions which do not provide a suitable mechanism for checking, tracking, verifying or maintaining metadata associated with content items. Implementing a container to maintain metadata items and modifying the computing process to perform functions such as determining a content type for the content; identifying items of metadata specified for the determined content type; determining whether specified metadata corresponding to the content is missing from or included in the container; and prompting a user to supply identified missing metadata corresponding to the container represent an inventive concept that alters the conventional operation of the computing system. Embodiments can ensure that the appropriate metadata is collected and maintained with the content and avoid issues with conventional systems. 
     Referring now to  FIG. 1  there is shown a diagram of a system  100  for controlled distribution of digital music. The system  100  includes a digital vault  110 , repository  115 , two or more control devices  125  and two or more reviewing devices  135 . A network  160  connects the various devices for intercommunications. The network  160  may be wired or wireless or combination, may be packet switched and/or circuit-switched or a combination, may include public and private LANs and WANs and may include or be the Internet. 
     The digital vault  110  is a hardware system providing digital vault services as described herein. The hardware of the digital vault  110  may be shared in whole or in part. Software of the digital vault  110  may be on one or more of a single computer, a group of computers which may be arranged as a cloud. The hardware of the digital vault  110  may be one or multiple computers and may be in a single location or distributed among multiple locations. The digital vault services may be embedded in hardware and/or implemented with machine readable storage media in a storage device included with or otherwise coupled or attached to a computing device. 
     The repository  115  is a data storage system and may be a single storage device, an array of devices, a distribution of devices and/or cloud storage, may be in a single location or distributed among multiple locations, may be local or remote to the digital vault  110 , and may be a combination of these. The repository  115  may store media items data and metadata. By media item, it is meant a single unit of streaming media, such as a song, a video or a playlist. The repository  115  may store both structured and unstructured data sets. 
     By song it is meant a file consisting of music in digital form having a play time at normal speed of between ten seconds and several hours. By normal speed it is meant a default playback speed; that is, not sped up or slowed down, and without use of fast forward to skip ahead or rewind to jump back. The songs may be stored in the repository  115  in one or multiple well-known and/or proprietary formats including, for example, MP3, MP4, WAV, AAC, OGG, AIFF, WMA, and other lossy and lossless fonnats. 
     By video it is meant a file consisting of moving images in digital form having a play time at normal speed of between ten seconds and several hours. 
     A playlist is akin to a song, but formed from a compilation of songs. In a playlist, individual songs may be modified by the creator (e.g., a DJ) such as with effects, transitions between songs may be added, and entirely new music or sounds may be placed between pre-existing songs. Furthermore, the digital vault may include a DJ mode that allows creation and modification of playlists on the fly, and captures and records the product. 
       FIG. 1  shows three identical control devices  125   a ,  125   b ,  125   n , and three identical reviewing devices,  135   a ,  135   b ,  135   n . This is intended to show that the system  100  can support numerous such devices. Furthermore, these devices need not be identical; they need only have the specific minimum components and capabilities described below. Furthermore, the control devices  125  and the reviewing devices  135  may be geographically distributed to the extent supported by the network  160 . 
     Human users, not part of the system  100 , are also shown. Owners  120  are users who own media items; that is, they own the copyrights and not merely copies, or human agents who act on behalf of the copyright owners. Owners  120  of songs may be musicians, including songwriters and performers. Owners of videos may be producers. Owners of playlists may be DJs. 
     Reviewing users  130  are an intended audience of the owners, such as people who work as producers, distributors, agents, labels, potential employers, other musicians and creators, fans, commercial purchasers of media and promoters. Owners  120  are shown adjacent respective control devices  125 . Reviewing users  130  are shown adjacent respective reviewing devices  135 . The respective users  120 ,  130  interact with the respective devices  125 ,  135 . The devices  125 ,  135  may be single-user or may support multiple users. Users may use multiple devices  125 ,  135  which may be synchronized. Owners  120  may also be reviewing users  130 . 
     The control devices  125  and reviewing devices  135  are end user computing devices through which the owners  120  interact with the digital vault  110 . These end user computing devices  125 ,  135  include software and/or hardware for providing functionality and features described herein. As shown in  FIG. 1 , the control devices  125  are laptop computers and the reviewing devices  135  are smartphones. However, other general purpose and special purpose computing devices may be used. 
     Referring now to  FIG. 2  there is shown a block diagram of a digital vault  200 , which may be the digital vault  110  of  FIG. 1 . The digital vault  200  has a number of modules: an account management module  210 , an access control module  220 , an upload module  230 , a sharing module  240 , a play module  250  and a management module  260 . The digital vault  200  may be used by owners to share their media items with reviewing users. The digital vault  200  may further include one or more of a publishing module  270 , a copyright registration module  280  and an infringement tracking module  290 . Additional and fewer modules or other arrangement of software, hardware and data structures may be used to achieve the processes and apparatuses described herein. 
     Each of the modules  210 ,  220 ,  230 ,  240 ,  250 ,  260 ,  270 ,  280 ,  290  has a respective function. The account management module  210  is for creating accounts with the digital vault for plural owners. The access control module  220  is for providing the owners secure access to their respective accounts. The access control module  220  also maintains security measures to prevent unauthorized access to the owners&#39; accounts. The security module may include encryption and decryption components, digital watermarking components, and related copy-limiting and song tracking components. The access control module  220  also provides reviewing users access to the media items in an owner&#39;s account. The upload module  230  is for the owners to upload media items into the owners&#39; respective accounts. The sharing module  240  is for the owners to provide reviewing users with access to their media items. The play module  250  is for the reviewing users to stream the media items in the digital vault to which the owners have given them access. The management module  260  provides the owners various options for managing the media items in their accounts. The activity module will record/track the exact time and date the reviewing users entered the digital vault, provide a timestamp of that activity by reviewer showing what specific media items they played and what the duration of the playback was for each specific original media item the owner deposited in the vault. The activity module may also capture or receive the IP address, anonymized or non-anonymized or other identifier of a reviewer. 
     The publishing module  270  provides an automated publication function to owners. Through the publishing module  270 , an owner can identify one or more media items in their account to publish. The publishing module  270  then automatically causes the identified media items to be streamed through a public channel, and records play information such as timestamp and channel identification. The public channel may be an online streaming service, such as Spotify, Pandora, YouTube or Hulu, or a broadcaster such as a terrestrial radio station, or a cable music channel such as those provided by Time Warner Cable. The media item may be streamed on demand by a user of the public channel, or may be included in a play list of the public channel. When the media item is streamed, the publishing module  270  may also capture or receive the IP address, anonymized or non-anonymized or other identifier of a reviewer or recipient of the media item from the streaming service. If providing songs directly from (he digital vault, then a streaming player with decoder/codec may be provided by the play module  250  or the publishing module  270  to the reviewing user. 
     The copyright registration module  280  provides an automated copyright application function to owners. Through the copyright registration module  280 , an owner can identify one or more media items in their account for copyright registration. The copyright registration module  280  then collects whatever information is required to file a copyright application and, through an interface with the online application system of a copyright office such as the U.S. Copyright Office, automatically files applications for registration for the identified media items. The copyright registration module  280  may request some of the required information from the owner. The copyright registration module  280  may obtain some of the required information automatically. For example, the digital vault  200  stores publication information about media items published through the publishing module  270 , and the copyright registration module  280  may use this information in copyright applications. 
     The infringement tracking module  290  provides an automated function to owners to learn about unauthorized distribution and plays of their media items. Through the infringement tracking module  290 , an owner can select one or more media items in their account, and the infringement tracking module  290  will automatically cause a search outside of the digital vault  200  for media which match the selected media items. The infringement tracking module  290  may perform the identification using the digital watermark added to the selected media item by the publishing module  270 . a bit comparison of media item files, a hash computation comparison or other identification technique. The infringement tracking module  290  then reports the match information, including location of the found media item and a rating of confidence in the match. 
     Referring now to  FIG. 3  there is shown a flowchart of a method of an owner controlling distribution of media items using a digital vault, such as the digital vault  200  ( FIG. 2 ). The flow chart has both a start  305  and an end  395 , but the process is cyclical in nature. The description of  FIG. 3  is with respect to one owner, though the digital vault is a multiuser system which supports concurrent operations regarding multiple owners and their respective accounts. 
     The method of  FIG. 3  may include major steps corresponding to modules of  FIG. 2 . That is, the major steps include account creation  310  through the account management module  210 , access control  320  through the access control module  220 , upload  330  through the upload module  230 , sharing of media  340  through the sharing module  240  tracking and time stamping the activity of reviewers through the activity tracking module and song management  360  through the management module  260 . The digital vault may provide a user interface to the owner&#39;s control device through which the operations described herein are performed by the owner and the control device. These user interfaces may be provided by the respective modules. 
     In account creation  310  an owner accesses the digital vault, such as through a website or an app on their control device which connects to the digital vault, and activates an account. Accounts may be created at initial sign-on or in advance. At the owner&#39;s initial connection to the digital vault, the owner&#39;s account is activated, and basic account settings configured. For example, the digital vault may obtain a user ID and a password for the owner. After validation of the initial information the digital vault (hen activates the account for the owner. Through the account management module, the owner can change passwords and other typical account management operations. 
     In access control  320 , the owner logs into the digital vault. Log-in may be through the same website or app as in account creation  310 , or another on the owner&#39;s control device which is connected to the digital vault. The digital vault validates the user and, once validated provides the user/owner access to their account. From within the access control user interface, the owner can then perform various other operations including upload  330 , sharing  340  and management  360 . 
     In upload  330 , the digital vault obtains media items from the owner. In this regard the digital vault may provide a user interface for the owner to identify one or more media items to upload to the digital vault. The upload user interface may allow the owner to select media items stored in their control device or elsewhere, such as cloud storage. The digital vault may then upload the selected media items into its repository, such as the repository  115  ( FIG. 1 ). Uploading may take the form of copying the media item, or may be storage of a pointer to or address of the location identified by the owner. The upload module  230  automatically records a timestamp in the digital vault of receipt of each media item from the owner. 
     In sharing  340 , the sharing user interface allows the owner to identify one or more reviewing users and the media items in the music owner&#39;s account to which the reviewing users are provided access. The sharing user interface may also allow the owner to set streaming limitations. The limits may be set with respect to an individual reviewing user or a group of reviewing users, and with respect to an individual media item or a group of media items. The total number of plays may be limited. Total amount of time played may be limited. Availability of media items for playing may be limited, such as for fixed deadline or a period beginning from some milestone such as first play or log in. The sharing user interface may allow the owner to select streaming players which reviewing users are authorized to use for streaming their media items, or which are not permitted. The digital vault may include counters and a tracking database to track numbers of listens, length of each listen, etc. In sharing, the sharing user interface allows the owner to assign individual access codes authorizing the reviewer to enter the owner&#39;s vault and allowing for specific tracking of the reviewer&#39;s activity and identifying the machine ID of the reviewer. The individual access codes would be specific to an individual reviewer and would not be transferable. The individual access codes for reviewers would be controlled by the owner and could be one-time review codes for a single session or may be a reviewer specific code that could be reused only by that reviewer on more than one reviewing occasion. A log file would be created for each individual reviewer who receives an access code showing and time-stamping the date of their activity, the duration of their activity by specific media item and the exact time they exited the digital vault. 
     In management  360  the management user interface allows the owner to manage the media items in the owner&#39;s account. Management may include assigning metadata and reporting. Metadata may be obtained from various sources. The management user interface may allow the owner to provide metadata, such as media item name, for the media items stored in their account. The digital vault, such as through the management module  260  ( FIG. 2 ) may automatically create and store as metadata for each media item a length of the media item. Other metadata may include album name, performing artist names, producer name, arranger name, recording engineer name, recording studio name, recording date and time, author name, lyrics author name, genre and sub-genre. 
     The management user interface may also provide a report to the owner of plays of their respective media items by the reviewing users. The report may identify the respective media item names and the respective reviewing users, plus playback information such as the timestamp of the start of the stream, the length of time of the stream, whether the media item was played in full or stopped early, and total number of streams. Reporting may be with respect to an individual reviewing user or a group of reviewing users, or an individual media item or a group of media item. 
     Whether a media item has been fully played may be defined by criteria. The simplest criteria would be that the media item has been played from start to finish without interruption. That is, the complete file has been streamed. The management user interface may allow the owner to define different criteria for defining a play. One play may be defined as the stream continuing for a predetermined period of time, or through a predetermined percentage. However, all authorized music plays for a music reviewer would be logged in and a record kept of any plays by the reviewer utilizing a specific authorized access code regardless of the duration of the play period of lime. This will prevent reviewers from managing their playing time to keep the play session under a specific or predetermined period of time. 
     In management  360 , the user interface may also allow the owner to associate one or more images and/or videos with songs and/or albums. The videos may include the respective songs. The management user interface may allow the owner to designate images, videos and other files, and upload these files in association with designated media items. 
     Referring now to  FIG. 4  there is shown a flowchart of a method of a reviewing user receiving controlled distribution of media items. The flow chart has both a start  405  and an end  495 , but the process is cyclical in nature. The description of  FIG. 4  is with respect to one reviewing user, but the digital vault supports concurrent operations regarding multiple reviewing users along with multiple owners. 
     The method of  FIG. 4  may include major steps corresponding to the modules of  FIG. 2 . That is, the major steps include access control  420  through the access control module  220  and playing  450  through the play module  250 . The digital vault may provide a user interface to the reviewing user&#39;s reviewing device through which the operations described herein are performed by the reviewing user and the reviewing device. These user interfaces may be provided by the respective modules. 
     In access control  420  the reviewing user, through their reviewing device, is provided access to media items in an owner&#39;s account. This may be in response to an owner, in the access control step  320  of  FIG. 3 , designating the reviewing user for access to media items in the owner&#39;s account. The digital vault may then send a message to the reviewing user, inviting the reviewing user to access the media items. The invitation may include media item metadata such as media item name and name of the owner. The invitation may be an email message which, when opened obtains data from the digital vault and also shares metadata from the reviewing device with the digital vault. The invitation may be provided through other electronic communications channels, such as text messaging and social networks. The digital vault may support offline invitations, such as through automated mailing. 
     The invitation may include links or credentials for the reviewing user to play media items in the owner&#39;s account. When activated by the reviewing user, the link may cause a user interface display from the digital vault to be displayed on the reviewing device. The user interface may provide additional metadata about the media item and display images or video, such as that obtained by the management module  360  ( FIG. 3 ). Activation of the link may cause a streaming media player on the reviewing device to be activated. The invitation may include a specific access code that is specific to the music reviewer and non-transferrable. The access code may be for a review session of a single designated media item or may be for multiple review sessions over a predetermined period of time with a specific beginning and end established by the owner for the specific reviewer. 
     When the reviewing user gains access to the media item, the digital vault may capture relevant event metadata such as identification of the reviewing user and an activation timestamp. Reviewing users may be provided with an access code, such as from the owner or the digital vault, that is either a single use, disposable access code or a user-specific, non-transferrable access code that remains valid for a pre-determined period of time established by the music owner. In the event that the reviewer requests additional affiliated members of the reviewer&#39;s organization or network be allowed to access the owner&#39;s media items in their vault, the owner could provide for additional authorized users to the specific access code given to the reviewer provided through the use of a suffix related to a specific individual that is part of the reviewer&#39;s organization or network. Alternatively, a new access code could be issued to every individual reviewer regardless of their affiliation with another authorized reviewer. Further a mechanism could be created whereby any additional authorized reviewers added to the primary authorized reviewer&#39;s organization or network, would be issued single use or extended, pre-determined period of time access codes under a group umbrella access code designation so that all affiliated members of a reviewer&#39;s circle of individuals can be tracked as part of a single reviewer group. Each subsequent request to play the owner&#39;s media items by the reviewer would require a new access code or would have to qualify under the pre-determined duration and scope of the access code already issued to that reviewer. 
     After accessing the digital vault  420  the reviewing user may begin playing  450 . Streaming of the media item may initiate automatically. There may be a user interface which allows the reviewing user to change the streaming of the media item. This user interface may be integrated with the streaming media player in the reviewing device, and/or provided by the digital vault. Through this user interface the user may request to jump back or ahead in the stream. However, the listening module  320  may limit the reviewing user to plays, streaming media players and stream controls as set by the owner in the sharing module  340 . The playing module  450  may record event metadata of each stream by the reviewing user, such as an identifier of the reviewing user, a timestamp of the start of the stream, and either a timestamp of the stop of the stream or a length of time of the stream. The metadata may also include stream controls by the reviewing user such as requests to jump back or ahead in the stream. 
     The play module  250  may record the type of streaming player used. The play module  250  may restrict the reviewing user to stream using only the streaming players selected by the owner, such as through the sharing module  340 . 
     During play  450 , the reviewing user may be provided options to listen to additional media items, or to repeat a media item, such as until the reviewing user is satisfied. 
       FIG. 6  illustrates an example container-based content management system in accordance with one embodiment. In this example of a container-based content management system  610 , a content creator creates media content for publication. Creators can include, for example, writers, performers, arrangers and so on. The media content can include, for example, audio content, video content, image content, written works, multimedia content, and so on. Content management  610  may provide one or more of a plurality of vehicles by which content creators may store their completed or in process works in a container file  612  that includes a metadata file associated with the works. The metadata file in container  612  can include the metadata itself, links to locations where the metadata is stored, or a combination of the foregoing. 
     In this example, applications such as a browser application  614  (e.g., in a web-based application), a mobile app  616  (e.g., such as may be made available on a smart phone, tablet, or other portable device), and a desktop application  618  (e.g., such as may be made available on a desktop computer, server, laptop computer, or other computing device) may be used by the creators  610  to store their content in a container  612 . These applications  614 ,  616  and  618 , and other applications may be used by creators  610  to create content, review content, modify content and share content that they created. The data in container  612  may be encrypted or compressed, stored using a markup language such as JSON or XML, or a combination of the foregoing. 
     The files in the container or the container itself may be stored, retrieved and updated locally by access to a local copy associated with the user&#39;s device. Additionally, the files in the container or the container itself may be stored, retrieved and updated via a network connection to a server  626  that stores and accesses the files on storage device  622 . Accordingly, the creation portion of the system can be connected to data store  622 , which is preferably a secure data storage environment at which multiple containers  612  may be stored for access by creators and entities with whom which creators wish to share their content. One example of a secure data store  622  is the digital vault for content owners disclosed by U.S. Pat. No. 9,836,619, which is hereby incorporated by reference herein in its entirety. 
     Local applications or other portals can be provided to allow creators or other custodians to manage, play and update the content and data. In this example, the content management applications  614 ,  616 ,  618  access data store  622  and it server  626  via the Internet  624 . In other examples, a data storage unit such as data store  622  can be a local data storage unit such as, for example, a disk drive on the creator&#39;s computer or other storage unit accessible over a LAN or other available network, a flash drive (e.g., thumb drive, jump drive, etc.) or other local storage unit. In further examples, a data storage unit such as data store  622  can be a remote storage unit accessible by means other than the Internet such as, for example, a WAN or other wired or wireless communications interface. As this example also illustrates, a stored container file  612  can be shared by server  626  with third parties at the direction of the creators or other authorized personnel. 
       FIG. 7  illustrates a high level example of a creator accessing a content management system to create and store a container file in accordance with one embodiment. With reference now to  FIG. 7 , in this example creator  610  accesses a content management application  615  (e.g., application  614 ,  616 ,  618 ) on a user device  611  (e.g., smart phone, tablet, laptop, desktop computer, server, rig, etc.) to create a container file  612 . Container file  612  can be stored locally or remotely. This example, similar to the example of  FIG. 6 , illustrates application  615  accessing a server  626  and data store  622  by a communications interface such as the Internet  624 . 
       FIG. 8  illustrates an example process for content management using a container file in accordance with one embodiment. In this example, an artist, or a plurality of artists in collaboration, create content at operation  720 . As noted above, the content created can be any of a number of different forms of media (including multimedia) content such as audio, video, and so on. The created content can include a completed piece of content or it can be content that is still a work in progress. For example, the created content can be partially completed elements of a song, video production, or other media content that a collaborator or co-collaborators are working on but have not yet finished. As another example, the created content can be a completed song, video production or other media content that the collaborator or collaborators have completed. 
     At operation  722 , the creators store the created content in a container file. The creators also store metadata associated with the content in the container file. In some circumstances, at least some of the metadata might be stored prior to storage or creation of the content. In other circumstances, at least some of the metadata might be stored when the creators store the content. In yet other circumstances, at least some of the metadata might be stored after the content is created and stored. Because the system can store content and metadata for works in progress as well as completed works, the system can allow receipt, management, sharing and tracking of content during the creation process as well as after the creation is complete. Where one or more users store content elements for a given created content in the system, the system can be configured to flag each of those users as potential co-collaborators for that given created content. Accordingly, the system can automatically gather metadata even during the creation process. 
     At operation  724 , the content management system checks the container to ensure that it is complete. Particularly, the system can check to determine that the appropriate items of metadata are included, depending on the type of content stored. For example, different types of metadata may be specified for different types of content. Examples of metadata that might be stored in the container file for audio content are listed in Table 1. 
     
       
         
           
               
             
               
                 TABLE 1 
               
               
                   
               
               
                 METADATA EXAMPLES 
               
               
                   
               
             
            
               
                 CREATOR IDENTIFICATION 
               
               
                 OWNERSHIP INFORMATION 
               
               
                 ROYALTY PAYMENT INFORMATION 
               
               
                 DIGITAL DISTRIBUTION RELEASE METADATA AND FILES 
               
               
                 LYRICS 
               
               
                 SHEET MUSIC 
               
               
                 COPYRIGHTS 
               
               
                 AGREEMENTS 
               
               
                 ALBUM ARTWORK 
               
               
                 WORK FOR HIRE CONTRACTS 
               
               
                 PERFORMER AND COMPOSER INFORMATION 
               
               
                 OTHER METADATA 
               
               
                   
               
            
           
         
       
     
     Checks to ensure that the container is complete with the appropriate forms of metadata can be done at different times. For example, the system may check to ensure that the container is complete when the content is first stored in the container, periodically after the container is created or in response to a user query. In some instances, the container can be configured to check certain of the content items for compliance with the requirements such as, for example, ensuring that an ISBN number is numeric and that it contains 13 digits. As another example, the system can check file types to ensure the correct file type is logged for the metadata it is purported to represent. For instance, the system might be configured to check to ensure that data stored as Album Artwork is a .jpg, .tiff, .gif or other appropriate file type. In further embodiments, the system may be configured to inspect files for content to ensure files are of the appropriate type for the metadata they are purported to represent. In this manner, the system may be programmed to scan purported contracts to determine whether certain language is present confirming it is at least the appropriate document type. This may be based on programming instructions to search for certain text strings, or on an Al trained model employed to predict document types based on content. 
     As these examples illustrate, when checking for completeness of the metadata, the content management system may be able to check whether certain metadata items are present, but may not be able to verify the accuracy or comprehensiveness of each item. For example, while the system might check to confirm that one or more creators are identified, the system may not know whether all creators have been identified. In some embodiments, the system can send reminders not only for metadata items that appear to be incomplete, but also to remind users to verify that metadata items that appear to be complete are in fact complete and accurate. For example, the system can generate and send a message to the original creators and query them to ensure that no co-collaborators have been left off of the information collected. Because this can be done somewhat contemporaneously with the creation of the content, or at least with the deposit of the content into the container, this information can be gathered while collaborators are still around and recollections of collaborators and their relevant contributions are likely to be fresh and accurate. 
     Additionally, there may be different levels of completeness for container files. For example, in some applications a first level of completeness (e.g., Level I) the indicated container is ready for distribution to certain recipients or types of recipients, but that it is not ready for other distribution. For example, Level I may mean complete for purposes of distribution to producers or publishers for review, but not yet ready for production. As another example, Level I may mean that the container is complete for distribution to certain streaming services, but not for other streaming services. Continue with these examples, Level II may indicate completeness for all streaming services whereas Level III may be required for certain licensing activities, and so on. As these examples indicate, different levels can be custom defined for various containers or for different content types and the system can be configured to check for levels of completeness. 
     Where the container appears complete, the system can set a flag or other indicator indicating that it is complete. Where the container is incomplete, the system may set a different flag on the container, indicating that materials are missing. The flag may be in various forms such as a change in the file name, a change in the file extension, an indicator or other alert associated with the container, data in a designated field in the container, or other designation that may indicate the completeness status of the metadata. The system may also be configured to send an alert to the creators or other users indicating that the metadata does not appear to be complete or ask them to verify the completeness of metadata that does appear to be complete. For example, the system may send a message to a user stating that the container is not complete. This message may further include a list of the metadata that is missing or a list of errors that appear to have been found in the metadata (e.g., wrong file type). This information may also be stored in a determined location in the container file itself, so others accessing the file may view this information as well. In yet further embodiments, the system may track container status as a central function such as, for example, by maintaining a log of containers and their statuses at a central or other accessible location or locations. As another example, the system may send a message to a user stating that a metadata element appears to be complete but asking the user to verify accuracy and completeness of the information. 
     As another example, where the system automatically created metadata not input by the users (e.g., identified users uploading content as collaborators), the system may be configured to generate and send a message to provide this gathered metadata to one or more users asking the one or more users to verify that the automatically created and stored metadata is accurate and complete. The users can verify the accuracy and completeness or update it to include corrections or additional information. 
     Different components of the content management system may be configured to ensure that the container is complete, to set flags indicating a completeness status and to send alerts to users. In some embodiments, the application on which the content is created may read the container file, compare the contents to the expected contents and determine whether the container is complete. This function may also be performed by a server and data store storing containers (e.g., server  626  and data store  622 ). Also, viewer applications or other creator or editor applications (in addition to the specific application on which the content was created) may also be configured to perform these functions. 
     In operation  726 , the content management system can be configured to distribute one or more containers at the direction of or with the permission of their respective creators or other custodians. For example, a creator may direct the content management system (e.g., the creator&#39;s application or the server) to send one of his or her container files to a third party. The content management system can send the container to the designated recipient or recipients and track the container. The container can be protected such as by encryption, by password protection, by keying it to designated recipients, and so on. The system can set up tiered protection such that different recipients might have different levels of access to the container and the contents therein. For example, some recipients might be able to access everything in the container, whereas other recipients might only be able to access certain container items. As another example, some recipients might be given read-only access to one or more items in the container whereas other recipients might be given read/modify/write access. The system can be configured to track every user or entity who had access to the content as well as rights that were given to such users and entities as well as their access parameters such as, for example when they accessed it, what they accessed it, for how long they accessed it, and so on. 
     In various embodiments, the custodian or custodians may be dynamic in that they can change over time as permissions change, such as when new persons are given access levels to view/modify content, or permissions are revoked from other persons. 
     The system may further be configured such that when the file is opened, the viewer application verifies the data in the local copy of the container against the data in the primary storage location (e.g., the data stored in the cloud) to determine whether any changes have been made since the transfer. If any changes were made, those changes may be highlighted to the viewer. Additionally, if authorized, an updated version of the file can be downloaded to the viewer. Likewise, changes made by a file recipient can be shared with other custodians (e.g., original content creators, other authorized viewers or editors) and they can be highlighted so that changes can be easily identified. Embodiments may require that such changes be approved by an authorized custodian prior to acceptance. 
       FIG. 9  illustrates an example creation of a content container in accordance with one embodiment. More particularly,  FIG. 9  illustrates an example of how an existing audio file such as a WAV, MP3, etc. file can be associated with, concatenated with or appended to include metadata (e.g. .TUNE data) and other data from the cloud to create a new file that could be played with an existing audio player (such as a conventional mp3 player). In this example, the resulting file includes the original audio file and information or data that might be included with it, and the additional metadata while retaining compatibility for play back with a conventional audio player. In this example, an original content file (in this case an audio file)  762  and a content metafile  764  are loaded into container  612 . Content file  762  created by one or more creators might be a file such as a WAV, MP3, AAC, WMA or other audio file. The final container in this example includes the original audio file (or files) and the metafile(s). 
     Metafile  764  can be a collection of data that is added to container  612 . In other embodiments, metafile  764  may be a specific or proprietary file structure that has a specified file format and may require a particular application to read, write or modify it. In the example illustrated in  FIG. 9 , metafile  764  is a proprietary .TUNE file type accessed with a compatible application. In other embodiments, other file types may be specified. In another application, the container  612  is a file with a specified file format (e.g., the .TUNE file) that can be loaded and accessed/played with a corresponding file player. 
     This example of  FIG. 9  can be implemented to preserve backward compatibility with existing audio players while still including the capability to associate or store metadata which might be accessed, for example, via a particular viewer or application. Stated another way, embodiments may append metadata to an existing standard audio file while maintaining backwards compatibility with existing audio players so they can play the file as is a standard playable audio file, but when the container is opened by a proprietary app configured to work with container files, the app would know how to play the file and extract all the additional metadata as well. 
       FIG. 10  illustrates an example process for creating a container in accordance with one embodiment. At operation  832 , one or more creators create a content item. For example, recording artists/musicians may record a song or an album. At operation  834 , the creators provide the content they created to a content management application (e.g., content management application  615 ) so that the content can be assigned a container  612 . Accordingly, the application receives the content created at operation  832  and creates a container in which the received content can be stored. At operation  836 , the creators or other authorized users add metadata associated with the created content to the created container. Accordingly, the application receives the metadata associated with the content created at operation  832  and stores this metadata in the container  612  created for the content. Although the metadata may be stored in any of a number of different file formats, some examples of metadata file formats are described below. 
     At operation  838 , the system checks for the completeness of metadata. Specifications may be created identifying the types of metadata items that are expected to be included for a particular content type. Accordingly, the system may identify the content type (e.g., based on the file extension or extensions for multiple files, or based on an identification provided by the creator on a UI), retrieved the appropriate specification for the content type or types included in the container and check the metadata file to determine whether specified content is included. In terms of the example depicted in Table 1, the system may check to ensure that creator information is included, album artwork is included, royalty payment information is included, copyright information is included, and so on. In other implementations, creators may be given the option to edit the standard specification for metadata for their particular content or to provide a custom specification for their content. In such applications, the system may compare the metadata on file with the custom or semi-custom specification to determine completeness. 
     Once the system verifies that the content is present in the metadata is complete, the content management system marks the container accordingly. As noted above, this may include setting a flag for the container, adjusting a container name, providing an appropriate designation in a field for the container, emailing the appropriate users (e.g., creators or other authorized users) or other appropriate designation technique. This is illustrated at operations  840  and  842 . Although not illustrated, the system may also inform the user that it believes the container is complete. The system may continue at operation  838  to perform periodic checks for completeness of the container. These checks may be performed at regularly scheduled intervals based on system settings or user preferences. These checks might also be triggered by system events such as request to share content, actions to edit or update content, actions to view or listen to content, and so on. 
     At operation  844 , even where the system has determined from its checks that the metadata appears to be complete, the system may be configured to periodically remind the creators or other designated users to update the metadata or to check the metadata to ensure that it is still current and complete. Users may be able to set the timing for periodic updates or this timing may be predetermined in the system. Updates may also be triggered based on events. For example, when a user requests that content be shared with a third party, the system may prompt the user at that time to confirm that the metadata is up-to-date and complete. 
     If upon completing its verification the system determines that the container is incomplete, the system may prompt the appropriate user or users for any missing data or information. This is illustrated at operations  840  and  846 . In some applications the user may simply be provided with a warning that the metadata file appears to be incomplete or that content appears to be missing. In other applications, the system may provide a specific listing to the user or users of content or metadata items that appear to be missing. Accordingly, the user may use this warning as an opportunity to complete the metadata information. 
     Where the user subsequently provides additional content or metadata to be added to the container, at operation  848 , the system receives this additional data from the user. At operation  850 , this data is added to the container. The system may continue at operation  838  to perform periodic checks for completeness of the container. These checks may be performed at regularly scheduled intervals based on system settings or user preferences. These checks might also be triggered by system events such as request to share content, actions to edit or update content, actions to view or listen to content, and so on. 
     In various embodiments, the content management system may further be configured to prohibit users from sending or sharing files to others if the metadata appears incomplete. The system may be configured to allow the user to override the safeguard, in essence verifying that the user has confirmed the completeness of the metadata despite the systems warning or that the user is otherwise satisfied that the file can be appropriately shared. 
       FIG. 11  illustrates an example UI for an application (e.g., application  615 ) for a content management system. This can be implemented as the UI to allow users to view play or otherwise access content in a container, view metadata associated with that content in the container and edit the content or the metadata in the container. With reference now to  FIG. 11 , this example UI  1100  includes a plurality of user selection elements (e.g., physical or touchscreen buttons) allowing the user to access the information. Shown are user selection elements for content information  932 , ownership information  934 , credits information  936 , royalty payment information  938 , master recordings  940 , and other documents and files  942 . Selection of these user selection elements allows the user to drill down to the next level of data stored in the application. For example, selection of content information  932  (in the case of audio content, song/album/EP information) allows the user to view or edit this information. Selection of the master recordings  940  element allows the user to play the stored audio or A/V content or to view stored image content.  FIG. 11  illustrates just one example of a UI layout. In other embodiments, other layouts may be provided and other user selection elements for different data items can be provided. 
       FIG. 12  illustrates an example UI for a container viewer in accordance with one embodiment. As with the example of  FIG. 11 ,  FIG. 12  illustrates just one example of a UI layout. In other embodiments, other layouts may be provided and other user selection elements for different data items can be provided. This example includes a file portion  1010 , a metadata portion  1020  and an additional vault data portion  1030 . Referring to file portion  1010  first, master recording element  1012  allows an authorized user to access and play/view the content stored in the container. Actuation of master recording element  1012 , may launch an appropriate player application and cause the associated content to be played. 
     Status element  1014  allows a user to view and update status information relating to assignment of master recording, release dates, and distribution dates. In some embodiments, this information can be displayed in the form of dates such as the date the master recording is assigned, the release date, and the date it is ready for distribution. States may be captured by the system and displayed based on system activities (e.g., the actual date that content was released through the system) or they may be manually set an update. In other embodiments, the status information can be displayed in the form of indicators (as opposed to dates) such as a GREEN status indicator indicating complete, a YELLOW status indicator indicating partially complete and a RED status indicator indicating incomplete. 
     Working files element  1016  allows the user to access the content files associated with the master. This may allow authorized users to review and modify the content files themselves. Actuation of working files element  1016  may launch an appropriate editor application allowing the content to be accessed, reviewed and modified by the authorized user. 
     Fingerprint element  1018  can be included to provide a container fingerprint. The container fingerprint can include an audit log of activities occurring associated with the container. Activities may include actions such as changes to the container contents (e.g., updates, additions, deletions), access actions, transfers/shares of the container, and other events. The activities may also include an identification of those accessing the container, the date and time of access, duration of access, portions of the content accessed and so on. The log may, like other contents, be encrypted or otherwise protected. Container activities can also be managed and tracked using blockchain or other distributed ledger technology. 
     Metadata section  1020  can provide user interface elements to allow users to access and revise metadata for the container. This example illustrates user interface elements for ownership information  1022 , distribution information  1024  and supporting documents  1026 . Selection of interface element for ownership information  1022  allows the user to pull up, view and modify ownership information for the content in the container. Selection of interface element for distribution info  1024  allows the user to pull up, view and modify current distribution information. This may be used to track and display parties to whom content has been distributed, set distribution parameters for parties to receive the information (e.g., identify who where and when to send the associated content or the entire container), and to track dates and times of distribution and access. Selection of interface element for supporting documents  1026  can allow users to pull up, view and modify other metadata items in the container such as, for example, associated song lyrics, sheet music, album artwork, contracts, copyright information, licenses, and so on. 
     Additional vault data portion  1030  may be included to allow additional data to be tracked and stored for the content in the container. This example includes three storage elements, certified song reviews  1032 , distribution information (e.g., Distro100 data)  1034 , and social data  1036 . The certified song reviews storage element stores reviews of the content and allows a user to access and view reviews of the content. In some cases, reviews may be limited to certified or verified reviews, whereas in other implementations, all reviews can be included. Distribution information interface element stores, and allows the user to access, view and modify distribution data regarding the who/when/where the content was distributed on a streaming basis. Streaming data from providers such as TuneGo™, Distro100™, Spotify™, Pandora™, and others can be accessed via this interface element. Social data storage element  1036  stores and allows the user to access data gathered by the system from social media and like sites. The gathered data may relate to the content, the artist, the publisher or other like information. The system may also store and allow the user to access social media links where this information can be accessed from its source. 
     In various embodiments, these and other additional vault data items can be collected by unaffiliated or third-party service providers and aggregated for quick and easy access by the container application user. As the above examples illustrate, listener/critic review data from multiple sources, streaming data from a plurality of streaming providers and social data from various social media sources can be collected, distilled and made available to the user via the interface elements in additional vault data portion  1030 . Note that each of the interface elements in  FIGS. 11 and 12  may be used to access an item directly or to drill down to a deeper level user interface. 
       FIG. 13  illustrates an example scenario of collaborative music creation in a cloud environment in accordance with one embodiment.  FIG. 14  illustrates an example process for collaborative music creation in accordance with the example of  FIG. 13 . In this example, two creators  610  use applications  615  to create content, which can be stored on a data store  622  (e.g., a vault) at server  626 . Creators  610  use the system to share their content file, or a container  612  including the content file with a third party  611 . 
     At operation  1132 , the system creates a container to contain the content created by creators  610  and the associated metadata. Creators  610  may use the system application  615  to collaboratively create the content and store it in a container with the associated metadata (e.g., as an audio file  762  and a metafile  764 ). At operation  1134 , the system verifies that the metadata associated with the content is complete. For example, this verification can be performed by application  615  during or after content creation or by server  626  when the container is provided to data store  622  for storage. 
     At operation  1136 , the system receives a request by one or more of the creators  610 , or from an authorized user, to share the content or the entire container  612  with a designated recipient  611 . This may be done, for example through application  615 , server  626  or a combination of the two. The system can check appropriate permissions to determine whether the requested transfer is permitted. The system can also check completeness of the container before transferring and issue any alerts, if appropriate, depending on the status of the completeness of the container. Examples of a designated recipient may include, a producer, creator, manager, record label, publisher, and so on. 
     Assuming the users are authorized and the transfer permitted, the system transfers the container  612  to the designated recipient  611  at operation  1138 . At operation  1140 , the recipient accesses the container and the content therein using an application  617 . In various embodiments, application  617  may be the same as or similar to application  615 . In some implementations, application  617  may be limited to a playback only application whereas another implementations, application  617  may be a fully functional application allowing playback and modification. The system may be configured such that application  615  or server  626  keeps track of the transfers made and can provide reporting to the user such as, for example via the user interfaces such as those exemplified in  FIGS. 11 and 12 . 
     Upon authorizing a transfer, a sender may specify different levels of permission for different recipients. In some instances, certain recipients may have set levels of permissions. Permissions can identify parameters such as access types (review, modify, etc.), number of times access is permitted, durations or time windows in which access is permitted, further sharing rights, and so on. Assuming recipient  611  has the appropriate permissions, recipient  611  may modify the content or the metadata and, using application  617 , save and updated container file locally or in data store  622 , or otherwise transfer the updated container file to the content creators  610  or other content centers. 
       FIG. 15  illustrates an example scenario of music creation in a local environment in accordance with one embodiment.  FIG. 16  illustrates an example process for music creation in accordance with the example of  FIG. 15 . In this example, a creator  610  uses an application  615  to create content, which can be stored on a data store  622  (e.g., a vault) at server  626 . Creator  610  uses the system to share its content file, or a container  612  including the content file with a third party  611 . 
     With reference now to  FIGS. 15 and 16 , at operation  1232 , the system creates a container to contain the content created by creator  610  and the associated metadata. Creator  610  may use system application  615  to create the content and store it in a container (e.g., container  612 ) with the associated metadata (e.g., as an audio file  762  and a metafile  764 ). At operation  1234 , the system verifies that the metadata associated with the content is complete. For example, this verification can be performed by application  615  during or after content creation or by server  626  when the container is provided to data store  622  for storage. 
     At operation  1236 , the system receives a request by creator  610 , or from an authorized user, to share the content or the entire container  612  with a designated recipient  611 . This may be done, for example through application  615 , server  626  or a combination of the two. The system can check appropriate permissions to determine whether the requested transfer is permitted. The system can also check completeness of the container before transferring and issue any alerts, if appropriate, depending on the status of the completeness of the container. Examples of a designated recipient may include, a producer, creator, manager, record label, publisher, and so on. 
     Assuming the user requesting transfer is authorized and the transfer permitted, the system transfers the container  612  to the designated recipient  611  at operation  1238 . At operation  1140 , the recipient accesses the container and the content therein using an application  617 . The system may be configured such that application  615  or server  626  keeps track of the transfers made and can provide reporting to the user such as, for example via the user interfaces such as those exemplified in  FIGS. 11 and 12 . 
       FIG. 17  illustrates an example scenario of hybrid music creation in which multiple creators  610  create content in a cloud-based environment and another collaborator performs content creation in a local environment. This example combines the example illustrated in  FIGS. 13 and 14  with the example illustrated in  FIGS. 15 and 16 . 
     In the various examples disclosed herein, the transfer of a container  612  for the files therein can be made by sending the container or files themselves or by sending a link to a location where the container or the files therein can be accessed. For example, the system may send a recipient a link or other designation to access the container stored in data store  622 . 
     Upon authorizing a transfer, a sender may specify different levels of permission for different recipients. In some instances, certain recipients may have set levels of permissions. Permissions can identify parameters such as access types (review, modify, etc.), number of times access is permitted, durations or time windows in which access is permitted, further sharing rights, and so on. Assuming recipient  611  has the appropriate permissions, recipient  611  may modify the content or the metadata and, using application  617 , save and updated container file locally or in data store  622 , or otherwise transfer the updated container file to the content creators  610  or other content centers. 
     If a recipient does not have appropriate permissions, the system may be configured to allow the recipient to submit a request for the particular permission desired (e.g., to update a particular item of data) and to present the request to designated owners/admins of the data for approval or denial. Users may be given the ability to adjust settings to specify the various notifications they would like to receive throughout the process of sharing data with other parties. 
     Application  615  may be implemented to facilitate metadata tracking and update. Embodiments can include the ability to display metadata to the user so that the user can make appropriate updates. The system can further be configured to reach out through network connections to verify of any metadata is out of date. Any out of date data can be flagged and visually highlighted so the user knows that it is stale data. 
     In various embodiments, creative asset metadata (including associated documents) may be appended to an existing media file in another file format such as an .mp3, .wav, or other file. In the process, this may create a new file that is readable in its native file format by existing applications such as an audio player capable of reading such files. This preserves the playability/accessibility of the original content if that is desired. The file may be converted in such a way that when the file is opened by the specific Viewer/Reader (e.g., application  615 ) the application will be able to extract, display and play the additional content. 
       FIG. 18  illustrates an example description of a descriptor file for contents of a container  612  in accordance with one embodiment. In this example, the descriptor file includes, for each asset, an Asset ID  1310 , version information  1312 , update information  1314  and identification of the asset itself  1316 . Asset ID can be any identification information to identify the various assets in the container, preferably such that each asset may be uniquely identified. In this example, a numeric designation  1 -N is utilized. Where different versions are contemplated and may be tracked, version information  1312  can be used to designate and display the current version of the asset item. In this example, version numbers of the format X.Y.Z are used, although other formats may be utilized. Update information  1314  can be used to capture and display information relative to the version number. This example illustrates displaying who made the update, when it was updated, what the update entails, how it was approved, and so on. The asset identification  1316  itself in this example is a listing of the file. For example, the assets in this container include a content file (e.g., media file in the form of a .wav, .mp3, etc file), a document file (e.g. for contracts), an image file (e.g., for album cover art), and so on. In some embodiments, the .TUNE file itself can include a version number for version tracking such that when updates are made to the contents of the container, that container&#39;s version number can also be updated. 
     In various embodiments disclosed herein, metadata information can be multiple separate metadata files or a metadata file including multiple items of metadata content such that can also be loaded into or associated with a container  612 . The metadata can be a collection of data items that are added to container  612 . In other embodiments, the metadata can be in a specific or proprietary file structure that has a specified file format and may require a particular application to read, write or modify it (e.g., a proprietary .TUNE file, although other file types may be specified). 
     Embodiments may be configured such that users can download or extract individual files or data from the .TUNE file, users can view and listen to the files that are included in the .TUNE file, and users can edit or update data in the .TUNE file if they have permission. The system can further be configured such that updates to a local version will also update the data on the server ( 626 ,  622  and will send notifications regarding the modifications to other users as well as the owner/admin of the content. 
     In this example a single audio file (label here as a Media File) is illustrated as being stored in the container. Similarly, in the example illustrated in  FIG. 9 , a single audio file  762  is illustrated as being stored in container  612 . This audio file might be a single track or a collection of tracks (e.g., an album or partial album). Accordingly, an album can be contained in a single container file  612 , or an album can be contained across multiple container files (e.g., one track of the album per container  612 ). The same can be said for other types of content as well. 
     Storing items in a container (e.g., container  612 ) can include, in some embodiments, packaging the items together and wrapping them in a container file. The container file can include a file name and can have the stored items embedded within the file. In other embodiments, the container  612  can be implemented in whole or in part as a virtual container and its contents could potentially be physically located in different databases or different locations but linked to or otherwise associated with their respective container  612 . Accordingly, storing items in a container can include identifying the items as belonging to the container. This may be implemented by listing the file names in the container file, using a lookup table to store the filenames included in the container, identifying the corresponding container for each item by designating the container in the filename or file header, or otherwise associating the item files with the corresponding container. 
       FIG. 19  illustrates an example of a container stored in a data store in accordance with one embodiment. In this example, container  612  is stored in data store  622  of server  626  which may be accessible via a network  624  such as the Internet. 
       FIG. 20  illustrates an example file structure that can be used for a container file  612  in accordance with one embodiment. Although any of a number of different structures can be utilized, this example structure includes a header  1411 , the content  1412  and metadata  1414 . In the context of  FIG. 9 , content  1412  may include one or more audio files  762 , and metadata  1414  may include a metafile  764 . An example of header  1411  is also illustrated in  FIG. 20 . Again, any of a number of different header structures can be utilized. This example header  1411  includes a checksum (to verify integrity), a file size indicator, encryption information, identifying information, version information, update history, and other information. As this example further illustrates, container  612  may be sent to data store  622  or otherwise shared via network  624 . 
     In various embodiments, container  612  may be maintained as an integral unit and stored in one location, or copied across multiple locations. In other embodiments, information in a container  612  may be stored in multiple locations, but not necessarily all in the same place.  FIG. 21  illustrates examples of different forms of container storage. At  1332 , a fully encapsulated container  612  is illustrated. This encapsulated container includes all data maintained in a single container. At  1334 , all of the data for the container (except for the header in this example) is stored external to the container. For example, it may be stored at data store  622  accessible via network  624 . In other examples, the data can be stored in other locations including multiple locations. Here, pointers or indices are used to point to the locations of the files.  1336  illustrates a hybrid approach in which a combination of internal (encapsulated data) and external storage are used. Here, the container includes the original audio recording, but at least some of the metadata is stored elsewhere in links or indices to that data point to the data locations. 
     The term “coupled” refers to direct or indirect joining, connecting, fastening, contacting or linking, and may refer to various forms of coupling such as physical, optical, electrical, fluidic, mechanical, chemical, magnetic, electromagnetic, optical, communicative or other coupling, or a combination of the foregoing. Where one form of coupling is specified, this does not imply that other forms of coupling are excluded. For example, one component physically coupled to another component may reference physical attachment of or contact between the two components (directly or indirectly), but does not exclude other forms of coupling between the components such as, for example, a communications link (e.g., an RF or optical link) also communicatively coupling the two components. Likewise, the various terms themselves are not intended to be mutually exclusive. For example, a fluidic coupling, magnetic coupling or a mechanical coupling, among others, may be a form of physical coupling. 
     Referring now to  FIG. 5  there is shown a computing device  500 . The computing devices described herein, such as the digital vault, control devices, reviewing devices, containers and other instrumentalities described herein may be configured as shown in  FIG. 5 . The computing device  500  includes a processor  520 , communications interface  530 , memory  540 , and an input/output interface  550 . Further, although these elements are shown independently of one another, each may, in some cases, be integrated into one another. 
     The computing device  500  is representative of the mobile devices and other computing devices discussed herein. For example, the computing device  500  may be or be a part of a mobile device or a server. The computing device  500  may include software and/or hardware for providing functionality and features described herein. The computing device  500  may therefore include one or more of: logic arrays, memories, analog circuits, digital circuits, software, firmware and processors. The hardware and firmware components of the computing device  500  may include various specialized units, circuits, software and interfaces for providing the functionality and features described herein. The processes, functionality and features may be embodied in whole or in part in software which operates on the computing device  500  and may be in the form of firmware, an application program, an app, a dynamic linked library (DLL), a script, one or more subroutines, or an operating system component or service. The hardware and software and their functions may be distributed such that some components are performed by the computing device  500  and others by other devices. 
     The processor  520  may be or include one or more microprocessors, application specific integrated circuits (ASICs), or a system-on-a-chip (SOCs). 
     The communications interface  530  includes an interface for communicating with external devices. In the case of a computing device  500 , the communications interface  530  may enable wireless communication with a mobile device. The communications interface  530  may be wired or wireless. The communications interface  530  may rely upon short to medium range wireless protocols like Bluetooth®, infrared, and/or 802.11x wireless or another wireless protocols then in existence. 
     The memory  540  may be or include RAM, ROM, DRAM, SRAM and MRAM or other memory systems, and may include firmware, such as static data or fixed instructions, boot code, system functions, configuration data, and other routines used during the operation of the computing device  500  and processor  520 . The memory  540  also provides a storage area for data and instructions associated with applications and data handled by the processor  520 . 
     The I/O interface  550  interfaces the processor  520  to components external to the computing device  500 . In the case of servers and mobile devices, these may be keyboards, mice, pens, voice activated systems and other peripherals. 
     The storage  560  is non-transient electronic, machine readable media which provides non-volatile, bulk or long term storage of data or instructions in the computing device  500 . The software described herein may be stored in the storage  560 . Storage devices include hard disk drives, DVD drives, flash memory devices, and other storage devices. Multiple storage devices may be provided or available to the computing device  500 . Some of these storage devices may be external to the computing device  500 , such as network storage, cloud-based storage, or storage on a related mobile device. This storage  560  may store some or all of the instructions for the computing device  500 . The term “storage medium”, as used herein, specifically excludes transitory medium such as propagating waveforms and radio frequency signals.