Media Asset Access Control System

Abstract

Provided herein is an asset storage server that assigns related files to asset names and assigns permissions to asset names so that related files with unrelated names can be assigned permissions independently of file naming conventions without requiring a user to individually set permissions for each file. The asset storage server can also generate a modified version of the original file name and index a distributed object storage area based on the modified version so that related files with related names are not listed in the same partition of the distributed object storage area. Indexing the distributed object storage area based on the modified version of the original file name can reduce data retrieval latency.

Description

[0001] This application is a divisional application of the patent application with application number 2017800641286, application date September 21, 2017, and invention name “Media Asset Access Control System”. Background Art

[0002] Typically, a file system stores various files in directories, folders, and subfolders. Users who have access to the file system can read, write, delete, or otherwise manage such files. In some cases, it may be desirable to be able to set permissions for one or more files. For example, multiple users may have access to the same file system. A first user may have created a first file, and may wish that other users who have access to the file system cannot read, write, or delete the first file. Therefore, the first user may access the properties of the first file and set the appropriate permissions. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Reference numerals may be repeated throughout the figures to indicate corresponding relationships between reference elements.The drawings are provided to illustrate example embodiments described herein and are not intended to limit the scope of the present disclosure.

[0004] Figure 1 is a block diagram of an asset storage environment 100 according to one embodiment.

[0005] Figure 2 According to one embodiment, storage in Figure 1 Example table in the lookup key database

[0006] Figure 3 According to one embodiment, storage in Figure 1 Example tables in the asset licensing database

[0007] Figure 4 According to an implementation scheme Figure 1 A block diagram of an asset storage environment is shown, illustrating the operations performed by components of the asset storage environment to manage data objects.

[0008] Figure 5 According to an implementation scheme Figure 1 A block diagram of an asset storage environment illustrating operations performed by components of the asset storage environment that allow access to data objects.

[0009] Figure 6 is a flow diagram depicting a routine for assigning data object permissions illustratively implemented by an asset storage server, according to one embodiment.

[0010] Figure 7is a flow diagram depicting a routine for generating modified data object names illustratively implemented by an asset storage server, according to one embodiment. DETAILED DESCRIPTION

[0011] As described above, a user can set file permissions to allow certain users to access files and prohibit other users from accessing the files. In some cases, a group of files are related. For example, a media player can output a digital copy of media (e.g., a movie, a television program, a music video, etc.). However, the digital copy of the media may include various files that are accessed sequentially to output the media. Because the files are related, it may be desirable for all related files to have the same file permissions.

[0012] A distributed object store may store paths that identify locations on disk where files (e.g., data objects) are stored. Specifically, a distributed object store may store paths to groups of related files. In a distributed object store, files may be identified as related based on their file names. For example, a first group of related files may be named "movie1file1," "movie1file2," movie1file3," etc., and a second group of related files may be named "movie2file1," "movie2file2," movie2file3," etc. When related files have related names, changing file permissions for the related files may be relatively simple. For example, a bulk operation may be run to change permissions for all files that have the same prefix in their file names (e.g., "movie1*").

[0013] However, if the related files do not have related names, changing file permissions may be difficult and / or expensive. For example, if the related files have irrelevant names, it may not be possible to define a bulk operation that captures all related files. An administrator may have to manually parse the stored files, identify which files are related, and set permissions for each related file individually. This may be particularly tedious if the number of related files is in the thousands, hundreds of thousands, millions, etc. If a related file is missed (e.g., by an operation that changes file permissions for a related file, by an administrator, etc.), this may compromise file security because an unauthorized user may access the missed related file. Additionally, if the related files have irrelevant names, it may not be possible to run high-level language policies such as "all files related to this particular media asset should not be readable by any user" or "all 1080p renditions of any media asset should be readable by every user on January 1, 2016."

[0014] In addition, if related files have related names, additional problems may arise. For example, a distributed object storage area may have multiple partitions and be indexed using file names. The index may be based on a tree structure having a root node, various levels of child nodes, and leaf nodes, each leaf node representing a partition of the distributed object storage area, such that the first character of the file name determines which child node of the root node the file is assigned to, the second character of the file name determines which child node of the assigned child node the file is assigned to, and so on, until the file is assigned to a leaf node (e.g., a partition of the distributed object storage area). In other words, files with related names may be listed together in the same partition of the distributed object storage area (e.g., file "movie1file2" is listed in the same partition as file "movie1file1", while file "game1file1" may be listed in another partition of the distributed object storage area). A user device may query the distributed object storage area to identify the location of various files that the user device is attempting to retrieve. Typically, a user device attempts to retrieve related files in rapid succession (e.g., because the user is watching a movie). Because the distributed object store can be indexed using file names, and because user devices attempt to retrieve related files with related names, user devices may be attempting to read from and / or write to the same partition of the distributed object store. As a result, there may be an uneven distribution of read and / or write traffic between partitions of the distributed object store, causing the distributed object store to become a performance bottleneck.

[0015] Thus, an asset storage server is described herein that (1) assigns related files to asset names and assigns permissions to asset names such that related files with unrelated names can be assigned permissions independently of file naming conventions without requiring a user to individually set permissions for each file; and / or (2) indexes a distributed object store based on a modified version of a given file name such that related files with related names are not listed in the same partition of the distributed object store. For example, when an asset owner provides a set of related files for storage in an asset database, the asset storage server may allow the asset owner to create an asset name that defines the related files (e.g., if the related files are for playing a movie, the asset name may be the name of the movie). The asset storage server may map the related files to the asset names and store the mapping in an asset permissions database.

[0016] In addition, the asset storage server can allow asset owners to assign permissions to asset names, and the asset storage server can store the assigned permissions in an asset permission database. Thus, when a user requests a file from an asset retrieval server, the asset retrieval server can (1) query the asset permission database to identify the asset name that maps to the file; (2) use the identified asset name to determine whether the user is authorized to access the file; (3) if the user is authorized to access the file, determine the location of the file by querying the distributed object storage area; (4) retrieve the file from the determined location; and (5) transmit the file to the user to satisfy the request.

[0017] In addition, the asset storage server can generate a hash for each related file. For example, the hash can be based on the file path of the corresponding related file. The generated hash can be appended as a prefix to the file name of the corresponding related file. Even though the related files can have related names and / or can be stored in similar locations, the hash values ​​generated for the related files can be different (for example, the first character of the hash value of the first related file can be different from the first character of the hash value of the second related file). Therefore, because the distributed object storage area is indexed by a tree structure, the related files can be divided into different partitions. This can reduce the likelihood that consecutive read and / or write requests are sent to the same partition of the distributed object storage area. Therefore, the distributed object storage area data retrieval latency can be reduced. The following reference Figures 1 to 7 Describes additional details of the asset storage server.

[0018] Example asset storage environment

[0019] Figure 1 is a block diagram of an asset storage environment 100 according to one embodiment. Figure 1 As shown in , the asset storage environment 100 includes an end-user device 102, an asset owner device 104, an asset storage server 106, an asset retrieval server 108, an asset database 144, a lookup key database 146, and an asset permission database 148. In an embodiment, the end-user device 102 communicates with the asset retrieval server 108 via a network 110. In addition, the asset owner device 104 can communicate with the asset storage server 106 via the network 110. The network 110 can be a publicly accessible network of linked networks, which may be operated by various different parties, such as the Internet. In other embodiments, the network 110 can include a private network, a personal area network, a local area network, a wide area network, a cable network, a satellite network, a cellular telephone network, the like, or a combination thereof, each of which can access and / or be accessed from the Internet.

[0020] The asset database 144 may store data objects (e.g., files) associated with a variety of different content, such as movies, television programs, music videos, audio books, and / or the like. In addition, the asset database 144 may store different versions of the same content. For example, the asset database may store content in different formats (e.g., 480i, 720p, 1080p, 4K, etc.), content in different languages ​​(e.g., English, French, Spanish, etc.), content with additional features (e.g., director's comments, deleted scenes, etc.), and / or the like. The data objects may be stored in various folders or directories within the asset database 144. However, as described herein, the actual location in the asset database 144 where the data object is stored may not affect the application of modifications to the license assigned to the data object. The asset database 144 may have several storage tiers, such as primary storage, archive storage, and / or the like. Primary storage may provide faster retrieval times than archive storage, and therefore may be more expensive to provide and maintain than archive storage.

[0021] Content may not be stored in a single data object. Instead, content may be stored in multiple data objects, each representing a small time segment of the entire content. Multiple data objects may be accessed continuously to output content. Therefore, multiple data objects may be related. An asset owner via an asset owner device 104 may indicate to an asset storage server 106 that multiple related data objects are being transferred to an asset database 144 for storage. For example, multiple related data objects may be transferred to an asset database 144 via an asset storage server 106, an asset retrieval server 108, or another system (not shown) for storage. The asset owner device 104 may also indicate which asset or sub-asset multiple related data objects should be associated with. As used herein, an asset may refer to a specific content title (e.g., a movie, a TV show, a music video, an audio book, etc.), and a sub-asset may refer to a specific version or format of an asset (e.g., content in 1080p format, French content, content that can be distributed through specific distribution channels such as TV, the Internet, and cellular networks) or different renditions of an asset (e.g., an episode of a TV show).

[0022] The asset storage server 106 may include a data object to asset mapper 122, an asset license manager 124, a lookup key generator 126, and an asset storage manager 128. The data object to asset mapper 122 may be configured to map data objects to asset or sub-asset names. For example, the data object to asset mapper 122 may receive an indicated asset or sub-asset name from the asset owner device 104 and generate a mapping of the asset or sub-asset name to each of the related data objects. The data object to asset mapper 122 may then store the mapping in the asset license database 148.

[0023] In addition, the asset owner device 104 may indicate permissions to be assigned to the asset or sub-asset name. For example, permissions may include read access, write access, update access, delete access, update metadata access (e.g., authorization to modify the attributes of a data object, such as format, bit rate, keywords, associated actors, creation date, shooting date, etc.), and / or the like, and may specify which end users are associated with the permissions. As an example, an end user may be a user (e.g., licensee, consumer, rights holder, etc.) who has been granted permission to access certain data objects for viewing. In some embodiments, multiple permissions may be assigned to an asset or sub-asset name. For example, a first end user may be granted read access to a data object mapped to an asset or sub-asset name, and a second end user may be granted read and write access to a data object mapped to an asset or sub-asset name. The asset permission manager 124 may receive permissions indicated by the asset owner device 104 and map the permissions to the indicated asset or sub-asset name. The asset permission manager 124 may then store the mapping in an asset permission database 148. Thus, the asset permission database 148 may store a mapping of an asset or sub-asset name to a plurality of data objects and a mapping of an asset or sub-asset name to one or more permissions. The contents of the asset permission database 148 will be referred to below. Figure 3 Describe in more detail.

[0024] Alternatively, the asset owner device 104 may not indicate the permissions that should be assigned to the asset or sub-asset name. In this case, the asset permission manager 124 assigns a default permission to the asset or sub-asset name and stores the mapping of the default permission to the asset or sub-asset name in the asset permission database 148.

[0025] The asset license manager 124 may be further configured to apply a license to an asset or sub-asset name in response to a received request. For example, the asset owner device 104 may transmit a request (e.g., an application programming interface (API) call) to add or modify a license for one or more asset names or sub-asset names. The request may identify one or more asset or sub-asset names and include information detailing the new license. The asset license manager 124 may use the identified one or more asset or sub-asset names and the license information to modify the license for one or more asset or sub-asset names stored in the asset license database 148 (e.g., update a mapping of assets to licenses and store the updated mapping in the asset license database 148).

[0026] Optionally, a request to add or modify permissions for one or more asset names or sub-asset names includes a time parameter. Using the time parameter, the asset owner can specify a date and / or time when the permissions expire. When the requested permissions expire, the permissions for the asset or sub-asset name may revert to the previous permissions, may be changed to the default permissions, or the permissions may no longer be mapped to the asset or sub-asset name.

[0027] The asset license manager 124 may also automatically run rules that apply licenses to select asset or sub-asset names. For example, a rule may define an action (e.g., adding or modifying a license for an asset or sub-asset name) that is executed when an event occurs or at a set time (e.g., periodically). A rule may be applied to an asset or sub-asset based on the name of the asset or sub-asset (e.g., a name provided by the asset owner device 104). In addition, a rule may be applied to a data object, either a data object that is mapped to the same asset or sub-asset name or a data object that is mapped to a different asset or sub-asset name. For example, a rule may be applied to a data object based on the format of the data object (e.g., resolution, file size, bit rate, play length, etc.). Events may include the introduction of a new asset or sub-asset name, the expiration of an existing license, the addition, modification, and / or deletion of one or more data objects stored in the asset database 144, and / or the like. The execution of a rule may cause the asset license manager 124 to update the mapping of asset or sub-asset names to licenses and store the updated mapping in the asset license database 148.

[0028] The lookup key database 146 may store mappings between the names of data objects and the storage locations of the data objects in the asset database 144. As described above, the distributed object storage area may have multiple partitions and be indexed using data object names. Figure 1 As shown in , the lookup key database 146 is a distributed object storage area. Therefore, the lookup key database 146 can have multiple partitions and is indexed using the names of the data objects stored in the asset database 144. Given that related data objects with related names may cause the above-mentioned performance bottleneck problem, the lookup key generator 126 can generate modified data object names that result in different name prefixes and create a mapping between the data object names originally provided by the asset owner and the modified data object names. Therefore, for the asset owner, the name of the data object remains unchanged. However, for the purpose of the lookup key database 146, the lookup key database 146 is indexed based on the modified data object names that have changed.

[0029] For example, the lookup key generator 126 can be configured to generate a hash for each data object stored in the asset database 144. The hash can be generated using any known technique (e.g., SHA-256). The lookup key generator 126 can determine the hash using at least a portion of the file path of the corresponding data object (e.g., the file path of the data object that identifies the location of the data object in the asset database 144, including the asset name, sub-asset name, data object name, folder, subfolder, subdirectory, directory, partition, etc.). Once the hash is generated, the lookup key generator 126 can append the generated hash as a prefix to the original name of the data object given by the asset owner to form a modified data object name. For example, if the data object is named "movie1file1" and the hash of the file path of the data object is "7HG9", then the modified data object name may be "7HG9movie1file1". Even though related data objects may have related names and / or may be stored in similar locations in the asset database 144, the hash values ​​generated for the related data objects may be different (e.g., the first character of the hash value for a first related data object may be different from the first character of the hash value for a second related data object). In fact, the hash values ​​may be generated so that conflicts (e.g., two consecutive or nearly consecutive (e.g., requests within 2 requests of each other) read requests to the same partition) are greatly reduced. Therefore, because the lookup key database 146 is indexed by a tree structure, related data objects may be divided into different partitions based on modified data object names. This may reduce the likelihood that the asset retrieval server 108 or another device will send consecutive read and / or write requests to the same partition of the lookup key database 146. Therefore, the lookup key database 146 data retrieval wait time may be reduced.

[0030] Alternatively, the lookup key generator 126 may generate the modified data object name using other techniques. For example, instead of generating a hash value and appending the hash value to the original data object name, the lookup key generator 126 may reverse the order of the characters in the original data object name. As another example, the lookup key generator 126 may generate a unique identifier that is not based on the file path of the data object and replace the original data object name with the unique identifier. As another example, the lookup generator 126 may randomly reorder the characters in the original data object name (e.g., randomly determine the reordering for each data object) and use the reordered characters as the modified data object name. The lookup key generator 126 may use other techniques not described to generate the modified data object name in such a way that the related data objects having the related data object names have sufficiently early differences in the modified names so that the searches for these related data objects in the lookup key database 146 are randomized between different partitions of the lookup key database 146.

[0031] Lookup key generator 126 may store mappings between original data object names and modified data object names in a table in lookup key database 146. Lookup key generator 126 may also store the generated modified data object names in association with the locations of the corresponding data objects in lookup key database 146 so that the generated modified data object names are used to index lookup key database 146.

[0032] When the lookup key database 146 can be indexed based on the generated modified data object names, the indexing can be transparent to the user. For example, the generation of the modified data object names may not affect the data object naming conventions of the asset owner. The asset owner can continue to store the data objects in folders, subfolders, directories, etc. in the asset database 144 using the names selected by the asset owner. The use of the modified data object names may not change the file structure or the way data objects are organized and stored in the asset database 144. Instead, when a data object is requested from the asset database 144, the modified data object names may only control which partitions of the lookup key database 146 are accessed. Figure 2 An illustrative example of looking up key database 146 is described.

[0033] The asset storage manager 128 may be configured to store data objects received from the asset owner device 104 in the asset database 144. The asset storage manager 128 may be further configured to perform bulk operations on the data objects stored in the asset database 144. For example, the asset owner device 104 may transmit a request (e.g., an API call) for a list of asset or sub-asset names that are mapped to data objects that a particular end user has permission to access (e.g., read, write, update, etc.). The asset storage manager 128 may query the asset permission database 148 for the list of asset or sub-asset names and forward the list to the asset owner device 104 for display and / or storage. Optionally, the asset permission manager 124 may retrieve the list and send it to the asset owner device 104. As another example, the asset storage manager 128 may receive a request (e.g., an API call) from the asset owner device 104 to move data objects mapped to the asset or sub-asset names from one storage tier to another storage tier. In response to the request, the asset storage manager 128 may query the asset licensing database 148 to identify a data object mapped to the asset or sub-asset name, query the lookup key database 146 to identify the location of the identified data object, retrieve the identified data object from a specified location in the asset database 144, and re-store the identified data object in a new storage tier in the asset database 144.

[0034] As described above, related data objects may be stored in the same folder or directory in the asset database 144. However, the permission mapping using the asset or sub-asset name described herein is different from conventional systems that allow a user to modify folder permissions (which are then applied to all data objects in the folder) because related data objects stored in the same folder typically require different access rights. As an illustrative example, a folder in the asset database 144 may store a first data object related to a first asset and a second data object related to the first asset. The first data object may be a 720p version of the first asset, and the second data object may be a 1080p version of the first asset. A first end user may be assigned a permission that grants the first end user read access to the 720p and 1080p versions of the first asset. A second end user may be assigned a permission that grants the second end user read access to the 720p version of the first asset and other assets, but no access to any accessed 1080p version. Without the techniques implemented by the asset storage server 106 described herein, it may not be possible to run a batch operation in the manner described above to assign permissions to the first end user and the second end user. Additional folders may have to be created to further subdivide data objects, resulting in increased asset database 144 retrieval latency due to the additional read and write requests required to create the additional folders or directories and due to the additional query time required to identify the location of the desired data object given the additional folders or directories. The techniques implemented by the asset storage server 106 described herein can reduce the proliferation of folders, thereby reducing retrieval latency of the asset database 144 and enabling the ability to run batch operations as described herein.

[0035] The end-user device 102 may request access to one or more data objects via the asset retrieval server 108. For example, the end-user device 102 may transmit a request (e.g., an API call) to the asset retrieval server 108 to access a first data object. The request may indicate whether the requested access is read access, write access, update access, delete access, update metadata access, and / or the like. The asset retrieval server 108 may query the asset permission database 148 to identify the asset or sub-asset mapped to the first data object. Once the mapped asset or sub-asset is determined, the asset retrieval server 108 may query the asset permission database 148 to determine whether the user associated with the end-user device 102 (or the end-user device 102 itself) has permission to access the mapped asset or sub-asset in the requested manner.

[0036] If the user or end-user device 102 does not have permission to access the asset or sub-asset, the asset retrieval server 108 may send a notification to the end-user device 102 indicating that access is denied. Otherwise, if the user or end-user device 102 does have permission to access the asset or sub-asset, the asset retrieval server 108 may query the lookup key database 146 to identify the location of the first data object in the asset database 144. For example, the asset retrieval server 108 may first query a table in the lookup key database 146 that maps original data object names to modified data object names to identify a modified data object name corresponding to the name of the first data object. The asset retrieval server 108 may then query the lookup key database 146 using the modified data object name to identify a file path for the first data object. Optionally, the query by the asset retrieval server 108 may cause the lookup key database 146 to identify a modified data object name corresponding to the first data object name (e.g., stored in a table in the lookup key database 146) and respond to the asset retrieval server 108 with a file path corresponding to the modified data object name.

[0037] Using the received file path, the asset retrieval server 108 can retrieve the first data object from the asset database 144 and transmit the first data object to the end-user device 102 to fulfill the request. The asset retrieval server 108 can repeat this process for any number of requested data objects and any number of end-user devices 102.

[0038] The end-user devices 102 and the asset owner devices 104 may include a wide variety of computing devices, including personal computing devices, terminal computing devices, laptop computing devices, tablet computing devices, electronic reader devices, mobile devices (e.g., mobile phones, media players, handheld gaming devices, etc.), wearable devices with network access and program execution capabilities (e.g., "smart watches" or "smart glasses"), wireless devices, set-top boxes, game consoles, entertainment systems, televisions with network access and program execution capabilities (e.g., "smart TVs"), and various other electronic devices and devices. Each end-user device 102 may execute a browser application or a stand-alone application that allows a user to request a particular data object from the asset retrieval server 108. Similarly, the asset owner device 104 may execute a browser application or a stand-alone application that allows an asset owner to add or modify permissions and / or manage the storage of data objects.

[0039] The asset storage server 106 may be a computing system programmed or otherwise configured to manage the storage of permissions and data objects as described herein. The asset storage server 106 may automatically add or change permissions upon request, upon an event, upon a data object being stored in the asset database 144, upon a data object being stored in the asset database 144 being modified, and / or any combination thereof.

[0040] Figure 1 The asset storage server 106 and / or asset retrieval server 108 may be a single computing device, or may include multiple different computing devices, such as computer servers, that are logically or physically grouped together to operate together as a server system. The components of the asset storage server 106 and / or asset retrieval server 108 may each be implemented in application-specific hardware (e.g., a server computing device with one or more ASICs) so that no software is required, or implemented as a combination of hardware and software. In addition, the modules and components of the asset storage server 106 and / or asset retrieval server 108 may be combined on a server computing device, or separated or divided into groups on several server computing devices. In some embodiments, the asset storage server 106 and / or asset retrieval server 108 may include more than one server computing device. Figure 1 More or fewer components as shown.

[0041] In some embodiments, the features and services provided by the asset storage server 106 and / or the asset retrieval server 108 may be implemented as network services that are consumable via the communication network 110. In further embodiments, the asset storage server 106 and / or the asset retrieval server 108 are provided by one or more virtual machines implemented in a hosted computing environment. A hosted computing environment may include one or more rapidly provisioned and released computing resources, which may include computing, networking, and / or storage devices. A hosted computing environment may also be referred to as a cloud computing environment.

[0042] The asset database 144, the lookup key database 146, and / or the asset license database 148 may be located external to the asset storage server 106 and / or the asset retrieval server 108. For example, the asset database 144, the lookup key database 146, and / or the asset license database 148 may be stored and managed by a separate system or server, and may communicate with the asset storage server 106 and / or the asset retrieval server 108 via a direct connection or an indirect connection (e.g., via a network, such as the network 110). In other embodiments not shown, the asset database 144, the lookup key database 146, and / or the asset license database 148 are located within the asset storage server 106 or the asset retrieval server 108.

[0043] Find the sample table in the key database

[0044] Figure 2 According to one embodiment, storage in Figure 1 The exemplary table 200 and the exemplary table 250 in the lookup key database 146 are shown in FIG. Figure 2 As shown, table 200 is a table storing the relationship between the original data object name and the modified data object name. For example, table 200 may include a data object file name header 202 listing the original data object name, and a data object key name header 204 listing the modified data object name. Rows 220, 222, and 224 may depict entries for various data objects in table 200. As shown in table 200, the original data object name may be "FILE1", "FILE2", and "FILE3". In certain embodiments, "FILE1", "FILE2", and "FILE3" may be the names of data objects mapped to the same asset or sub-asset. As described above, the lookup key generator 126 may generate a hash value to be attached to the original data object name as a prefix. Therefore, the modified data object name may be "4H56FILE1", "G765FILE2", and "1AENFILE3", wherein "4H56", "G765", and "1AEN" are attached hash values.

[0045] Table 250 may be a table that stores the relationship between modified data object names and file paths in asset database 144. For example, table 250 may include a data object key name header 252 that lists the modified data object names, and a data object location header 254 that lists the file paths of the corresponding data objects. Rows 260, 262, and 264 may depict entries for various data objects in table 250. Although rows 260, 262, and 264 are in Figure 2 146, but this is for illustration purposes only. Because each of the appended hash values ​​begins with a different character, the modified data object name will likely fall into a different partition of the lookup key database 146. Therefore, even if the asset retrieval server 108 attempts to access "FILE1", "FILE2", and "FILE3" consecutively, read requests to the lookup key database 146 may be routed to different partitions in the lookup key database 146.

[0046] Although table 200 and table 250 are depicted as separate tables in lookup key database 146, this is not meant to be limiting. For example, the contents of table 200 and table 250 may be combined into a single table stored in lookup key database 146.

[0047] Example tables in the asset licensing database

[0048] Figure 3According to one embodiment, storage in Figure 1 Example table 300 and example table 350 in the asset permission database 148 of FIG. Figure 3 As shown, table 300 is a table that stores the relationship or mapping between the original data object name and the asset and / or sub-asset name. For example, table 300 may include a data object file name header 302 that lists the original data object name, and an asset name header 304 that lists one or more mapped assets and / or sub-assets. Rows 320, 322, and 324 may depict entries for various data objects in table 300. As shown in table 300, the original data object names may be "FTLE1", "FTLE2", and "FTLE3". The data objects "FTLE1", "FTLE2", and "FTLE3" are each mapped to the asset name "ASSET 1". However, the data objects "FTLE1" and "FTLE2" may be mapped to the sub-asset name "SUB-ASSET 1", while the data object "FTLE3" may be mapped to the sub-asset name "SUB-ASSET 2". As an illustrative example, data objects "FILE1" and "FILE2" may both be mapped to sub-asset name "SUB-ASSET 1" because both data objects, along with other data objects, may be used together to play back a particular version of an asset (eg, a 1080p version of a movie).

[0049] Table 350 may be a table that stores relationships or mappings between assets and / or sub-assets and permissions. For example, table 350 may include an asset name header 352 that lists one or more assets and / or sub-assets and a permission header 354 that identifies the permissions assigned to the assets and / or sub-assets. Rows 360 and 362 may depict entries for various assets and / or sub-assets in table 350. As shown in table 350, the sub-asset "SUB-ASSET 1" of the asset "ASSET 1" has a permission that allows user 1 to read data objects mapped to the sub-assets (e.g., data objects "FILE1" and "FILE2") and has a permission that allows user 2 to have no access to the mapped data objects. However, the sub-asset "SUB-ASSET 2" of the asset "ASSET 1" has a different permission than "SUB-ASSET 1". Sub-asset "SUB-ASSET 2" has a permission that allows user 1 read access to data objects mapped to the sub-asset (e.g., data object "FILE3"), and has permissions that allow user 2 read access, update access, and delete access to the mapped data objects. Thus, multiple permissions can be assigned to a particular asset or sub-asset name, and different permissions can be assigned to different sub-assets of an asset name.

[0050] Although table 300 and table 350 are depicted as separate tables in asset permission database 148, this is not meant to be limiting. For example, the contents of table 300 and table 350 may be combined into a single table stored in asset permission database 148.

[0051] Example block diagram for managing data objects

[0052] Figure 4 According to an implementation scheme Figure 1 1 is a block diagram of an asset storage environment 100, illustrating operations performed by components of the asset storage environment 100 to manage data objects. Figure 4 As shown in , the asset owner device 104 can transmit data associated with the data object to be stored to the data object to asset mapper 122, the asset license manager 124, and / or the lookup key generator 126 at (1A). The data associated with the data object to be stored may include the name of the data object, an indication of an asset or sub-asset name associated with the data object, and / or a permission to assign the asset or sub-asset name. The data object to asset mapper 122 can map the data object to an asset or sub-asset name specified by the asset owner device 104 at (2). The data object to asset mapper 122 can then indicate to the asset license manager 124 at (3) that the data object is mapped to a particular asset or sub-asset name. The asset license manager 124 can then map the permission provided by the asset owner device 104 to the asset or sub-asset name at (4) and store the mapping in the asset license database 148 at (5).

[0053] Simultaneously with, prior to, or after transmitting the data associated with the data object at step (1A), the asset owner device 104 may transmit the data object to the asset storage manager 128 for storage at (1B). The asset storage manager 128 may store the data object in the asset database 144 at (6). The asset storage manager 128 may also forward an identification of the storage location (e.g., file path) of the data object to the lookup key generator 126 at (7). Alternatively, the lookup key generator 126 may determine the storage location by querying the asset database 144.

[0054] Using the identified storage location, the lookup key generator 126 may generate a modified data object name for the data object at (8). For example, the lookup key generator 126 may generate a hash using the identified storage location and append the hash as a prefix to the original name of the data object to create the modified data object name. The lookup key generator 126 may then store the mapping of the original data object name to the modified data object name and the mapping of the modified data object name to the storage location of the data object in the lookup key database 146 at (9). The modified data object name may allow related data objects to be partitioned into different partitions of the lookup key database 146. For example, as described above, the index of the lookup key database 146 may be based on a tree structure having a root node, various levels of child nodes, and leaf nodes, each leaf node representing a partition of the lookup key database 146. The first character of the modified data object name may determine which child node of the root node the data object is assigned to, the second character of the modified data object name may determine which child node of the assigned child node the data object is assigned to, and so on, until the data object is assigned to a leaf node (e.g., a partition of the lookup key database 146). The original data object names of related data objects may have similar names (e.g., "movie1file1," "movie1file2," "movie1file3," etc.), and therefore the related data objects may be partitioned into the same leaf nodes (e.g., partitions) if the lookup key database 146 is indexed based on the original data object names. However, appending the hash as a prefix to the original name for the related data objects may result in the first character and / or subsequent characters of the modified data object name being different. Therefore, by indexing the lookup key database 146 using the modified data object names, the related data objects may be assigned to different child nodes and / or leaf nodes, resulting in the related data objects being partitioned into different partitions of the lookup key database 146. Partitioning the related data objects into different partitions of the lookup key database 146 may reduce data query and / or retrieval time.

[0055] Although steps (6) to (9) are depicted as occurring after steps (2) to (5), this is not meant to be limiting. For example, the asset storage server 106 may perform steps (6) to (9) before steps (2) to (5).

[0056] Example block diagram for accessing data objects

[0057] Figure 5 According to an implementation scheme Figure 1 1 is a block diagram of an asset storage environment 100, illustrating operations performed by components of the asset storage environment 100 to allow access to data objects. Figure 5 As shown in , the end-user device 102 transmits a request to the asset retrieval server 108 at (1) to identify the data object to be retrieved. In response to receiving the request, the asset retrieval server 108 queries the asset permission database 148 at (2) to determine whether the user associated with the end-user device 102 (or the end-user device 102 itself) has permission to access the requested data object. As described herein, the query can involve two operations. For example, the asset retrieval server 108 can query the asset permission database 148 to identify which asset or sub-asset name is mapped to the requested data object. Once this is determined, the asset retrieval server 108 can query the asset permission database 148 to identify the permission associated with the mapped asset or sub-asset name. The asset retrieval server 108 can analyze the retrieved permission to determine whether the user is authorized to access the data object. Optionally, the asset retrieval server 108 may transmit the name of the user or end-user device 102 and the data object name to the asset permission database 148, and the asset permission database 148 may analyze such data as described above with respect to the asset retrieval server 108 and return a notification indicating whether the user or end-user device 102 is authorized to access the data object.

[0058] If the user or end-user device 102 is not authorized to access the data object, the asset retrieval server 108 sends a notification to the end-user device 102 indicating that access is denied, not shown. Otherwise, if the user or end-user device 102 is authorized to access the data object, the asset retrieval server 108 determines the location of the data object by querying the lookup key database 146 at (3). For example, the lookup key database 146 can be indexed based on the modified data object name. Therefore, the asset retrieval server 108 can query the first table in the lookup key database 146 to determine the modified data object name corresponding to the original name of the data object. Once this is determined, the asset retrieval server 108 can query the lookup key database 146 using the modified data object name to identify the file path of the data object stored in the asset database 144.

[0059] Upon receiving the file path of the data object stored in the asset database 144, the asset retrieval server 108 may retrieve the data object from the asset database 144 at (4). The asset retrieval server 108 may then transmit the retrieved data object to the end-user device 102 to satisfy the request at (5).

[0060] Alternatively, instead of transmitting a request to the asset retrieval server 108 identifying a data object to be retrieved, the end-user device 102 may transmit a request to the asset retrieval server 108 identifying an asset or sub-asset to be retrieved at (1). In response to receiving the request, the asset retrieval server 108 queries the asset permissions database 148 at (2) to determine whether a user associated with the end-user device 102 (or the end-user device 102 itself) has permission to access the data object associated with the specified asset or sub-asset name. The asset retrieval server 108 may make this determination by querying the asset permissions database 148 to identify a permission associated with the specified asset or sub-asset name. The asset retrieval server 108 may analyze the retrieved permission to determine whether the user is authorized to access the data object associated with the asset or sub-asset name. Optionally, the asset retrieval server 108 may transmit the name of the user or end-user device 102 and the asset or sub-asset name to the asset permission database 148, and the asset permission database 148 may analyze such data as described above with respect to the asset retrieval server 108 and return a notification indicating whether the user or end-user device 102 is authorized to access a data object associated with the specified asset or sub-asset name.

[0061] If the user or end-user device 102 is not authorized to access the data object associated with the specified asset or sub-asset name, the asset retrieval server 108 sends a notification to the end-user device 102 indicating that access is denied, not shown. Otherwise, if the user or end-user device 102 is authorized to access the data object associated with the specified asset or sub-asset name, the asset retrieval server 108 can identify the data object associated with the specified asset or sub-asset name. For example, the asset retrieval server 108 can query the asset permission database 148 to identify the data object mapped to the specified asset or sub-asset name. The asset retrieval server 108 can then determine the location of some or all of the mapped data objects by querying the lookup key database 146 at (3). As described above, the lookup key database 146 can be indexed based on the modified data object name. Therefore, the asset retrieval server 108 can query the first table in the lookup key database 146 to determine the modified data object name corresponding to the original name of the mapped data object. Once this is determined, the asset retrieval server 108 can query the lookup key database 146 using the modified data object name to identify the file path of the mapped data object stored in the asset database 144.

[0062] Upon receiving the file path of the mapped data object stored in the asset database 144, the asset retrieval server 108 may retrieve the mapped data object from the asset database 144 at (4). The asset retrieval server 108 may then transmit the retrieved data object (e.g., sequentially, in bursts or groups, in parallel, etc.) to the end-user device 102 at (5) to satisfy the request.

[0063] Example Data Object Permission Assignment Routine

[0064] Figure 6 6 is a flow chart depicting a data object license assignment routine 600 illustratively implemented by an asset storage server, according to one embodiment. As an example, Figure 1 The asset storage server 106 may be configured to perform a data object permissions assignment routine 600. The data object permissions assignment routine 600 begins at block 602.

[0065] At block 604, data associated with the data object to be stored is received. For example, the data may include a name of the data object, an indication of an asset or sub-asset name associated with the data object, and / or permissions to assign the asset or sub-asset name.

[0066] At block 606, the data object is mapped to the user-specified asset name. For example, multiple data objects may be mapped to an asset name.

[0067] At block 608, a determination is made as to whether a license is received from the user. For example, the received license may include information identifying a license to be associated with the received asset name. If a license is received, the data object license assignment routine 600 proceeds to block 612. Otherwise, the data object license assignment routine 600 proceeds to block 610.

[0068] At block 610, a default permission is mapped to the received asset name. For example, the default permission can be defined so that only users who provide data objects mapped to the asset name are allowed to access the data objects. After block 610 is completed, the data object permission assignment routine 600 proceeds to block 614.

[0069] At block 612, the received license is mapped to an asset name. In some embodiments, multiple licenses are mapped to an asset name, such as licenses specific to individual users.

[0070] At block 614, the mapping of data objects to asset names and the mapping of permissions to asset names are stored. For example, the mappings may be stored in the asset permissions database 148. The asset retrieval server 108 may then use the mappings to satisfy requests for data objects submitted by various end-user devices 102. After the mappings are stored, the data object permissions assignment routine 600 may be completed, as shown in block 616.

[0071] Example modified data object name generation routine

[0072] Figure 7 is a flow chart depicting a modified data object name generation routine 700 illustratively implemented by an asset storage server, according to one embodiment. As an example, Figure 1 The asset storage server 106 may be configured to perform a modified data object name generation routine 700. The modified data object name generation routine 700 begins at block 702.

[0073] At block 704, variable i is set equal to 1 and variable n is set equal to the number of data objects corresponding to the asset name. For example, the asset owner device 104 may indicate that a plurality of related data objects are to be stored in the asset database 144, where each of the related data objects may be categorized within the asset name.

[0074] At block 706, a name of data object i is received. For example, the name of data object i may be a name provided by an asset owner.

[0075] At block 708 , a storage location of data object i is received. For example, the storage location may be a file path of data object i that indicates a storage location of data object i in the asset database 144 .

[0076] At block 710, a hash corresponding to data object i is generated. For example, the hash may be generated using the file path of data object i. The hash function may be performed using SHA-256 or other similar techniques.

[0077] At block 712, a modified data object name for data object i is set to a combination of the generated hash and the name of data object i. For example, the generated hash value may be appended as a prefix to the name of data object i to form the modified data object name. In an alternative embodiment, the modified data object name for data object i may be set to a random reordering of the characters in the name of data object i.

[0078] At block 714 , the original name of data object i is mapped to the modified data object name. For example, the lookup key generator 126 may store this mapping in the lookup key database 146 .

[0079] At block 716, the modified data object name is mapped to the storage location of data object i. For example, the lookup key generator 126 may store this mapping in the lookup key database 146 so that the lookup key database 146 is indexed using the modified data object name.

[0080] At block 718, a determination is made as to whether variable i is equal to variable n. If the two variables are equal, this indicates that all data objects to be stored in the asset database 144 have been processed, and the modified data object name generation routine 700 may be completed, as shown in block 722. Otherwise, all data objects to be stored in the asset database 144 have not been processed, and the modified data object name generation routine 700 proceeds to block 720.

[0081] At block 720, the variable i is incremented by 1. After completion of block 720, the modified data object name generation routine 700 returns to block 706 and repeats blocks 706 through 718 until all data objects are processed.

[0082] the term

[0083] All methods and tasks described herein can be performed by a computer system and fully automated. In some cases, a computer system can include multiple different computers or computing devices (e.g., physical servers, workstations, storage arrays, cloud computing resources, etc.) that perform the described functions through network communication and interoperation. Each such computing device generally includes a processor (or multiple processors) that executes program instructions or modules stored in a memory or other non-temporary computer-readable storage medium or device (e.g., solid-state storage device, disk drive, etc.). Various functions disclosed herein can be implemented in such program instructions, or can be implemented in an application-specific circuit (e.g., ASIC or FPGA) of a computer system. In the case where a computer system includes multiple computing devices, these devices can be but not necessarily located at the same place. By transforming a physical storage device such as a solid-state memory chip or a disk into different states, the results of the disclosed methods and tasks can be stored persistently. In some embodiments, a computer system can be a cloud-based computing system, and its processing resources are shared by multiple different business entities or other users.

[0084] Depending on the implementation, certain actions, events, or functions of any process or algorithm described herein may be performed in a different order, may be added, combined, or omitted entirely (e.g., not all described operations or events are necessary for algorithm practice). In addition, in some embodiments, operations or events may be performed simultaneously, such as through multithreading, interrupt handling, or multiple processors or processor cores or on other parallel architectures, rather than sequentially.

[0085] Various illustrative logic diagrams, modules, routines and algorithmic steps described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware (e.g., ASIC or FPGA devices), computer software running on computer hardware, or a combination of the two. In addition, various illustrative logic diagrams and modules described in conjunction with the embodiments disclosed herein can be designed to be implemented or executed by a machine for performing the functions described herein, such as a processor device, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic, discrete hardware components or any combination thereof. The processor device can be a microprocessor, but in an alternative, the processor device can be a controller, a microcontroller or a state machine, a combination thereof and the like. The processor device can include a circuit configured to process computer executable instructions. In another embodiment, the processor device includes an FPGA or other programmable devices that perform logical operations without processing computer executable instructions. The processor device can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although this article is mainly described with respect to digital technology, the processor device can also mainly include analog components. For example, some or all of the rendering techniques described herein may be implemented in analog circuitry or mixed analog and digital circuitry. The computing environment may include any type of computer system, including but not limited to a microprocessor-based computer system, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computing engine within a device, to name a few.

[0086] The elements of the method, process, routine or algorithm described in conjunction with the embodiments disclosed herein can be implemented directly in hardware, in a software module executed by a processor device, or in a combination of the two. The software module can reside in a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM or any other form of non-temporary computer-readable storage medium. An exemplary storage medium can be coupled to a processor device so that the processor device can read information from a storage medium and write information to a storage medium. In an alternative, a storage medium can be integrated with a processor device. The processor device and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In an alternative, the processor device and the storage medium can reside in a user terminal as discrete components.

[0087] Unless otherwise expressly stated, or understood in other ways in the context of use, conditional language used herein (e.g., "may," "might," "for example," and the like) is generally intended to express that certain embodiments include certain features, elements, or steps, while other embodiments do not include these features, elements, or steps. Therefore, such conditional language is generally not intended to imply that features, elements, or steps are in any manner required by one or more embodiments, or that one or more embodiments necessarily include logic for determining whether these features, elements, or steps are included in any particular embodiment or will be performed therein with or without other inputs or prompts. Terms such as "including," "having," and the like are synonymous and are used inclusively in an open-ended manner, and do not exclude additional elements, features, actions, operations, and the like. In addition, the term "or" is used in its inclusive sense (rather than in its exclusive sense) so that, for example, when used to connect a list of elements, the term "or" represents one, some, or all of the elements in the list.

[0088] Unless expressly stated otherwise, disjunctive language such as the phrase "at least one of X, Y, or Z" is otherwise understood in the context of common usage to indicate that an item, term, etc. may be X, Y, or Z, or any combination thereof (e.g., X, Y, or Z). Thus, such disjunctive language is generally not intended to, and should not, imply that certain embodiments require the presence of at least one of X, at least one of Y, and at least one of Z, respectively.

[0089] The above may be better understood in light of the following additional terms:

[0090] 1. A computer-implemented method comprising:

[0091] It is implemented by one or more computing devices configured with specific executable instructions.

[0092] Receives the name of a media object stored in an asset data store;

[0093] receiving an identification of a storage location of the media object in the asset data store;

[0094] generating a hash value for the media object based on the storage location of the media object in the asset data store;

[0095] generating a modified media object name for the media object based on the hash value and the name of the media object;

[0096] mapping the name of the media object to the modified media object name;

[0097] mapping the storage location to the modified media object name;

[0098] storing said mapping of said name of said media object to said modified media object name in a lookup key data store; and

[0099] storing said mapping of said storage location to said modified media object name in said lookup key data storage area,

[0100] Wherein storing the mapping of the name of the media object to the modified media object name and the mapping of the storage location to the modified media object name causes the lookup key data storage area to be indexed based on the modified media object name.

[0101] 2. The computer-implemented method of clause 1, further comprising:

[0102] receiving a request from a user device to access the media object;

[0103] determining that the user device is authorized to access the media object;

[0104] querying the lookup key data store using the name of the media object to identify that the modified media object name is mapped to the name of the media object;

[0105] querying the lookup key data storage area to identify that the media object is stored at the storage location using the modified media object name;

[0106] retrieving the media object from the storage location; and

[0107] The media object is transmitted to the user device to satisfy the request.

[0108] 3. The computer-implemented method of clause 1, wherein generating a modified media object name for the media object further comprises appending the hash value as a prefix to the name of the media object to form the modified media object name.

[0109] 4. A computer-implemented method according to clause 1, wherein the media object and the second media object stored in the asset data storage area are both associated with an asset name, and wherein a first character of the name of the media object is the same as a first character of the name of the second media object.

[0110] 5. A computer-implemented method according to clause 4, wherein the first character of the modified media object name and the first character of a second modified media object name corresponding to the second media object are different, so that the modified media object name is listed in a first partition of the lookup key data storage area, and the second modified media object name is listed in a second partition of the lookup key data storage area that is different from the first partition.

[0111] 6. A system comprising:

[0112] Finding a key data store configured to identify a storage location of the media object; and

[0113] An asset storage system comprising at least one processor and at least one memory, wherein the at least one memory comprises instructions that, when executed by the at least one processor, cause the asset storage system to:

[0114] receiving a name of the media object;

[0115] receiving an identification of a storage location of the media object;

[0116] generating a modified media object name for the media object based on the name of the media object;

[0117] mapping the name of the media object to the modified media object name;

[0118] mapping the storage location to the modified media object name;

[0119] storing the mapping of the name of the media object to the modified media object name; and

[0120] storing said mapping of said storage location to said modified media object name,

[0121] Wherein storing the mapping of the name of the media object to the modified media object name and the mapping of the storage location to the modified media object name causes the lookup key data storage area to be indexed based on the modified media object name.

[0122] 7. The system of clause 6, further comprising an asset retrieval server, wherein the second instructions, when executed, cause the asset retrieval server to:

[0123] receiving a request from a user device to access the media object;

[0124] determining that the user device is authorized to access the media object;

[0125] querying the lookup key data store using the name of the media object to identify that the modified media object name is mapped to the name of the media object;

[0126] querying the lookup key data storage area to identify that the media object is stored at the storage location using the modified media object name;

[0127] retrieving the media object from the storage location; and

[0128] The media object is transmitted to the user device to satisfy the request.

[0129] 8. The system of clause 6, wherein the instructions, when executed by the at least one processor, further cause the asset storage system to:

[0130] generating a hash value for the media object based on the storage location of the media object;

[0131] The modified media object name is generated for the media object based on a combination of the hash value and the name of the media object.

[0132] 9. The system of clause 8, wherein the instructions, when executed by the at least one processor, further cause the asset storage system to append the hash value as a prefix to the name of the media object to form the modified media object name.

[0133] 10. The system of clause 6, wherein the instructions, when executed by the at least one processor, further cause the asset storage system to reverse the order of characters in the name of the media object to form the modified media object name.

[0134] 11. The system of clause 6, wherein the media object and the second media object are both associated with an asset name, and wherein a first character of the name of the media object is the same as a first character of the name of the second media object.

[0135] 12. A system according to clause 11, wherein the first character of the modified media object name and the first character of the second modified media object name corresponding to the second media object are different, so that the modified media object name is listed in a first partition of the search key data storage area, and the second modified media object name is listed in a second partition of the search key data storage area that is different from the first partition.

[0136] 13. The system of clause 6, wherein the storage location comprises a file path of the media object.

[0137] 14. A non-transitory computer readable medium having executable program code stored thereon, the executable program code, when executed, instructing one or more computing devices to perform operations, the operations comprising:

[0138] receiving a name of the media object;

[0139] generating a modified media object name for the media object based on the name of the media object;

[0140] mapping the name of the media object to the modified media object name;

[0141] mapping the storage location of the media object to the modified media object name;

[0142] storing the mapping of the name of the media object to the modified media object name; and

[0143] The mapping of the storage location of the media object to the modified media object name is stored.

[0144] 15. The non-transitory computer-readable medium of clause 14, wherein the operations further comprise:

[0145] generating a hash value for the media object based on the storage location of the media object;

[0146] The modified media object name is generated for the media object based on a combination of the hash value and the name of the media object.

[0147] 16. The non-transitory computer-readable medium of clause 15, wherein the operations further comprise appending the hash value as a prefix to the name of the media object to form the modified media object name.

[0148] 17. The non-transitory computer-readable medium of clause 14, wherein the operations further comprise reversing an order of characters in the name of the media object to form the modified media object name.

[0149] 18. The non-transitory computer-readable medium of clause 14, wherein the media object and the second media object are both associated with an asset name, and wherein a first character of the name of the media object is the same as a first character of the name of the second media object.

[0150] 19. A non-transitory computer-readable medium as described in claim 18, wherein the first character of the modified media object name and the first character of a second modified media object name corresponding to the second media object are different, so that the modified media object name is listed in a first partition of the index data storage area, and the second modified media object name is listed in a second partition of the index data storage area that is different from the first partition.

[0151] 20. The non-transitory computer-readable medium of clause 14, wherein storing the mapping of the name of the media object to the modified media object name and the mapping of the storage location of the media object to the modified media object name causes an index data storage area to be indexed based on the modified media object name.

[0152] And the following additional terms:

[0153] 1. A computer-implemented method comprising:

[0154] It is implemented by one or more computing devices configured with specific executable instructions.

[0155] receiving data associated with a media object to be stored, wherein the received data includes a name of the media object, an indication of a name of an asset associated with the media object, and a set of permissions to assign the asset;

[0156] mapping the name of the media object to the asset name;

[0157] mapping the permission set to the asset name;

[0158] storing the mapping of the name of the media object to the asset name in an asset permissions data store;

[0159] storing the mapping of the permission set to the asset name in the asset permission data store;

[0160] receiving a request from a user device to access the media object;

[0161] using the name of the media object, querying the asset permissions data store to identify that the asset name is mapped to the name of the media object;

[0162] using the asset name, querying the asset permissions data store to retrieve the set of permissions mapped to the asset name;

[0163] determining, based on the retrieved set of permissions, that a user associated with the user device is authorized to access the media object;

[0164] retrieving the media object from the asset data store; and

[0165] The media object is transmitted to the user device to satisfy the request.

[0166] 2. The computer-implemented method of clause 1, further comprising:

[0167] receiving a second request from the asset owner device to modify permissions for the asset name based on a second set of permissions;

[0168] mapping the asset name to the second set of permissions; and

[0169] The mapping of the asset name to the second set of permissions is stored in the asset permissions data store.

[0170] 3. The computer-implemented method of clause 1, wherein the media object comprises one of: a movie file, a television program file, a music video file, or an audio book file.

[0171] 4. A system comprising:

[0172] an asset permissions data store configured to identify permissions associated with the media object; and

[0173] An asset storage system comprising a processor and a memory, wherein the memory comprises instructions that, when executed by the processor, cause the asset storage system to:

[0174] receiving data associated with the media object, wherein the received data includes a name of the media object, an indication of a name of an asset associated with the media object, and a set of permissions to assign the asset;

[0175] mapping the name of the media object to the asset name;

[0176] mapping the permission set to the asset name;

[0177] storing the mapping of the names of the media objects to the asset names; and

[0178] storing said mapping of said permission sets to said asset names,

[0179] Wherein the mapping of the name of the media object to the asset name and the mapping of the permission set to the asset name are stored such that the permission set controls access to the media object.

[0180] 5. The system of clause 4, further comprising an asset retrieval server, wherein the second instructions, when executed, cause the asset retrieval server to:

[0181] receiving a request from a user device to access the media object;

[0182] using the name of the media object, querying the asset permissions data store to identify that the asset name is mapped to the name of the media object;

[0183] using the asset name, querying the asset permissions data store to retrieve the set of permissions mapped to the asset name;

[0184] determining that a user associated with the user device is authorized to access the media object;

[0185] retrieving the media object; and

[0186] The media object is transmitted to the user device to satisfy the request.

[0187] 6. The system of clause 4, wherein the instructions, when executed by the processor, further cause the asset storage system to:

[0188] receiving a second request from the asset owner device to modify permissions for the asset name based on a second set of permissions;

[0189] mapping the asset name to the second set of permissions; and

[0190] The mapping of the asset name to the second set of permissions is stored.

[0191] 7. The system of clause 6, wherein the second request includes a time parameter indicating expiration of the second set of permissions.

[0192] 8. The system of clause 4, wherein the instructions, when executed by the processor, further cause the asset storage system to update permissions for the asset name in response to an occurrence of an event.

[0193] 9. The system of clause 8, wherein the event comprises one of: storage of a second media object, expiration of the set of permissions, or modification of the media object.

[0194] 10. The system of clause 4, wherein the instructions, when executed by the processor, further cause the asset storage system to perform a batch operation to move the media object and any other media objects mapped to the asset name from a first storage tier to a second storage tier.

[0195] 11. The system of clause 4, wherein the media object comprises one of: a movie file, a television program file, a music video file, or an audio book file.

[0196] 12. The system of clause 4, wherein the set of permissions includes at least one of: read access granted to the user, write access granted to the user, delete access granted to the user, or update metadata access granted to the user.

[0197] 13. A non-transitory computer readable medium having executable program code stored thereon, the executable program code, when executed, instructing one or more computing devices to perform operations, the operations comprising:

[0198] receiving data associated with a media object, wherein the received data includes a name of the media object and an indication of an asset name associated with the media object;

[0199] mapping the name of the media object to the asset name;

[0200] responsive to determining that the received data does not indicate any permission set, mapping a default permission set to the asset name;

[0201] storing the mapping of the names of the media objects to the asset names; and

[0202] storing said mapping of said default permission set to said asset name,

[0203] Wherein the mapping of the name of the media object to the asset name and the mapping of the default permission set to the asset name are stored such that the default permission set controls access to the media object.

[0204] 14. The non-transitory computer-readable medium of clause 13, wherein the operations further comprise:

[0205] receiving a second request to modify permissions for the asset name based on a second set of permissions;

[0206] mapping the asset name to the second set of permissions; and

[0207] The mapping of the asset name to the second set of permissions is stored.

[0208] 15. The non-transitory computer-readable medium of clause 14, wherein the second request includes a time parameter indicating an expiration of the second set of permissions.

[0209] 16. The non-transitory computer-readable medium of clause 13, wherein the operations further comprise updating permissions for the asset name in response to occurrence of an event.

[0210] 17. The non-transitory computer-readable medium of clause 16, wherein the event comprises one of: storage of a second media object, expiration of the set of permissions, or modification of the media object.

[0211] 18. The non-transitory computer-readable medium of clause 13, wherein the operations further comprise performing a batch operation to move the media object and any other media objects mapped to the asset name from a first storage tier to a second storage tier.

[0212] 19. The non-transitory computer-readable medium of clause 13, wherein the media object comprises one of: a movie file, a television program file, a music video file, or an audio book file.

[0213] 20. The non-transitory computer-readable medium of clause 13, wherein the default permission set comprises at least one of: read access granted to a user, write access granted to the user, delete access granted to the user, or update metadata access granted to the user.

[0214] Although the above specific embodiments have shown, described and pointed out novel features applied to various embodiments, it is understood that various omissions, substitutions and changes can be made to the form and details of the displayed devices or algorithms without departing from the spirit of the present disclosure. It is recognized that certain embodiments described herein can be implemented in a form that does not provide all the features and benefits described herein, because some features can be used or practiced separately from other features. The scope of certain embodiments disclosed herein is represented by the attached claims rather than the previous description. All changes within the meaning and equivalent range of the claims are included within their scope.

Claims

1. A computer-implemented method comprising: It is implemented by one or more computing devices configured with specific executable instructions. Receives the name of a media object stored in an asset data store; receiving an identification of a file path of the media object in the asset data store; generating a hash value for the media object based on at least a portion of the file path for the media object in the asset data store; generating a modified media object name for the media object, the modified media object name comprising the hash value and the name of the media object; mapping the name of the media object to the modified media object name; mapping the file path to the modified media object name; storing said mapping of said name of said media object to said modified media object name in a lookup key data storage area; storing said mapping of said file path to said modified media object name in said lookup key data store, wherein storing said mapping of said name of said media object to said modified media object name and said mapping of said file path to said modified media object name causes said lookup key data store to be indexed based on said modified media object name; receiving a request from a user device to access the media object; using the name of the media object, querying the key data store to identify that the modified media object name is mapped to the name of the media object; querying the key data storage area to identify that the media object is stored at the file path using the modified media object name; Retrieving the media object from the file path; as well as The media object is transmitted to the user device to satisfy the request.

2. The computer-implemented method of claim 1 , further comprising: It is determined that the user device is authorized to access the media object.

3. The computer-implemented method of claim 1, wherein generating a modified media object name for the media object further comprises appending the hash value as a prefix to the name of the media object to form the modified media object name.

4. A computer-implemented method according to claim 1, wherein the media object and the second media object stored in the asset data storage area are both associated with an asset name, and wherein a first character of the name of the media object is the same as a first character of the name of the second media object.

5. A computer-implemented method according to claim 4, wherein the first character of the modified media object name and the first character of the second modified media object name corresponding to the second media object are different, so that the modified media object name is listed in a first partition of the lookup key data storage area, and the second modified media object name is listed in a second partition of the lookup key data storage area that is different from the first partition.

6. A system comprising: Finding a key data store that identifies a file path for the media object; An asset storage system comprising at least one processor and at least one memory, wherein the at least one memory comprises instructions that, when executed by the at least one processor, cause the asset storage system to: receiving a name of the media object; receiving an identification of the file path of the media object; generating a modified media object name for the media object, the modified media object name comprising at least a portion of the file path and a representation of the name of the media object; mapping the name of the media object to the modified media object name; mapping the file path to the modified media object name; storing said mapping of said name of said media object to said modified media object name; storing said mapping of said file paths to said modified media object names, wherein storing said mapping of said name of said media object to said modified media object name and said mapping of said file path to said modified media object name causes said lookup key data store to be indexed based on said modified media object name; as well as An asset retrieval server, wherein the second instruction, when executed, causes the asset retrieval server to: receiving a request from a user device to access the media object; querying the lookup key data store using the name of the media object to identify that the modified media object name is mapped to the name of the media object; Using the modified media object name, querying the lookup key data storage area to identify the media object stored at the file path; retrieving the media object from the file path; as well as The media object is transmitted to the user device to satisfy the request.

7. The system of claim 6, wherein the second instructions, when executed, further cause the asset retrieval server to: It is determined that the user device is authorized to access the media object.

8. The system of claim 6, wherein the instructions, when executed by the at least one processor, further cause the asset storage system to: generating a hash value for the media object based on at least a portion of the file path of the media object; and The modified media object name is generated for the media object based on a combination of the hash value and the name of the media object.

9. The system of claim 8, wherein the instructions, when executed by the at least one processor, further cause the asset storage system to append the hash value as a prefix to the name of the media object to form the modified media object name.

10. The system of claim 6, wherein the instructions, when executed by the at least one processor, further cause the asset storage system to reverse the order of characters in the name of the media object to form the modified media object name.

11. The system of claim 6, wherein the media object and the second media object are both associated with an asset name, and wherein a first character of the name of the media object is the same as a first character of the name of the second media object.

12. A system according to claim 11, wherein the first character of the modified media object name and the first character of the second modified media object name corresponding to the second media object are different, so that the modified media object name is listed in a first partition of the search key data storage area, and the second modified media object name is listed in a second partition of the search key data storage area that is different from the first partition.

13. The system of claim 6, wherein the file path comprises a file path of the media object.

14. A non-transitory computer readable medium having executable program code stored thereon, the executable program code, when executed, instructing one or more computing devices to perform operations, the operations comprising: The name of the receiving media object; generating a modified media object name for the media object, the modified media object name comprising at least a portion of a file path of the media object and a representation of the name of the media object; mapping the name of the media object to the modified media object name; Mapping the file path of the media object to the modified media object name; storing said mapping of said name of said media object to said modified media object name; storing said mapping of said file path of said media object to said modified media object name; receiving a request from a user device to access the media object; using the name of the media object, querying a data store to identify that the modified media object name is mapped to the name of the media object; Using the modified media object name, querying the data storage area to identify the media object stored at the file path; retrieving the media object from the file path; as well as The media object is transmitted to the user device to satisfy the request.

15. The non-transitory computer readable medium of claim 14, wherein the operations further comprise: generating a hash value for the media object based on at least a portion of the file path of the media object; as well as The modified media object name is generated for the media object based on a combination of the hash value and the name of the media object.

16. The non-transitory computer-readable medium of claim 15, wherein the operations further comprise appending the hash value as a prefix to the name of the media object to form the modified media object name.

17. The non-transitory computer-readable medium of claim 14, wherein the operations further comprise reversing an order of characters in the name of the media object to form the modified media object name.

18. The non-transitory computer-readable medium of claim 14, wherein the media object and the second media object are both associated with an asset name, and wherein a first character of the name of the media object is the same as a first character of the name of the second media object.

19. A non-transitory computer-readable medium according to claim 18, wherein the first character of the modified media object name and the first character of the second modified media object name corresponding to the second media object are different, so that the modified media object name is listed in a first partition of the index data storage area, and the second modified media object name is listed in a second partition of the index data storage area that is different from the first partition.

20. The non-transitory computer-readable medium of claim 14, wherein storing the mapping of the name of the media object to the modified media object name and the mapping of the file path of the media object to the modified media object name causes an index data store to be indexed based on the modified media object name.

21. A computer-implemented method comprising: It is implemented by one or more computing devices configured with specific executable instructions. Receives the name of a media object stored in an asset data store; receiving an identification of a file path of the media object in the asset data store; generating a hash value for the media object based on the file path of the media object in the asset data store; generating a modified media object name for the media object, the modified media object name comprising the hash value and the name of the media object; mapping the name of the media object to the modified media object name; mapping the file path to the modified media object name; storing said mapping of said name of said media object to said modified media object name in a lookup key data storage area; storing said mapping of said modified media object names in said lookup key data storage area; wherein storing said mapping of said name of said media object to said modified media object name and said mapping of said file path to said modified media object name causes said lookup key data store to be indexed based on said modified media object name; receiving a request from a user device to access the media object; determining that the user device is authorized to access the media object; querying the lookup key data store using the name of the media object to identify that the modified media object name is mapped to the name of the media object; querying the lookup key data storage area to identify that the media object is stored at the file path using the modified media object name; Retrieving the media object from the file path; as well as The media object is transmitted to the user device to satisfy the request.

Images