EP3991059A1 - Systems and methods for federated searches of assets in disparate dam repositories - Google Patents
Systems and methods for federated searches of assets in disparate dam repositoriesInfo
- Publication number
- EP3991059A1 EP3991059A1 EP20897618.3A EP20897618A EP3991059A1 EP 3991059 A1 EP3991059 A1 EP 3991059A1 EP 20897618 A EP20897618 A EP 20897618A EP 3991059 A1 EP3991059 A1 EP 3991059A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- asset
- assets
- registry
- satellite
- digital
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title description 84
- 238000007726 management method Methods 0.000 claims description 94
- 239000000203 mixture Substances 0.000 claims description 20
- 238000013499 data model Methods 0.000 claims description 6
- 230000004044 response Effects 0.000 claims description 6
- 230000008569 process Effects 0.000 description 52
- 238000009826 distribution Methods 0.000 description 19
- 238000005516 engineering process Methods 0.000 description 15
- 230000007246 mechanism Effects 0.000 description 14
- 238000003860 storage Methods 0.000 description 14
- 230000008859 change Effects 0.000 description 11
- 230000009471 action Effects 0.000 description 10
- 238000013459 approach Methods 0.000 description 9
- 230000008901 benefit Effects 0.000 description 9
- 238000004519 manufacturing process Methods 0.000 description 8
- 230000036961 partial effect Effects 0.000 description 8
- 238000012545 processing Methods 0.000 description 8
- 230000006870 function Effects 0.000 description 7
- 230000001976 improved effect Effects 0.000 description 5
- 238000012546 transfer Methods 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 239000000047 product Substances 0.000 description 4
- 241000287828 Gallus gallus Species 0.000 description 3
- 239000013065 commercial product Substances 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 230000001667 episodic effect Effects 0.000 description 3
- 230000003116 impacting effect Effects 0.000 description 3
- 230000000977 initiatory effect Effects 0.000 description 3
- 230000002452 interceptive effect Effects 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- 230000000007 visual effect Effects 0.000 description 3
- 101000642431 Homo sapiens Pre-mRNA-splicing factor SPF27 Proteins 0.000 description 2
- 241000219739 Lens Species 0.000 description 2
- 102100036347 Pre-mRNA-splicing factor SPF27 Human genes 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 239000004615 ingredient Substances 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000000873 masking effect Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 230000008093 supporting effect Effects 0.000 description 2
- 238000012800 visualization Methods 0.000 description 2
- 229930091051 Arenine Natural products 0.000 description 1
- 235000001453 Glycyrrhiza echinata Nutrition 0.000 description 1
- 244000303040 Glycyrrhiza glabra Species 0.000 description 1
- 235000006200 Glycyrrhiza glabra Nutrition 0.000 description 1
- 235000017382 Glycyrrhiza lepidota Nutrition 0.000 description 1
- 235000014647 Lens culinaris subsp culinaris Nutrition 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000012512 characterization method Methods 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 235000013409 condiments Nutrition 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 235000021438 curry Nutrition 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 238000013497 data interchange Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 238000004880 explosion Methods 0.000 description 1
- 230000001815 facial effect Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000037406 food intake Effects 0.000 description 1
- 229910000078 germane Inorganic materials 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000012432 intermediate storage Methods 0.000 description 1
- 229940010454 licorice Drugs 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 230000001737 promoting effect Effects 0.000 description 1
- 230000002829 reductive effect Effects 0.000 description 1
- 238000007670 refining Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 239000000344 soap Substances 0.000 description 1
- 229940102903 take action Drugs 0.000 description 1
- 230000032258 transport Effects 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
- G06F16/41—Indexing; Data structures therefor; Storage structures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
- G06F16/48—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/70—Information retrieval; Database structures therefor; File system structures therefor of video data
- G06F16/71—Indexing; Data structures therefor; Storage structures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/70—Information retrieval; Database structures therefor; File system structures therefor of video data
- G06F16/78—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/901—Indexing; Data structures therefor; Storage structures
- G06F16/9024—Graphs; Linked lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/907—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/907—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
- G06F16/908—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually using metadata automatically derived from the content
Definitions
- This technology relates to storing, tracking, accessing, and distributing media assets to viewers and business partners. More particularly, the technology relates to systems and methods to flexibly integrate multiple sets of Media Asset Management (MAM) repositories capturing the complex relationships between assets to provide rapid asset navigation, storage, search and retrieval and to managing inbound and outbound intellectual property rights to media assets. The technology also relates to systems and methods for searching content, viewing metadata, viewing content, and collecting media asset information across multiple sets of MAM repositories.
- MAM Media Asset Management
- Devices that capture and produce still images, video images, audio recordings, animations, and other types of audio, visual, and written content allow the creation of large collections of media assets, including digital media assets.
- assets can be stored in a common storage location or distributed across a wide variety of storage locations.
- the assets may also be physically stored on a wide variety of devices such as tape or computer disk.
- tape or computer disk As the number and size of media assets increases and the storage devices become large and varied, it is increasingly difficult to navigate through the assets to locate and access particular content of interest.
- Multi-platform media companies harness and manage assets from disparate sources to deliver interactive and engaging user experiences.
- the existing processes for gathering asset metadata and capturing relationships between assets is often manual, ad-hoc, and frequently, difficult to repeat or update.
- Conventional commercial Media Asset Management (MAM) systems require inclusion of all metadata into a single MAM system to capture relationships. This limits the choice of system to a single vendor or suite. The result is a monolithic system that cannot change quickly as new asset types or business needs are introduced.
- MAM Media Asset Management
- Conventional commercial Media Asset Management (MAM) systems require inclusion of all metadata and assets into a single MAM system to capture relationships (e.g., relationships between assets, relationships between assets and people, relationships between assets, people, and organizations). This limits the choice of a MAM system to a single vendor or suite. The result is a monolithic system that cannot change quickly as new asset types or business needs are introduced and a system that is not well suited to all asset types. For example, the business needs for managing a recipe database are very different than for managing videos or photography. Users of DAM systems need to be able to view all asset types with their metadata and the relationships between them without a deep knowledge of the digital asset management systems.
- These existing commercial systems also have restrictive data models that, because they are more focused on the media assets themselves, cannot represent all of these entities as needed to provide the orbital searches that are critical to content exploration and usage (such as showing all content related to a particular talent).
- Media asset libraries include hundreds of thousands of media assets with complex, opaque, and multi-dimensional relationships to each other and to people and organizations.
- users need a way to search and view inventory of different types of assets, relationships between them (such as which photos and recipes are related to an episode) and related information (such as talent, vendors, locations, and restaurants, for example).
- assets often are stored in specialized digital asset management systems determined by the type of asset and storage locations.
- users need a technique for visualizing and accessing the assets and relationships that does not require knowledge of the specific digital asset management systems and that consolidates the information into an easily consumable format.
- the systems and methods of the invention provide visualization of media assets, relationships between them, and related people and organizations.
- the systems and methods of the invention provide an application layer on top of Media Asset Management (MAM) infrastructure as a single point for content discovery throughout the enterprise.
- the invention provides searching, viewing (of both content and content metadata), retrieving, curating, and processing capabilities across different MAM repositories to efficiently monetize the media.
- the media search invention builds an improved index for a search engine from all asset repositories and asset registries.
- the invention provides technical improvements over existing systems to exploit best-of-breed MAM (and DAM) repositories that are configured and optimized for each media asset type.
- the invention provides an enterprise-wide search of still images, recipes, and videos housed in separate repositories, as well as related people and organizations, and presents a hierarchical structure of assets using an intuitive user interface. Using the interface, operators can act on individual or groups of media assets by launching connected workflows such as editing, downloading files, or ordering assets for distribution. This single platform allows global accessibility, business evolution, and simpler technology updates.
- the media search invention provides improved capabilities related to searching, viewing, and accessing media assets in repositories around the world.
- the invention provides improved availability, ease of information sharing, and enhanced interfaces and search capabilities for assets of all types.
- the invention provides improved search capabilities of digital content including videos, recipes, and still images. Real-time index updates are available as well. Searches may be personalized, filtered, saved, and shared. Metadata can be exported using systems and methods of the invention, and parametric searches can be performed.
- Similar capabilities can be exploited when using the invention to view assets. For example, users can browse assets and view videos, recipes, and still images as well as rights associated with those assets. Viewing details can be personalized and saved for individual users or groups.
- the invention provides expanded media cart capabilities. Users can select groups of assets and place them in the media cart. The selected assets can then be edited individually or in a batch mode. Users can also request additional media (e.g., transcodes, recipes, etc.), create episodic versions of the asset, and download images.
- the invention provides the capability to download and/or transcode instances of the carts and includes a search service, mobile support, and a media asset search application.
- the invention includes services and applications that identify search results, asset details, related assets, and other metadata.
- the search results may be identified using keywords or IDs, for example.
- Other services identify deliverables, proxies, recipes, still images, and closed captioning files.
- Additional processes perform bulk operations, such as downloading multiple files, adding multiple items to an asset cart, and exporting asset metadata.
- the systems and methods of the claimed invention provide a central asset registry of media assets to tie together multiple Digital Asset Management (DAM) repository systems into a unified whole.
- DAM Digital Asset Management
- the systems and methods of the claimed invention can optimize different DAMs for each major media asset type (e.g., video, recipes, images, writings, and the like).
- Implementing a centralized registry in accordance with the claimed invention allows the use of a pluggable system architecture.
- Digital Asset Management (DAM) systems are more general cases of Media Asset Management (MAM) systems. That is, Media Asset Management (MAM) systems include digital assets that are media assets. In this document, the terms are used interchangeably.
- Removing the tracking of asset relationships from the Media Asset Management (MAM) repository and creating a central asset registry elegantly addresses problems with gathering asset metadata (with tags, for example) and capturing relationships between assets and provides the necessary speed, scalability and flexibility to analyze and traverse networks of relationships in a media asset environment.
- MAM Media Asset Management
- the central asset registry tracks and stores the multi-dimensional relationships between the assets. Relationships such as show/series/episode "part of” hierarchies, inbound and outbound intellectual property rights inheritances, media "version” and “variant” derivation histories, "reference” relationships for ancillary materials, and ad-hoc grouping of assets into sets or containers all can be done in the central asset registry. Adding new relationship types is then just a change to the central asset registry, not to the individual MAM repositories.
- the central asset registry can be implemented in any desired technology.
- the tracking of relationship and identifier information is an ideal candidate for a graph database.
- the "graph" in graph database refers to relating objects together as a mathematical graph structure. The entire graph area of mathematics is dedicated to studying and representing relationships. Therefore, the use of a graph database for the central asset registry simplifies the expression of the asset hierarchy, enables flexibility in adding relationship types dynamically, allows rapid retrieval from the asset hierarchy, and opens up analytical opportunities not easily available from other database types.
- the systems and methods of the claimed invention use graph databases to implement a central asset registry as it relates to a media asset system, such as a multi-platform media company, including a cable television network.
- a media asset system such as a multi-platform media company, including a cable television network.
- OTT over-the-top
- the systems implement a central asset registry in conjunction with one or more media asset repositories.
- Each repository that is referenced by the central asset registry is abstracted by a proxy service masking the underlying platform specifics and repository representation. Instead, a uniform record is created in the central asset registry. Needed assets types and supporting repositories can be added quickly and normalized at the registry layer.
- the claimed invention provides an analytical and visual depiction of relationship data.
- the systems and methods provide graph objects corresponding to the relationship data of media assets and categorize the graph objects that represent a network structure. Instead of storing all the asset metadata in one database along with the relationships, the asset metadata can be spread over multiple MAM databases with the relationships consolidated to a central graph database registry.
- the central asset registry of the claimed invention stores its data (and allows queries of the data) in the form of a graph, or network-like structure.
- the graph database of the claimed invention provides performance advantages over conventional relational databases and object-oriented databases.
- the claimed invention provides a system and method of organizing cable television and other non-linear media content into a hierarchical tree of nodes.
- Each node can represent media content, such as a television show, season, episode, segment, or other content.
- the system can navigate between nodes of the graph with a user interface.
- the system employs a property graph data model with nodes, relationships, properties, and labels.
- the nodes function as containers for properties.
- the system uses nodes to represent "things" or "entities” or other things with identities in the realm of media assets, such as cable television content and other non-linear media content including videos viewed on websites, social media, standalone kiosks, and the like.
- Every node can contain one or more "properties," and the properties represent attributes or qualities of the nodes.
- the nodes connect or relate to one another with "relationships.” Each relationship has a name and a direction to help structure the overall data set and to lend semantic clarity to the data set to understand the context of each of the nodes.
- the system also attaches properties to the relationships to denote a quality of that relationship (e.g., a qualifier, a weight, etc.).
- the system also uses metadata (tags) to denote qualities such as a time stamp, or a version number, or the like.
- the system uses "labels" to assign roles to the nodes.
- the system can attach one or more labels to each of the nodes to represent the role(s) the node plays within the cable television media asset hierarchy. Labels allow the system to index and group the nodes and to associate specific constraints with the nodes.
- the system user interface applications and associated services provide graphical data representing related content (assets) within the hierarchy of the assets consolidated from multiple MAM repositories.
- the services can be independent software components that can be called from other software components. For example, a service may look up information in a database and return metadata about an asset. Services are independent in that they are packaged and deployed separately to run on a given computer system. Services can call other services.
- the central asset registry itself and the various underlying repositories are exposed via a software service tier.
- the service tier provides a single programmatic interface to access asset information across all the integrated repositories. Requesting systems or users require no direct access to the underlying repositories, and security and access control can be enforced outside of the federated repositories.
- the service tier also abstracts the location of the repositories from the requesting agent. By providing uniform access to the data, the service tier is analogous to a Domain Name System (DNS) for assets. Physical retrieval of the asset instance is also supported at the service tier level supporting potentially long running asynchronous transfers of large files.
- DNS Domain Name System
- the system user interface browses the hierarchy levels of related assets.
- the related media assets can include an ordered sequence of television show seasons, episodes for each season, video segments for each episode, and the like.
- the services and user interface applications allow the system to traverse the assets by any relationship type such as rights inheritance, derived assets, versions, reformats, reference assets, and the show/series/episode hierarchies example above.
- the node and edge flexibility of the central asset registry allows the creation of arbitrary containers of assets sets called collections and media carts. This approach provides the flexibility to add new node types and edges while maintaining backwards compatibility. Older systems using the data can continue to use the old relationships to traverse, while new systems can take advantage of the new relationships and node types (such as abstract episode, for example).
- Nodes of the hierarchy can be represented through an interface in a row of graphical content or images.
- the media search invention allows internal users and partners to search for shows, episodes, collections, non-linear videos, still images, recipes, people, and organizations across the various MAMs throughout worldwide locations and to access those assets from any location.
- the invention provides a variety of filters to narrow the search results. Users can browse through listings of shows for each brand, search using rich metadata such as keywords or titles, and search for multiple videos using lists of different internal identifiers.
- the invention's user interfaces provide easy navigation between different pages and tabs to find more details. Users can view and download video files, closed caption, and production deliverables and can add videos and recipes to a media cart for exporting metadata to other applications or to initiate workflows in other applications.
- the systems and methods of the invention provide benefits over previous systems by providing a computer infrastructure and framework to search, access, and monetize media assets across multiple platforms and distribution channels.
- the additional application layer over the MAMs provides seamless search/access/distribute across federated repositories.
- queries do not have to be customized for particular MAMs or particular vendors, and all assets are available to users via a unified access point and a single application across enterprise-wide databases in global locations.
- the invention provides improved asset availability and provides a cohesive view of related media assets across asset types. For example, a user may view an episode along with its related recipes, still images, production deliverables, people, and organizations.
- the media search invention provides a modular cart with enhanced security controls around data to support changing business needs, including launching workflows in other applications, easier sharing of assets, and business partner use.
- the media search invention updates the layout of data to ensure that the placement of the data and the needs of the computer systems align with business needs.
- the system and method of the claimed invention provides benefits over previous systems because it can store, manage and represent complex relationships of media assets used by broadcasters, including assets of similar types, of hierarchical relationships, between companies, and among people.
- the systems and methods of the claimed invention are modular and can be integrated with any number of MAM repositories, and new relationships and node types can be added at any time.
- the data corresponding to real-world relationships can be stored in a database in a structure corresponding to the relationships that exists in the digital media field, making manipulation, searching, and representation of the data in the database more efficient and effective.
- the graph engine can include an ontological structure, which is represented in the same manner as the asset relationship data.
- This provides an analytics, querying, and data input platform to maximize the utility of the representations presented to a user and the overall computational power of the graph engine.
- the system is fast and scalable and can thus analyze millions or billions of relationships quickly, accurately and flexibly. For example, query times for finding related items in a graph with 2.5 million nodes and 60 million edges averages under 5 milliseconds (ms), even when hosted on modest computer hardware.
- Conventional relational database queries that depended upon many "join" commands or many recursive joins can be performed many times faster on a graph database, as the traversal query time can be constant no matter how big the graph grows. Traversals in relational databases always get slower as the size of the database increases.
- the central asset registry of the claimed invention uses graph structures for semantic (meaning) queries with nodes, relationships, and properties to represent and store media asserts.
- Semantic queries enable the retrieval of both explicitly and implicitly derived information based on syntactic (rules), semantic (meaning), and structural information contained in data (media assets). Semantic queries deliver precise results or answer more fuzzy and wide open questions through pattern matching and digital reasoning.
- the query processes the actual relationships between information (nodes) and infers the answers from the network of data.
- Each node in the graph database directly and physically includes a list of relationshiprecords that represents its relationships to other nodes. The relationship records are organized by type and direction.
- the central asset registry graph database of the invention associates information with names to each of the participating entities.
- the registry node in the graph database acts as a proxy to the real asset stored in one of (possibly) many repositories. This allows the system to have multiple asset repositories (e.g., still image repository, video image repository, recipe repository, etc.) and allows the system to recognize any of the assets across any of the repositories and makes the overall solution look and feel like a single repository.
- the use of a service layer provides an abstraction layer over the multiple asset repositories. When combined with the central asset registry, the service layer can then transparently direct asset retrieval to the appropriate asset repository.
- the central asset registry can maintain a variety of relationships.
- the central asset registry of the claimed invention can track inbound and outbound rights associated with assets over all the MAM repositories. Such rights tracking can be done by enhancing the central asset registry to track relationships between assets and a contract(s) that bears the rights for that asset.
- rights are hierarchical. For example, the contract at the show level can be different from a contract at the series level, which can be different then a contract at the episode level. The rights are the composition of these contracts tied together. Having rights tied to the asset hierarchy makes it easier to resolve the rights at any given episode or any given time.
- the systems and methods of the claimed invention allow users to fold in restrictions as well.
- inbound rights of a media distributor to a show can include all territories in perpetuity.
- the outbound rights can be a subset of the inbound rights, such as an exclusive right to a Canadian broadcaster to show the episode in Canada for six months.
- the extensible nature of the central asset registry not only allows incorporation of multiple MAM repositories and inheritable attributes such as intellectual property rights, but also provides a way to add new relationship dimensions.
- the system supports adding geographical relationships to quickly find episodes about restaurants in Chicago or locations within an arbitrary map polygon.
- the claimed invention includes a system and method to create a single, uniform, highly performant view of multiple federated repositories.
- One example implementation includes a system for managing digital assets in a distributed repository framework.
- the system includes a plurality of federated repositories connected to a network, and each of the plurality of federated repositories maintains digital assets with metadata tags.
- the system also includes a central registry of digital assets.
- the central registry of digital assets receives relationship information, asset identifiers and location information concerning the digital assets from the plurality of federated repositories based on the metadata tags of the digital assets when a digital asset is saved to one of the plurality of federated repositories.
- the central registry of digital assets stores the relationship information and location information of the digital asset to provide a comprehensive view of the digital assets in the plurality of federated repositories that make up the system.
- the system of the invention can include a central asset registry with an asset relation hierarchy that allows rapid navigation and read performance across assets held in multiple repositories.
- the central asset registry can include an asset relationship hierarchy incorporating multiple media types.
- the central asset registry of digital assets is a graph database.
- the graph database can include a registry node as a proxy to a corresponding digital asset stored in at least one of the federated repositories.
- the graph database objects can show a hierarchy of the assets.
- the graph database can include graph objects corresponding to the relationship data of the digital assets and a categorization of the graph objects representing a hierarchy of the digital assets.
- the graph database can include a property graph data model with nodes, relationships, properties, and labels in a hierarchy of the digital assets.
- a system for managing digital assets in a distributed repository framework in accordance with the claimed invention can include a central asset registry that includes a uniform record to each of the digital assets.
- the system can include a pluggable architecture that provides a proxy of multiple repositories and media types.
- the plurality of federated repositories includes at least one pluggable digital asset management (DAM) repository.
- DAM digital asset management
- the pluggable repository can be configured to house a single digital asset type to allow optimization for that asset type.
- the single digital asset type can be still images, videos, text, recipes, and the like.
- the system for managing digital assets in a distributed repository framework can also include a proxy service masking underlying platform information to abstract the plurality of federated repositories and provide a single interface to the plurality of federated repositories.
- the systems of the invention have the ability to federate repositories and access to assets in disparate geographic locations, such as when the federated repositories are located in disparate geographic locations.
- the central asset registry includes a rights registry.
- the central asset registry receives rights information concerning the digital assets from the plurality of federated repositories based on the metadata tags of the digital assets when a digital asset is saved to one of the plurality of federated repositories.
- the relationship registry and/or rights registry is a pluggable architecture.
- the structure of the invention provides the ability to rapidly add new media types and relationships to other assets while scaling efficiently.
- digital assets saved to one of the plurality of federated repositories can include a new relationship type of relationship information based on the metadata tag of at least one digital asset.
- digital assets saved to one of the plurality of federated repositories can include a new asset type or new media type that includes relationship information and location information concerning the new media type digital asset based on the metadata tag of the at least one digital asset.
- the central asset registry updates the database(s) based on the new media type of asset and its relationship information.
- the central asset registry receives the new media type relationship information and location information when the new media type digital asset is saved to one of the plurality of federated repositories and updates the comprehensive view of the digital assets in the plurality of federated repositories that make up the system.
- the system for managing digital assets in a distributed repository framework includes a service tier that provides a programmatic interface to access digital asset metadata across the plurality of federated repositories. Also, the system can include a digital asset service configured to read metadata tags in the digital assets stored in the federated repositories and provide the metadata tags to the central asset registry.
- the systems and methods for managing digital assets in a distributed repository framework of the claimed invention provide additional capabilities and performance not available with previous systems, both in terms of flexibility to integrate with other commercial systems and in the ability to optimize repositories and registries for each type of data.
- a central registry can be used to integrate diverse repositories into a single overall MAM
- another configuration of the invention uses a central registry to link together a hierarchy of satellite MAM systems in one overall MAM.
- This satellite and central registry system automatically assesses intellectual property rights and inventory related to large numbers of digital assets, including video assets and the like, stored in satellite MAMs where each satellite MAM includes one or more repositories and a local registry.
- the system recognizes the location of the repository (or repositories) in which the digital asset resides.
- the system utilizes a (web) service layer to create a local view of each satellite MAM as well as a unified view across all the multiple satellite MAMs.
- Each satellite MAM may contain one or more repositories appropriate for the various asset types as outlined above.
- each satellite MAM includes a local registry integrating the local repositories and linked back to the central registry.
- a recipe for a Brazilian chicken dish can be stored in a recipe repository in Virginia and/or another repository in Sao Paolo where the asset was created.
- the service layer and central registry brings the local asset registries and repositories together as a single, unified view, regardless of the type and location of the asset repository and asset registry.
- the central registry records the Brazilian chicken dish asset having local copies in a Virginia MAM and Sao Paolo
- the rights registry system associates an asset to a set of inbound and outbound intellectual property rights derived from the contract for that asset. Because rights are hierarchical, just like the assets, there may be a set of intellectual property rights associated at the show level, another set at the series level, and yet another at an episode level. The system determines the rights as the combination/composition of the hierarchies. The system ties the rights to the asset hierarchy to resolve the actual rights a user has in any given asset or at any given point in time.
- a contract for a particular show may include inbound intellectual property rights to the system with restrictions on the outbound rights that can be granted.
- the satellite and central registry can reflect the rights and restrictions in a graph database or other suitable persistent store.
- the graph database of the invention can concisely represent the intellectual property rights associated with the assets.
- the graph database abstracts the hierarchies into a network of relationships where any entity can be related to any other.
- Intellectual property rights are linked to assets, and restrictions and terms may be attributes on the graph edges linking the nodes. Restrictions and terms include territory, time ranges, and language. Intellectual rights may then be traversed to include restrictions such as "find all assets with nonallocated rights in Mexico for a given time frame.”
- the relationships of assets and intellectual property rights leads to a data network that can be navigated or traversed in the same hierarchy as the media, and any related information can be retrieved quickly from any starting point.
- the flexibility and scalability of the graph database accurately represents intellectual property rights at each level of the rights hierarchies and at each level of the asset hierarchy.
- the graph structure of the relationships allows analysis of asset and market sectors, content creation and distribution partnerships, and other opportunities not evident with traditional databases, which are unable to scale to support the types of data volumes and flexibility required for modeling the rights relationships.
- a URI is used for identifying data resources and metadata, and a federated platform query accesses multiple types of data using that URI, regardless of the location and type of database in which the asset is stored.
- Satellite systems may be nested to form a hierarchy.
- An example is shown in Fig 12 where Satellite B 1151 might represent a regional European system which further supports Satellite Bl 1251 and Satellite B2 1252 systems which might represent United Kingdom and Polish local systems.
- Performance enhancements over other available systems is enabled by a combination of nested, federated satellite systems (e.g. Satellite B 1151) with registries covering inventory, rights, and other data about local assets and a central registry providing the same information for all enterprise assets.
- the satellite systems provide a more local view of inventory and intellectual property rights.
- the central registry provides an enterprise view. Queries often can be satisfied at one of the nested satellite levels, precluding the need for a remote query to the central enterprise system.
- Another benefit of the approach using federated systems linked by a central registry is the ability to combine local inventories into a single global inventory.
- the central registry tracks where physical copies of the assets exist anywhere in the enterprise. Users requiring a copy of the physical asset may therefore pull a copy from the closest/fastest location.
- the invention for managing rights and distribution of digital assets in a distributed repository framework includes a plurality of federated repositories connected to a computer network, a satellite repository connected to the computer network, a central registry of digital assets, and a satellite registry of digital assets.
- Each of the federated repositories maintains enterprise digital assets with metadata tags
- the satellite repository maintains a local digital asset with metadata tags.
- the central registry of digital assets receives digital asset rights attributes, relationship attributes, asset identifiers, and location attributes concerning the enterprise digital assets from at least one of the federated repositories based on the metadata tags of the digital assets when a digital asset is saved to one of the plurality of federated repositories.
- the satellite registry of digital assets receives digital asset rights attributes, relationship attributes, asset identifiers, and location attributes concerning a local digital asset from the satellite repository based on the metadata tags of the local digital asset when a local digital asset is saved to the satellite repository.
- the central registry of digital assets registers the local digital asset as an enterprise digital asset upon receiving an indication that the local digital asset will be available throughout the enterprise, and the central registry of digital assets stores the digital asset rights attributes, the relationship attributes , asset identifiers, and location attributes of the digital asset to provide an enterprise-wide view of the digital assets in the federated repositories and the satellite repository that make up the enterprise system.
- the central registry can include a relationship registry and a rights registry, and the central registry can update these registries as a local asset is designated as an enterprise asset that will be available throughout the enterprise system.
- the rights registry can include cached queries, flattened views of hierarchical data, and pre-calculated query values for retrieval and inclusion in a search index of the rights attributes.
- the satellite registry of digital assets can record a global identifier of the enterprise asset upon receiving an indication that the local digital asset will be available throughout the enterprise system.
- Graph databases work well as the central registry and/or as a satellite registry (registries).
- a registry node can be a proxy to digital assets stored in the federated repositories and the satellite repository.
- the graph database of the rights registry can include graph objects corresponding to the rights information of the digital assets and a categorization of the graph objects representing a rights hierarchy of the digital assets.
- the graph database(s) can include a property graph data model with nodes, relationships, properties, and labels in a rights hierarchy of the digital assets.
- the central registry can include a uniform record of each of the digital assets and can automatically resolve intellectual property rights and distribution rights of digital assets stored in the federated repositories and the satellite repository based on the metadata tags of the enterprise digital assets and the local asset.
- the intellectual property rights can include inbound and outbound intellectual property rights, and the outbound intellectual property rights can include restrictions.
- the automatic resolution of intellectual property rights and distribution rights includes tying the intellectual property rights to an asset hierarchy to resolve the intellectual property rights a user has in the digital asset at a point in time.
- the central asset registry, the relationship registry, and/or rights registry can be pluggable between systems and system architectures. Additionally, the central registry can include an asset rights hierarchy for rapid navigation across digital assets in the federated repositories and the satellite repository. The central registry can include an asset rights hierarchy with multiple media types. Further, the repositories can be in different geographic locations. [00058] In the systems of the invention, when a digital asset is saved to the satellite repository, new and different rights types and rights information can be specified by metadata tag of the digital asset.
- the systems of the invention can also include a service tier that provides access to the metadata in all the repositories.
- the service tier can provide a programmatic interface to access digital asset metadata across the federated repositories and the satellite repository that make up the enterprise.
- the systems of the invention can also include a digital asset service that reads the metadata tags in the digital assets stored in the federated repositories and the satellite repository and provides the metadata tags to the central registry of digital assets.
- a digital asset service that reads the metadata tags in the digital assets stored in the federated repositories and the satellite repository and provides the metadata tags to the central registry of digital assets.
- Key features of the invention include the aforementioned federation of satellite media DAMs and the ability to leverage (asset) relationship data in a relationship service. The former, in combination with a "take-action" feature, allows users to find and use content without having knowledge or necessary navigation familiarity with the underlying source DAMs.
- the latter allows users to find content without having to know media and DAM-specific identifiers (e.g., a recipe ID versus a cut UUID versus a show code versus a GUID, and other unique identifiers) by using an associative search (e.g., all seasons for "Expedition Unknown," all the images for Episode 3 of Season 6 of "Chopped,” etc.) and other queries using known relationships to locate the asset or entity for which the user is ultimately searching.
- media and DAM-specific identifiers e.g., a recipe ID versus a cut UUID versus a show code versus a GUID, and other unique identifiers
- an associative search e.g., all seasons for "Expedition Unknown," all the images for Episode 3 of Season 6 of "Chopped,” etc.
- the invention provides a single application for searching media assets across different vendors and different MAMs (and DAMs) and extends enterprise-wide database searches to build a media cart of assets.
- the invention improves asset availability with increased efficiency and provides a cohesive view of related media assets across different asset types.
- the media search applications enable location, modification, and distribution of media assets.
- the systems and methods of the invention aggregate all versions of an episode to provide relevant search results and eliminates the need to modify and re-create different versions as well as eliminating multiple versions of the same episode in a search results set of assets.
- the invention includes an interface created for a distributed search and analytics engine, a user interface patterns library, a web service that provides programmatic access to the search index, and a search engine using an index built from metadata from the digital asset management systems and the relationship registry of the central asset registry.
- Data from repositories is consolidated into subject area flat files.
- the interface houses the search engine, allows users to view metadata, allows users to view videos, and collects media asset information.
- the invention updates the layout of the data to ensure that the placement of data aligns with the user's needs.
- the media cart enhances security controls around the data to support changing business needs, including launching workflows in other applications, easier sharing of assets, and concurrent business partner use.
- the invention allows users to search for shows, episodes, collections, non-linear videos, still images, recipes, people, and organizations.
- the index provides a variety of filters to narrow down the search results. Users can browse through listings of shows for different vendors and search multiple videos using lists of internal identifiers.
- the interface provides easy navigation between different pages and tabs to find more details. Users can view and download video files, closed caption, and production deliverables and can add videos and recipes to the media cart for exporting metadata or initiating workflows in other applications.
- the invention includes systems and methods for federated searches of assets in disparate DAM repositories.
- One example embodiment of the invention includes a computerized media search system for searching, viewing, and organizing content and metadata of digital assets in a distributed repository framework.
- the system includes a processor for executing applications stored in a non-transitory computer-readable medium.
- the applications include a search index data collector service configured to construct a linked cross-referenced representation of digital assets in a plurality of federated repositories based on relationship attributes of the digital assets which are stored in a relationship registry.
- Relationship registries can be components of the central registries. Additionally, the relationship registry can include an asset relationship hierarchy for rapid navigation across digital assets incorporating multiple media types.
- the cross-referenced representation of digital assets in the digital asset management system can be a graph database
- the graph database can include graph objects corresponding to relationship attributes of the digital assets and a categorization of the graph objects representing a relationship hierarchy of the digital assets.
- the graph databases can include a property graph data model with nodes, relationships, rights, properties, and labels in a relationship hierarchy of the digital assets.
- the search index data collector service is also configured to provide the linked cross- referenced representation of digital assets in the plurality of federated repositories to a search engine.
- the linked cross-referenced representation of digital assets is in JSON format for each digital asset type.
- the systems and methods in accordance with the invention can also include a federated search service configured to provide an independent programming interface to the search engine and services queries and retrieval requests for the digital assets from the plurality of federated repositories.
- a federated media search application can be included that initiates workflows and operations on digital assets from the plurality of federated repositories as a result of the queries and retrieval requests.
- systems and methods can include a central registry of digital assets, where the central registry of digital assets receives digital asset rights attributes, relationship attributes, asset identifiers, and location attributes concerning the digital assets from one or more of the plurality of federated repositories based on metadata tags of the digital assets when a digital asset is saved to one or more of the plurality of federated repositories.
- the digital assets are stored in both a federated repository and a satellite repository, where the satellite repository maintains a local digital asset with metadata tags.
- the plurality of federated repositories and the satellite repository can be located in disparate geographic locations.
- the systems and methods of the invention can include a satellite registry of digital assets, where the satellite registry of digital assets receives digital asset rights attributes, relationship attributes, asset identifiers, and location attributes concerning a local digital asset from the satellite repository based on the metadata tags of the local digital asset when a local digital asset is saved to the satellite repository.
- a federated media search application builds a satellite registry index of digital assets for each satellite registry by receiving a digital asset attribute from the satellite registry, searching the central registry for relationship attributes of the digital asset associated with the retrieved digital asset attribute, constructing a list of related digital assets and their corresponding satellite registries, retrieving additional digital asset attributes for each of the listed related digital assets, and repeating the receiving, searching, constructing, and retrieving steps for each satellite registry.
- the federated media search application further builds a satellite registry index of digital assets for each satellite registry by cross-referencing the received digital asset attribute and the retrieved digital asset attributes for each of the listed related digital assets across all of the satellite registries.
- the invention includes systems and methods that, in response to a type of search query, the federated media search application receives a digital asset attribute that corresponds to the type of search query, searches the search index (part of a pluggable search engine, for example) based on the received digital asset attribute to identify digital assets in the repositories that satisfy the type of search query, and returns a representation of identified digital assets corresponding to the received digital asset attributes to the search engine.
- the search index part of a pluggable search engine, for example
- the federated search service in response to the type of search query, also receives a selection of an identified digital asset corresponding to the received digital asset attribute, searches the search index based on relationship attributes of the selected digital asset to identify related digital assets in the repositories, and returns a representation of identified related digital assets to a search engine.
- the federated search service also can display a relationship attribute of the identified related digital assets to the selected digital asset.
- the invention includes a computerized media search system for searching, viewing, organizing, and editing content and metadata of digital assets in a distributed repository framework.
- Example implementations of systems and methods in accordance with the invention include a processor for executing applications stored in a non-transitory computer-readable medium.
- the applications include a search index data build service that constructs a list of digital assets from a satellite repository, collects asset attributes from each of the listed digital assets, and creates a search record for each of the listed digital assets, where the search record for each of the listed digital assets includes the asset attributes of the listed digital asset.
- the systems and methods in accordance with the invention also include a relationship registry that determines assets related to each of the listed digital assets based upon a relationship attribute of the listed digital asset and that updates the search record for each of the listed digital assets to include identifying information of the related assets.
- the search index data build service constructs the list of digital assets from the satellite repository using a central registry composition service layer and/or a service layer of a satellite DAM corresponding to the satellite repository.
- some example embodiments of the invention include a federated search service that provides an independent programming interface to a search engine and services queries for the digital assets.
- FIG. 1 shows a generic system for registering assets and accessing multiple federated media repositories.
- FIG. 2A shows a sample representation of a media asset hierarchy over one of many possible relationship dimensions.
- FIG. 2B shows a sample representation of an example media asset registry entry used in accordance with the claimed invention.
- FIG. 3 illustrates a dynamic addition of a new asset type in the media asset hierarchy ontology structure of FIG. 2A.
- FIG. 4 shows a dynamic addition of a new relationship type in the media asset hierarchy ontology structure of FIG. 2A.
- FIG. 5 shows a central asset registry system deployed in a cloud infrastructure in accordance with the claimed invention.
- FIG. 6 is a sequence diagram showing one example of how assets can be added to the system and registered and how they may be subsequently accessed via an API interface.
- FIG. 7 shows a component drawing of a central asset registry system deployed in a single computing device.
- FIG. 8 shows a central asset registry system deployed in a data center in accordance with the claimed invention.
- FIG. 9 shows a component drawing of a central asset registry system deployed as a computing device in contact with a network of computing devices.
- FIG. 10 shows a block diagram of a rights system in accordance with the claimed invention.
- FIG. 11 shows an example system for registering assets and accessing multiple federated media repositories and satellite repositories and registries.
- FIG. 12 illustrates example satellite locations with their respective registries, repositories, and their connectivity and interaction with the central asset registry.
- FIG. 13 shows a process flow for an example system registering assets at satellite locations.
- FIG. 14 shows a process flow for an example system searching and retrieving assets at satellite locations.
- FIG. 15 shows an example intellectual property rights model used in the invention.
- FIG. 16 is an adaption of FIG. 4, depicting properties and relationships in an example media search system of the invention for removing sensitive content from programming schedules.
- FIG. 17 is a further adaptation of FIGS. 4 and 16 and illustrates an example search system of the invention for searching for content associated with talent.
- FIG. 18 shows an example search index builder system in accordance with the media search invention.
- FIG. 19 illustrates a simplified component drawing of a media search system in accordance with the invention that includes a federated search service that is a service implementation over a separate, pluggable search engine.
- FIG. 20 shows an example algorithmic process of an example implementation of a full search index build process in accordance with the invention.
- FIG. 21 illustrates an example incremental update process in accordance with the media search invention.
- FIG. 22 shows an example implementation of the media search invention and mechanisms to edit available information in a media asset, including a recipe.
- FIG. 23 shows an example implementation of the media search invention and mechanisms to add media assets to a media cart.
- One example implementation of the invention consolidates data from the central video metadata repository and other source systems into subject area flat files that are used to build a fulltext, distributed database.
- the system uses documents rather than schema or tables.
- the database configuration and architecture allow for real-time searching and analyzing of the media assets and associated data.
- the files in the database can be stored as simple data structures and objects in a variety of data interchange formats, such as JSON (JavaScript Object Notation), for example.
- the files are grouped together by Data Type and Record ID.
- the invention runs a number of different workflows that drive the processing.
- the workflows are typically sets of multiple tasks connected with a start task link that triggers the proper sequence to execute a process. When a workflow is executed, it triggers the start task and other tasks connected in the workflow.
- One example workflow generates JSON files for each specific asset type and one with a list of IDs that have data changes between runs.
- JSON files there are nine JSON files grouped by show, series, episode, segment, NLV (non-linear video), collection, person, organization and recipe.
- Each of the build processes calls a script at the end of their run to build out or upsert the data store that is the primary source for the search application (described further below) and also a support source for several additional applications and processes.
- the full and partial workflows pull data from the central video metadata repository sources and create the show, series, programs, and segment JSON files.
- the workflows share the same core code, and a full build baseline is run each day and the partial build runs continuously. Differences exists in the two runs, such as in the setup, housekeeping tasks, and the amount of data pulled.
- the full build creates a set of baseline JSON files that are used to baseline the data store.
- the partial build pulls in data that has changed between runs and then pushes those changes to the data store via JSON files. Changes are tracked using asset update tables, such as the asset_update_log table.
- the asset update table is updated by triggers on key tables such as assets, asset date, asset relation, asset title, and other asset attributes.
- the triggers place an entry with the table name and update date in the asset update log table.
- the partial build keys on that date and aggregates all of the asset ids that where changed between the last successful index build and the current date and time set for the operating system on which the database resides (e.g., sysdate).
- the processes also send out a JSON file with the system IDs of the assets that were changed. For each JSON file there is a corresponding intermediate storage area for data processing (e.g., a stage table in the ESEARCH_BO schema).
- the table contains record id (asset id), srt group, srt key, and data values.
- Each file includes a header record for each record and a data record that is stored in a single row of data.
- the files are then split into files that are less than 100MB each. They are logically split so that the header and data records are kept in together.
- the files are labeled showl.json, show2.json, segmentl.json, segmentl3.json, etc. Those files are picked up and used to build out or update the data store by a shell script that is called from within the workflow.
- the Recipe, Organization and People JSON files and index creations are handled in additional workflows.
- these stage tables are loaded each day at 0700 and then upserted throughout the day via service lookup calls.
- the central registry data is processed this way to improve workflow performance.
- An additional process that pulls in new and updated closed caption text files related to programs assets can run concurrently or sequentially depending upon the volume of closed caption text files.
- the closed caption text file data is stored in a file (e.g., an Oracle table) and then cached to improve workflow performance.
- the claimed invention provides a central asset registry system, implemented as a graph database.
- the central asset registry system provides a database and set of services to access aggregated information of distributed media asset sources.
- the central asset registry system maintains a list of assets and their relationships.
- the central asset registry provides end users and programmatic access the ability to efficiently query and retrieve assets across multiple repositories in multiple locations.
- the system allows an arbitrary number of underlying repositories to be represented and scaled effectively.
- the claimed invention also provides a pluggable architecture to provide extensibility and dynamic expansion as needed.
- the pluggable architecture supports parallel development by different teams as features can be implemented as separate components. Pluggable repositories may be custom- developed, commercial suites, centrally located, or may be geographically dispersed. Additionally, the pluggable architecture provides a defined interface to facilitate additional development.
- the claimed invention includes a scalable, graph-centric data storage and analysis system (i.e., graph engine instantiating the enterprise logic implemented as service wrappers around a graph database) as the central asset registry.
- the graph engine instantiates, manages, and stores complex networked (related) structures through the use of a relationship or "graph" database.
- the graph database stores and represents actors and relationships as graph structures, instead of table entries in a relational database.
- the data structure of the graph engine uses graph objects to represent the data, including nodes and edges. Each of the graph objects can be defined by and coupled with ontological categories of a particular ontology.
- the ontology includes a cable television ontology— a "concept framework" that models cable television programming interaction as a set of interrelationships between MVPDs (multichannel video programming distributors) and shows.
- a cable television ontology a "concept framework” that models cable television programming interaction as a set of interrelationships between MVPDs (multichannel video programming distributors) and shows.
- MVPDs multichannel video programming distributors
- utilizing data structures that are composed of graph objects, coupled with a particular ontology allows the graph objects to be stored, combined, and represented in a semantically meaningful way, which facilitates data consistency, advanced analytics, and visualization of complex networks.
- a digital asset management (DAM) system is configured to provide management actions and decisions regarding the ingestion, annotation, classification, storage, retrieval, and distribution of digital assets.
- the digital assets include media assets (media content) such as still images, video images, audio recordings, animations, and other types of audio, visual, and written content
- media assets such as still images, video images, audio recordings, animations, and other types of audio, visual, and written content
- MAM media asset management system
- the term "repository” can be used to connote a system for managing a set of metadata about an inventory of digital assets.
- an "asset” is a general term for a media entity such as an episode of a television show. Assets are hierarchical and may be a container for other entities. For example, a show titled “Chopped” could be an asset. A specific episode of that show titled “Fried Chicken Time” would also be an asset.
- An “abstract asset” is a term used to represent a grouping of the variations of a single media entity. For example, an abstract episode would represent a linear broadcast episode for a given show and series. Many variations of the abstract episode may exist, differing in format and editing to meet business requirements.
- the graph engine manages a database that stores graph objects (media assets) that proxy media assets held in one or more media repositories.
- Each media repository holds detailed asset metadata and an inventory of asset instances.
- An instance is the actual media physical object.
- instances include image files of various formats, such as “jpeg,” “tiff,” or “bmp.”
- examples of video instances include digital files of various formats such as “mov,” or “mp4.”
- Instances may be digital or analog and may be physically stored on a variety of media such as tape or computer disk. Instances may exist in multiple physical locations, such as one instance in a repository in data center A with another instance in a repository in data center B. A given asset may have many associated instances.
- a media registry can include many hundreds of millions or billions of graph objects. Repositories can be partitioned from a single storage medium or can be located alongside each other in one physical computer system or can be geographically separated in different computers, different buildings, different cities, and different countries.
- the graph objects in the registry may proxy assets in remote repositories (media DAMs) that allows for the federation of repositories.
- the remote repositories control access to their digital assets. With federated repositories, the size of the maintained data set can be effectively unlimited.
- the underlying detailed metadata for the assets can be located in the individual media repositories.
- the graph objects in the central asset registry act as proxies with identifiers that act as keys into the individual media repositories. In this manner, relationships between assets can be recorded in the graph database without having to import or replicate all the repository metadata.
- a registry can include a set of media assets (graph objects) that include an ontology, that is, a formal naming and definition of the types, properties, and relationships of the media assets.
- the ontology can have a general purpose facility for defining and refining categorical structures and other ontological elements. The ontology does not need to be dedicated to a particular ontological domain, such as cable television. These facilities are also used to define the overall system ontology, which categorizes the objects used in the implementation of the graph engine itself and can be used to build other ontological structures.
- Repositories can contain different ontological structures, but in one embodiment of the invention, every repository contains a base ontology.
- the repositories can include different media asset types.
- one repository can include still image objects
- another repository can include video objects
- another repository can include recipes.
- the base ontology can correspond to a small set of pre-defined unique identifiers.
- the overall system ontology can use these identifiers the same way in every DAM, to identify the built-in ontological categories and other ontology-related objects that are required by the system.
- each DAM repository just needs an asset identifier, which can be used by the central asset registry to link the registry with the given repository.
- the system uses metadata to describe the media assets in the DAM repository.
- the metadata can describe the asset contents, the location of the asset, the means of encoding/decoding, the history of the asset, ownership, access rights, and the like.
- the system uses the Dublin Core schema of vocabulary terms to describe the assets.
- the system uses the PBCore metadata standard as a set of specified fields in the database to catalogue and manage the assets.
- Fig. 5 shows a central asset registry 501 in a cloud deployment to an Amazon Web Service (AWS) cloud environment.
- AWS Amazon Web Service
- This cloud deployment diagram (Fig. 5) can be directly mapped to the generic distributed repository framework shown in Fig. 1.
- the Asset Registry Service 570a, 570b, 570c (collectively shown as an Auto-Scaling Group 570) in Fig. 5 corresponds to the Registry Service Layer 170 in Fig. 1.
- the Neo4j Cluster 502 in Fig. 5 is (are) the database(s) housing the relationship registry 151, the rights registry 153, and the other registry 155 shown in Fig. 1.
- the Neo4j master slave clustering architecture (cluster 502) is a set of database instances working together in a master/slave relationship.
- the cluster management is managed by the Neo4j nodes 505, 506, 507 via a TCP connection between the nodes.
- the nodes 505, 506, 507 handle self-nomination to master and settle consistency checks between the nodes.
- the Service Endpoint 577 in Fig. 5 corresponds to the Service Entry Point 177 in Fig. 1.
- the cloud deployment shown in Fig. 5 leverages Amazon Web Service (AWS) cloud built- in environment functions.
- AWS Amazon Web Service
- the Auto-Scaling Group 570, Elastic Load Balancing 520, 540, and Route 53 DNS 530 are all available as components of the AWS cloud environment.
- auto-scaling group 570 relates redundant copies of a service and/or application over one or more availability zones (essentially different data centers).
- the claimed invention can leverage the inherent capabilities and features of the AWS cloud environment.
- the central asset registry of the claimed invention can capitalize on the capabilities and features of those deployment environments as well.
- Fig. 8 shows a deployment of a central asset registry 801 to a corporate data center environment.
- the corporate data center deployment can be on physical computer systems, virtual systems, or a combination of the two.
- This corporate data center deployment (Fig. 8) can be directly mapped to the generic distributed repository framework shown in Fig 1.
- the Asset Registry Service 870a, 870b, (collectively 870) in Fig. 8 corresponds to the Registry Service Layer 170 in Fig. 1.
- the Neo4j Cluster 802 in Fig. 8 is (are) the database(s) housing the relationship registry 151, the rights registry 153, and the other registry 155 shown in Fig. 1.
- the Neo4j master slave clustering architecture (cluster 802) is a set of database instances working together in a master/slave relationship.
- the cluster management is managed by the Neo4j nodes 805, 806, 807 via a TCP connection between the nodes.
- the nodes 805, 806, 807 handle self-nomination to master and settle consistency checks between the nodes.
- the Service Endpoint 877 corresponds to the Service Entry Point 177 in Fig. 1.
- FIG. 7 shows a central asset registry 701 deployed to a single physical computing device (system 700).
- the web application container 770 of Fig. 7 holds an implementation of the registry service layer 170, DAM Servicel 141, DAM Service2 142, DAM Service3 143, DAM Service n 144, composition service layer 160, and event generator 180 depicted in Fig. 1.
- the computer system 700 holds an instance of registry database 750, including database engine 710 and database files 720.
- the registry database 750 includes an implementation of the relationship registry 151, rights registry 153, and other registry 155 shown in Fig. 1.
- the registry database 750 shown is the Neo4j graph database deployed as a single node. Other databases can be used in a similar fashion.
- the registry service layer contained in the web container 770 can query the database either via a REST service call or via a native API call 730.
- a central asset registry system 100 of media assets in accordance with the claimed invention separates the registry 101 from the various DAMs (repositories) 131, 132, 133, 134.
- the registries 151, 153, 155 together provide a central logical place to hold a list of all the assets spread over the various repositories 131, 132, 133, 134.
- the resultant framework integrates multiple DAMs (repositories) and registries through a service layer allowing abstraction of the actual underlying repositories and registries.
- the architecture allows new DAMs or registries to be plugged into the framework seamlessly. Existing DAMS and registries can be refactored or switched to entirely new technologies without impact to the overall system.
- Fig. 9 provides a simplified component drawing of a system 900 with a central asset registry 901 of media assets separated from the various DAMs (repositories) 131, 132, 133, 134, such as a deployment that can be implemented on a single computer system.
- the central asset registry 901 of media assets shown in the system 900 of Fig. 9 incorporates a registry service layer 970 (akin to registry service layer 170 in Fig. 1) as well as a relationship registry 951, rights registry 953, and other registry 955.
- the central asset registry 901 of media assets of Fig. 9 also includes a composition service layer 960 (akin to composition service layer 160 in Fig.
- the resultant central asset registry 901 of media assets provides a centralized registry as well as services to access the federated media DAMs 131, 132, 133, 134.
- Other configurations of the components are also possible, such as cloud deployments, data center deployments, and the like, as described above.
- the components described with regard to Fig. 9 can also be hosted on separate computer systems to allow for independent clustering and scaling.
- the pluggable modules 102 on the right side of FIG. 1 represent the actual implementations of each registry and DAM (repository).
- Media DAM1 131 can be a repository for image assets implemented by a third party vendor in their data center.
- Media DAM2 132 can be a repository of video assets implemented as a custom system in a cloud data center, such as in a SaaS DAM.
- Media DAM3 133 can be a repository of recipe assets stored in an on-premise system data center. Any number of DAMs can exist and can be distributed geographically and/or implemented to focus on specific asset types (e.g., still image assets, video assets, recipe assets, and the like).
- FIG. 1 shows four DAMs 131, 132, 133, 134, the number and type of DAMs can be scaled and customized based on content stored in each DAM, location of each DAM, vendor and business relationships, and other factors.
- the registries 151, 153, 155 together provide a central logical place to hold a list of all the assets spread over the various DAMs (repositories) 131, 132, 133, 134.
- the resultant framework integrates multiple DAMs (repositories) 131, 132, 133, 134 and registries 151, 153, 155 through a service layer 103 allowing abstraction of the actual underlying DAMs (repositories) and registries.
- the architecture allows new registries to be plugged into the framework seamlessly. Existing DAMS and registries can be refactored or switched to entirely new technologies without impact to the overall system.
- One Relationship Registry 151 may associate assets in a hierarchical inheritance structure such as shows/series/episodes.
- Another Rights Registry 153 may relate the inbound and outbound intellectual property rights to each asset.
- Yet another registry 155 may relate assets to various geographic locations.
- Other registries can also be used to relate assets to business partners.
- the registries 151, 153, 155 can be implemented separately or combined. Also, they may be deployed in a number of combinations such as cloud or on premise. The number and types of registries is expandable and can be based on many factors in addition to the examples listed.
- FIG. 1 depicts the framework 103 built over the actual DAMs (repositories) and registries.
- the framework 103 includes several layers of services. At the lowest layer, a DAM service exists for each actual Media DAM (repository).
- DAM Servicel 141 is a service implementation over Media DAM1 131
- DAM Service2 142 is a service implementation over Media DAM2 132
- DAM Service3 143 is a service implementation over Media DAM3 133
- DAM Service n 144 is a service implementation over Media DAM n 134, and so on for all the actual repositories.
- This service abstraction layer allows any given repository to be replaced by a new vendor implementation, custom system, or even refactoring of an existing repository without disrupting the other DAMs (repositories).
- the DAM services 141, 142, 143, 144 can be optimized for the particular type of media asset stored in each of the DAMs to provide optimal interface service and support.
- a composition service layer 160 exists over each DAM service 141, 142, 143, 144, abstracting the interface to each DAM (repository) 131, 132, 133, 134. In this way, new DAMs can be introduced without changing the service entry point 166 to the composition service layer 160.
- the composition service layer 160 can include asset entity services, instance retrieval services, and search and view capabilities. Consumers of the composition service layer 160 do not have to change when new DAMs are introduced or lower interfaces (such as DAM services 141, 142, 143, 144) change.
- the composition service layer 160 provides a single entry point (composition layer service entry point 166) to access assets from any DAM (repository).
- the registry service layer 170 provides a single entry point 177 to access information from any of the underlying registries 151, 153, 155.
- the use of the registry service layer 170 allows introduction of new registries or changes to implementations of existing registries without impacting consumers of the service via the registry service entry point 177.
- All assets from the various repositories have at least an entry in the relationship registry 151.
- the list of assets in the relationship registry 151 therefore ties all the repositories 131, 132, 133, 134 together.
- the framework 103 provides an event generator 180 to publish events whenever asset metadata, relationships, or physical instances change in the system 100.
- the event generator 180 provides a fast, reliable, and scalable message queuing service. Subscribers can access queues and topics to exchange data using point-to-point or publish and subscribe patterns.
- the event stream 185 is available for any other system to be notified of changes in any aspect of the data contained in one of the pluggable modules (registries 151, 153, 155 or DAMs 131, 132, 133, 134).
- FIG. 1 shows a central asset registry system 100 for registering and accessing assets over multiple federated media repositories (DAMs 131, 132, 133, 134).
- DAMs 131, 132, 133, 134 federated media repositories
- FIG. 2B upon ingest, each media asset (registry entry) 290 is added to the central asset registry 101 and assigned a unique identifier 280 via the central asset registry service 170.
- Detailed metadata about the asset and the physical asset itself is placed in a repository (DAMs 131, 132, 133, 134). That unique identifier 280 is used to "relate" the asset 290 to a position in an asset hierarchy 200 (shown in FIG. 2A).
- the repository (DAMs 131, 132, 133, 134) maintains the detailed metadata about the asset 290 and the instance inventory.
- Multiple repositories (DAMs 131, 132, 133, 134) can exist distributed over multiple geographic areas or separated by asset type.
- a central asset registry 101 is used to hold the identifiers 280 of assets over all repositories (DAMs 131, 132, 133, 134) and holds the relationships between the assets 290.
- the central asset registry 101 can have a sparse set of metadata including reference to the underlying repository (DAM 131, for example) with asset and instance location.
- location of asset repository 270 and instance entities are represented by a URI and other descriptive metadata.
- the central asset registry 101 can be implemented as a graph database to efficiently track asset relationship and identifier information.
- FIG. 2A shows an example media asset hierarchy 200 as a directed graph.
- graph edges or relationships can be "directed” or "undirected.”
- a directed relationship points explicitly from one node to another.
- a directed edge may point from a "Show” 205 to a "Series 1" 215 with edge type "Has Part” 210.
- An undirected edge can be used to point from one peer to another, without implying a hierarchy.
- an undirected edge may point from one variant of an episode to another or from one actor to another.
- category nodes must be organized into a categorical structure, such as a hierarchy, where categories "lower” in the hierarchy represent specializations (or descendants) of categories “higher” in the hierarchy.
- categories “lower” in the hierarchy represent specializations (or descendants) of categories “higher” in the hierarchy.
- the node that represents the category of "Show” 205 might have several more specific descendant categories that represent specific kinds of shows, including different "Series” of the "Show” 205, such as "Seriesl” 215 and "Series n” 216.
- the graph engine can include as part of the built-in ontology an edge category called "Has Part" 210.
- an edge that refers to the "Has Part” 210 as its ontological category can link, for example, the "Show" category node 205 with a descendant category node, such as "Seriesl” 215, to indicate that the "Seriesl” category node 215 is a sub-type of the "Show” category node 205.
- the semantic meaning of edges 210 that are marked with the "Has Part” category can be part of the built-in ontology of the graph engine, and can be how the ontological machinery is boot-strapped.
- Another example can be the addition of "Pilots" 317 and "Specials” 319 as new asset types as shown in the asset hierarchy 300 in FIG. 3.
- the use of a graph database allows new asset types to be dynamically added without refactoring the rest of the system or any clients that access the graph engine. Client modules or downstream systems that don't need to know about "Specials" can continue to use the system without change.
- Using media assets as a graph allows dynamic addition of new relationship types, such as the ability to relate people to media assets and include their role such as "Host,” 444 "Producer,” 446 and so forth as shown in the asset hierarchy 400 in FIG. 4. Relationship types may be added dynamically without refactoring the rest of the system or any clients that access the graph engine.
- Integration to the system 100 shown in FIG. 1 is via the Registry Service Entry Point 177, The Composition Layer Service Entry Point 166, and the Event Stream 185.
- the implementation of the module integrating to the service entry points 177, 166, 185 might be a graphical user interface, an API call from another system, a module polling a watch folder, or other mechanism. Calls using an API interface, for example, typically involve REST or SOAP protocols via HTTP over TCP/IP networks. Interface via a graphical user interface might involve a web browser-based application, a thick client installed on a workstation, or other user interface technology.
- a media database of the claimed invention can include people, who are actors, directors, producers, and the like.
- the media database also includes movies, videos, television shows, still pictures, and other "productions" that are viewed by an audience. Many actors appear in many television shows, and many video productions. The actors' roles can be defined and tracked as well. Additionally, television shows can include a number of different episodes, and actors may star in a single episode or in many episodes over many seasons.
- FIG. 6 is a sequence diagram showing one example of how assets may be added to the system 100 and how they may be subsequently accessed via an API interface.
- the client module 699 calls the Composition Service Layer 160 to create an episode asset 601, which directs the call to the Video Repository Service 142 to create the episode asset 603.
- the Video Repository Service 142 provides a service wrapper over the actual Video Media DAM 132 to create an episode asset DAM record 605.
- the Video Media DAM 132 is responsible for holding the detailed metadata about the new asset and returns a local DAM identifier 607 to the Video Repository Service 142.
- the Video Repository Service 142 now calls the Registry Service Layer 170 to record 609 the new asset in the central asset registry 101.
- the Registry Service Layer 170 calls the Relationship Registry 151 to record 611 the new asset in the graph database, returning 613 the global registry identifier back up the call chain to the Video Repository Service 142.
- the Video Repository Service 142 calls 615 the Event Generator 180 to send out an Asset Creation event 617.
- the Event Generator 180 is responsible to distribute the event to any listeners of the Event Stream.
- instances of the asset may be added to the system.
- Instances are the actual physical objects corresponding to the asset.
- the instance may be an MP3 video file.
- the client module 699 calls the Composition Service Layer 160, which directs the call the Video Repository Service in much the same sequence as when creating an asset. The main difference is in this case the Event Generator would send out an Instance Creation event to indicate a physical copy of the asset has been added to the system.
- the instance (or physical asset files) can be ingested.
- the client module 699 calls the Composition Service Layer 160 to ingest a video instance 641, which directs the call to the Video Repository Service 142 to create the video instance 643.
- the Video Repository Service 142 provides a service wrapper over the actual Video Media DAM 132 to create an instance DAM record 645.
- the Video Media DAM 132 is responsible for holding the detailed metadata about the new instance and returns a local DAM identifier 647 to the Video Repository Service 142.
- the Video Repository Service 142 now calls the Registry Service Layer 170 to record 649 the new instance in the central asset registry 101.
- the Registry Service Layer 170 calls the Relationship Registry 151 to record 651 the new instance in the graph database, returning 653 the global registry identifier back up the call chain to the Video Repository Service 142.
- the Video Repository Service 142 calls 655 the Event Generator 180 to send out an Instance Creation event 657.
- the Event Generator 180 is responsible to distribute the event to any listeners of the Event Stream. [000141] Similar mechanisms exist to modify and delete assets and asset instances. Again, multiple protocols and transports may be used.
- the system can be queried to retrieve metadata, relationships, or the actual instance files.
- the client module 699 calls the Registry Service Layer 170 for a list of related assets 681.
- the Registry Service Layer 170 in turn calls the Relationship Registry 151, retrieves the information 683, and returns the list of related assets back to the client 685.
- the list of related assets can include assets stored in many of the distributed repositories.
- the client query to the central asset registry 101 looks up descriptors and identifiers of the content, and returns an identification of the related assets, their respective locations, and their relationship to one another based upon matching metadata descriptors.
- the system returns pointers to the related assets to provide a list to the user.
- the identification can be provided as thumbnail images of the asset, size, location, rights, and the like.
- the user can then select and receive a digital asset or set of assets from the list.
- the graph data is accessed by accessing a node by index and then traversing through the set of relationships.
- search results can be cached to avoid repeated accessing operations of the same content.
- the central asset registry can be extended to multiple registry types while maintaining a centralized registration of assets from all repositories, thereby maintaining the enterprise ID and relationships between assets.
- the central registry may be expanded by adding another registry focused on intellectual property rights.
- Such a rights registry includes an intellectual property rights model and can be extended by plugging other modules into the framework further defining relationships between assets such as asset hierarchies, intellectual property rights in and rights out, talent roles, and other aspects of the features and restrictions that are tied to each asset.
- Fig. 10 shows two sample implementations of a rights registry as an extension of the central registry in the framework of the claimed invention.
- the rights registry 153 acts as an operational data store holding a copy of the intellectual property rights as rights objects and relationships to media assets in a database 1004.
- an external rights system 1002 acts as a system of record for intellectual property rights and may be a custom implementation or a commercial system.
- the external system is typically responsible for overall contract and intellectual property rights management and supports complex reporting and planning surrounding inbound and outbound intellectual property rights. For example, if a given asset has been licensed exclusively to a third party in Canada for 2017, the asset is not available for further licensing in Canada during that timeframe.
- the intellectual property rights current state data is fed from the external rights system 1002 into the central rights registry 153 via the registry service layer 170.
- the MAM system can make current state intellectual property rights known throughout the enterprise.
- FIG. 10 Another implementation of an intellectual property rights registry depicted in Fig. 10 omits the external rights system 1002 (shown by dashed line around external rights system 1002 in Fig. 10).
- the rights registry 153 (shown in Figs. 11 and 12) becomes the authoritative system of record for intellectual property rights in the central registry 101.
- the rights registry 153 is responsible for tracking the inbound and outbound intellectual property rights for a given asset.
- the difference in this configuration is that the rights registry 153 would have fewer reporting and analytic capabilities than the external rights system 1002.
- the ability to configure the rights registry 153 with or without an external system of record 1002 provides great flexibility to integrate to other systems optimized for contract and rights management. In this configuration the rights registry 153 would provide a minimum set of intellectual property rights management, just as if the data was fed in from the external system 1002.
- the rights registry 153 can be configured in a number of ways to improve performance and optimize capabilities of the system.
- the rights registry 153 includes dependent structures built off the rights objects to increase query speed and to handle the query load. These dependent structures can be cached queries, flattened views of hierarchical data, and pre-calculated values stored in 1008 and kept up to date by the rights registry 153.
- the structures 1008 therefore allow fast retrieval and inclusion in a search index for an application that needs rights information 1010.
- Intellectual property rights associated with the asset hierarchy and inheritance can be used to evaluate the actual rights for any given asset. For example, the rights assigned to a series would need to be considered when determining the rights of a specific episode in the series. Pre-calculating the results of such inheritance can dramatically speed up a query for rights on a specific asset.
- the rights relationship attributes themselves lend to extremely fast queries. Attributes such as license duration, country, music license details, can be added to the relationships and automatically considered by the query, filtering out unwanted or otherwise unavailable assets. Complex queries involving graph traversal including impact of restrictions are substantially faster than those implemented on traditional relational databases as outlined above.
- the system can store the data in a flattened manner. That is, if the rights of a series are changed, the corresponding rights of all children would be changed at the same time. This optimization extends the time to perform update and inserts, but speeds up reading the rights for a given asset.
- the flattened rights can also directly feed a search index build process.
- Fig. 15 shows an intellectual property rights model used in this invention. While there are existing systems that model intellectual property rights, those systems either focus on a small set of intellectual property rights groups with limited extensibility or require all the assets to be held in a single vendor system.
- the modular approach to the central asset registry 101 allows inclusion of other registries such as the rights registry 153 (shown in Figs. 11 and 12).
- Implementing the rights registry 153 as a graph in a graph database allows expansion of rights groups to cover any or all intellectual property rights groups simply, without a system outage. As shown in Fig. 15, these groups might start with exhibition rights 1503 and be expanded to cover other complex groups such as derivative rights 1505, promotion rights 1507, merchandising rights 1509, and licensing rights 1511.
- These major intellectual property rights groups are further divided into subgroups. For example, derivative rights 1505 is subdivided into format rights 1513, rights to edit 1515, and rights to complete 1517, forming a tree structure.
- assets may be associated to any rights group at any level with inheritance. Restrictions on the rights are kept in the graph database edges, allowing very fast, complex queries when determining asset availability for any given purpose.
- distributed satellite registries e.g., satellite A registry 1113 from Fig 11
- Fig. 11 shows an example satellite and central registry system 1100 according to the claimed invention.
- the satellite and central registry system 1100 takes the initial distributed repository framework and the asset hierarchy databases and distributes the registry and repositories (for example, a registry and one or more repositories can be distributed geographically among satellite offices as shown in Fig. 12).
- satellite A registry 1113 and satellite B registry 1163 both access central asset registry 101 via registry service entry point 177.
- Registry service entry point 177 can also provide access to a quick search indexing mechanism implemented in central registry 101.
- a user in satellite A can view enterprise assets through the lens of the central asset registry as if the assets were in a single repository (i.e., media DAMs 131, 132, 133, 134 appear as one, as described above).
- satellite A 1101 in Fig. 12 is geographically separated from the central asset registry 101.
- a local user of satellite A 1101 can search for and retrieve local-only assets without any communication to the central registry 101. Only when a search needs to expand to other satellites would a query be directed to the central registry 101.
- the central registry 101 has a record of all enterprise assets
- the satellite A registry 1113 has a record of all local-only assets and only those enterprise assets that have a local copy in the satellite MAM.
- the traffic to the central registry 101 is greatly reduced. Also, since enterprise users can only see enterprise assets, there is no chance local-only assets might be mistakenly used by other satellites.
- FIG. 12 shows one example implementation of the invention where satellite A 1101 can be Sao Paulo, where local users create and store digital assets in satellite A 1101.
- the actual physical media assets are stored in satellite A MAM 1107 repository and are registered in satellite A registry 1113.
- Assets that will never be used outside the satellite A 1101 are registered as local-only media assets 1103, whereas assets to be used throughout the enterprise are registered as enterprise assets 1105.
- the process of registering enterprise assets 1105 (as opposed to local-only assets) involve a registration to the central asset registry 101 via the central registry service access point 177 as described below.
- Satellite B 1151 is another satellite system, which may be geographically or logically separated from satellite A 1101. Satellite B local-only media assets 1153 are not visible to other satellites or to the central registry 101. Only upon promotion to enterprise assets do the satellite assets get registered to the central registry 101 and become visible to other satellites and the enterprise as a whole.
- the enterprise media assets 1105 may be used outside satellite A 1101 in other enterprise locations, including satellite B 1151. Satellite A 1101 registers these enterprise assets 1105 with the enterprise for users in the rest of the enterprise to become aware of and have access to these enterprise media assets stored in satellite A 1101. Upon registering the enterprise media assets 1105 with the central asset registry 101, users throughout the enterprise have information and knowledge regarding the assets. The once local media assets are now enterprise media assets. However, there is no requirement for satellite A 1101 to register all assets (local media assets 1103 and enterprise media assets 1105) with the central registry. Satellite A 1101 can selectively register assets in this fashion. The assets not registered with the central registry remain local-only media assets 1103.
- a new asset may be registered first in a satellite and then with the central registry as an enterprise asset, this is just one of several ingest paths.
- a new asset may be registered first with the central registry and then physically stored in DAMs 131-134. Copies of the physical asset may or may not be also sent to the satellites.
- the actual implementation of the satellite registries 1113 and 1163 can vary from custom code to commercial products.
- the flexibility to integrate with third party implementations of satellite registries is a major advantage of the invention.
- the invention provides benefits over previous systems as it includes both features from the central registration of enterprise assets, and local registration of local assets.
- the system realizes benefits of a global view of enterprise assets courtesy of the central registry, yet satellites however are free to have their own assets as well.
- the system can be vendor agnostic and plug in other registries, just like it plugs in DAM vendors.
- system wrapper on the service (for example, on satellite A registry service layer 1111 and on satellite B registry service layer 1157)
- the system can be vendor agnostic and plug in other registries, just like it plugs in DAM vendors.
- other asset registry systems either don't allow a federated registry with a distinction between local and enterprise assets, or they require all registries to lock into the same vendor.
- the approach used in this invention provides both federation and the ability to integrate with various vendor products.
- each satellite can have their own satellite registry (satellite A registry 1113, satellite B registry 1163, and the like).
- enterprise media assets 1105 can physically remain in satellite A MAM 1107, but metadata describing the enterprise media asset 1105 is registered in central asset registry 101 giving location information, rights information, and other information regarding the enterprise media asset 1105.
- a query against the central registry 101 or against any of the satellite registries shows an integrated view of the assets held in any of the federated MAMs (e.g., 1107 and 1171) and DAMs.
- the view from the central registry 101 can see all enterprise assets.
- the view from the satellite registries 1113 and 1163 can see both the enterprise assets and those local to the given satellite.
- satellite A physical enterprise media assets held in satellite A MAM 1107 can be copied to other locations (e.g., Media DAM 1 131, Media DAM 2, 132, Media DAM 3, 133, Media DAM n, 134, Satellite B media asset management system 1171, and the like).
- the enterprise physical media assets can then be distributed throughout the enterprise in various MAMs, with central asset registry 101 tracking the assets.
- the hybrid approach to registration allows the enterprise to provide the asset where it is used most, eliminate it where it is not used saving storage costs, store it where storage charges are least expensive, optimize for network traffic by positioning physical copies near the consumer, and take advantage of other storage and access variables that can change over time such as storage latencies.
- the central asset registry 101 tracking the location and rights of enterprise assets, the system knows the asset exists and where the asset exists (along with other information from the asset metadata), and can access it accordingly.
- the resulting system provides faster queries, quicker access to physical media, and is more responsive to load variations.
- a user in satellite A 1101 has a view of the local media assets 1103 in satellite A 1101 as well as the enterprise media assets 1105 physically in satellite A and all other enterprise media assets stored in other locations of the enterprise (e.g., DAMs 131, 132, 133, 134, and satellite B media asset management system 1171) via the registry service access point 177 to access the central asset registry 101.
- users can search the enterprise for assets in a similar fashion.
- the registry service layer 170 provides a single entry point 177 to access information from any of the underlying registries 151, 153, 155 (and now satellite A registry 1113).
- the use of the registry service layer 170 allows introduction of new registries or changes to implementations of existing registries without impacting consumers of the service via the registry service entry point 177.
- All enterprise assets from the various repositories, including enterprise media assets 1105 have at least an entry in the central relationship registry 151.
- the list of assets in the relationship registry 151 therefore ties all the repositories 131, 132, 133, 134, satellite A 1101, and satellite B 1151 together for those assets designated to be enterprise assets.
- Fig. 12 shows only two satellites, satellite A 1101 and satellite B 1151, the configuration is logically extensible to any number of satellites all accessing the central asset registry 101 via register service access point 177.
- each satellite can include more than one registry.
- Satellite B 1151 could include additional satellites Bl and B2 (reference numerals 1251 and 1252, respectively), each with their own registry 1263, 1264 as keeping track of other (local) assets within satellite Bl 1263 and within satellite B2 1264.
- the satellites and satellite registries can be configured based on asset characteristics, rights attributes of the assets, physical storage characteristics, and other business considerations. In all configurations, the central registry 101 is authoritative for enterprise assets, and the satellite registries are authoritative for local-only assets.
- FIG. 13 shows a process flow and program function of the registration of a media asset in a satellite in one example of the claimed invention.
- Registration includes creating a metadata record for the asset in a media DAM (or MAM) and optionally, recording the asset in the central registry for enterprise assets.
- Ingest of the physical media asset is a separate process where the physical asset is associated with metadata record.
- Fig. 13 focuses on the registration of the asset metadata record as opposed to the ingest of the physical asset.
- the process begins when a user creates an asset metadata record in block 1301 at a satellite location, such as satellite A 1101 Fig. 12.
- the satellite A media asset management system 1107 receives a command to create a metadata record.
- satellite A then registers the MAM asset with satellite registry 1113 as a local asset. If the asset is a local-only asset, as determined in block 1309, the process then stops at block 1399.
- the process continues in block 1313 to register the asset with the central registry 101 using registry service access point 177.
- central asset registry 101 uses the registry service layer 170 to update the relationship registry 151 and rights registry 153 in block 1315 characterizing the enterprise media asset 1105 residing in satellite A 1101.
- the rights information is either entered by the user in the satellite MAM 1101, determined by inheritance in the central registry 101, or fed from an external rights system 1002. If determined by inheritance, the asset hierarchy is traversed upwards till a rights object is found. For example if adding an episode, the parent series or show would be checked for rights assignment.
- the updated information is stored and indexed to facilitate retrieval.
- the central asset registry 101 can also update other registries, including Other Registry 155, based upon characteristics of the enterprise media asset 1155.
- a global ID is returned from the central registry 101 to the satellite registry 1117.
- Fig. 13 block 1301 describes an action from an interactive user
- registration may be triggered by any of a typical set of automation such as API call, batch processing, message queueing, or other common automation technique.
- FIG. 14 shows a process flow and program function of the retrieval of a digital asset in one example of the claimed invention.
- Satellite B 1151 from Fig 12 will serve as an example for the asset request process.
- a user e.g., local server 11805 accesses a media asset management system 1171.
- the local server can be a part of a media asset management system as shown by reference numerals 1185 and 1109 in Fig. 12, or the local server can be a different access point to the overall system.
- the search index data build service 1805 is comprised of a search index data collector 1807 and a search index event generator 1809.
- the search index data collector 1807 constructs a cross-referenced representation of each asset present in each of the satellite MAM systems 1831, 1832, 1833, 1834 by using the relationship registry 1851 component of the central registry 1801 to identify and query data for related assets and entities (in one example, actors, production companies, and production managers, among many, may be the related data) and then provide the linked data from the plurality of MAM systems 1831, 1832, 1833, 1834 to a (pluggable) search engine 1810, which processes that data into an optimized search index.
- related assets and entities in one example, actors, production companies, and production managers, among many, may be the related data
- the search engine 1810 can be a bespoke component or a commercial product, so long as it is able to respond to a query and return representations of the media assets, including information about related assets, to the requestor.
- a component of the search index data build service 1805 is a search index event generator 1809 that notifies interested parties when changes recently made to assets are reflected in the search data. This occurs during an incremental or partial search index build.
- FIG. 19 depicts elements of the invention related to search once the relevant data has been provided to the search engine 1910.
- a separate federated search service 1901 provides an independent programming interface to the search engine 1910, regardless of the underlying data presentation of the search index, or the search engine 1910 analyzing that data.
- the federated search service 1901 can be called by programs that wish to query for and retrieve assets (and their relationships) from the plurality of media DAM systems.
- the federated media search application 1920 is a chief consumer of the federated search service 1901 and provides additional functions to initiate relevant business workflows on assets that the user finds and retrieves through the combination of user interface elements in the federated media search application 1920 and other applications (including media distribution application 1921, content association application 1922, and other applications 1923) and the multi-media asset search capabilities exposed by the federated search Service 1901.
- These types of client applications 1920, 1921, 1922, 1923 make search request to the federated search service 1901 rather than to the pluggable search engine.
- the federated search service 1901 interacts with the pluggable search engine 1910.
- Fig. 20 shows an example process flow for the construction of a searchable index or indices comprised of digital asset identifiers, attributes and/or metadata (searchable properties) and relationships to other digital assets (and information germane to each).
- the search index data build program begins in block 2005 by retrieving a single digital asset (i.e., record of the asset) from the satellite registry 1113, 1163 as well as additional asset attributes and/or metadata (that which has been designated as searchable).
- the search index data build service 1805 looks up that asset in the central (asset) registry (1801 in Fig. 18), where information about relationships to other digital assets are stored, and (in blocks 2021 and 2025) constructs a list of all of the asset's parents, siblings and children, as well as which source/satellite registry would be the system of record for each related asset. For each of those related assets, the search index build program 1805 retrieves additional information about that asset from the appropriate satellite registry of record until all familial relationships are exhausted (in block 2009).
- the search index build program 1805 records all of that information in a record or other form suitable for a search index to scan and analyze. The search index build program 1805 then proceeds to the next satellite registry and repeats the process, so that for each satellite registry, a search index containing all of the information pertinent to that type of asset, as well as "cross-references" to assets in other search indices is created.
- satellite registries might contain information and attributes about digital assets, or they might contain information about other entities, such as people, organizations, geographic locations, as examples.
- a user enters any pertinent information into a search text field.
- the search application (related to the pluggable search engine 1810) then makes a request to the search engine 1810, for each known asset or entity type, to query for matching records.
- the search application organizes the results of the different queries by asset or entity type.
- a user can explore the federated digital asset inventory (for example, searching for "condo", and finding all shows with “Condo” (or similar) in the title or description, all talent with “condo” (or similar) in the name, all recipes authored by anyone with "condo” (or similar) in the name or containing ingredients with or like "condo” (e.g.
- search or companies related to any of the digital assets (e.g., Conde Naste) and so on.
- a small subset of pertinent information is displayed.
- the displayed subset of information regarding the search results can be customized based on user preferences, common search results, rights to the content, and other use and workflow factors.
- a user selects a single search result (of any type) of the displayed results to obtain further information. Because each of the constructed search indices contains cross-referenced information to other assets and entities, this information can be easily displayed to users. Examining a specific television episode, for example, the user can view not only details of that episode (e.g., its title, listing description, etc.), but related information such as the rights associated with the episode, when the episode has aired, the people who appeared on the episode, the production company that shot the episode, the show to which the episode belongs (and which season), any still images of the talent, set, location for that episode, and other related information.
- details of that episode e.g., its title, listing description, etc.
- related information such as the rights associated with the episode, when the episode has aired, the people who appeared on the episode, the production company that shot the episode, the show to which the episode belongs (and which season), any still images of the talent, set, location for that episode, and other related information.
- users can request a digital asset by searching for an asset or by displaying a list of available assets based on user-chosen criteria.
- the user (such as local server 1185) uses APIs provided by the media asset management system 1171 to initiate a query.
- the media asset management system 1171 in turn queries the satellite registry 1163 to get a list of assets known to the satellite matching the user query parameters.
- the system can return an asset list that displays asset metadata characteristics including asset title, thumbnails (for graphical assets), asset size, asset location, IP rights, and other asset criteria that can be specified by users.
- Satellite B Registry 1163 has a view of all local media assets 1153 as well as an access point (via registry service access point 177) that provides access to the central asset registry 101 for an enterprise-wide view of all enterprise media assets, including those enterprise media assets 1155 that reside in satellite B 1151, enterprise media assets 1105 that reside in satellite A 1101, and enterprise media assets that reside in other satellite locations and in other media DAMs, including Media DAMs 131, 132, 133, 134, and the like.
- the requesting location that is, satellite B 1151 receives the location information and the rights constraints of the requested digital asset from the central asset registry 101.
- the located media assets can then be retrieved by satellite B if they reside in other locations.
- local server 1185 can retrieve the local media asset 1153 using satellite B media asset management system 1171 as shown in block 1420.
- the satellite B media asset management system 1171 can request authentication credentials (e.g., passwords, certificates, biometric access controls, and the like) from the requesting user prior to retrieving and providing the local digital asset to the requesting user in block 1424 and stopping the process in block 1428.
- local server 1185 via asset management system 1171 can query the satellite B registry 1163 to in turn query the central registry 101 using registry access point 177 as shown in block 1440.
- the central registry 101 checks to determine if the requested digital asset in listed in the central asset registry 101 as an enterprise asset. Since the central registry 101 has a global view of inventory and metadata for enterprise assets, the local satellite registry 1163 can be updated with global inventory information via a single, efficient call. That is, the system does not have to poll the various other satellites in response to individual requests to present a global view.
- the process stops at block 1490.
- the central registry 101 reports the location information, the security constraints, and the IP rights constraints of the requested digital asset back to the satellite registry 1163 which in turn passes the information to the local server 1185 via the media asset management system 1171.
- the process can continue on to block 1476.
- the caching of the physical assets locally combined with CRC values to verify the file is currently dramatically reduces the load on the network, especially for large media files.
- the local media asset management system 1171 does not have a local copy of the physical asset, a list of inventory locations retrieved as part of the block 1468 data is presented to the local user server 1185.
- the local server may then either access the physical file remotely (as in retrieving from a remote cloud storage locations) or request a copy as shown in block 1472.
- the request involves the local media asset management system 1171 calling the service layer entry point 166 (see Fig. 11) to retrieve an authoritative copy from the relevant DAM 131, 132, 133, or 134.
- the located enterprise media assets can then be retrieved by satellite B if they reside in other locations.
- the central asset registry 101 and/or the media asset management system satellite B media asset management system 1171 can request authentication credentials (e.g., passwords, certificates, biometric access controls, and the like) from the requesting user prior to retrieving and providing the local digital asset to the requesting user in block 1476.
- the local media asset management system 1171 can initiate a transcode of the physical asset.
- a new physical asset may be held as a local-only asset in the satellite 1151 or may be go through the registration process described previously in Fig. 13.
- the central registry 101 is updated as shown in block 1480 and the process stops in block 1490.
- the central registry 101 maintains a global inventory of all copies of the physical asset.
- the requesting server/asset management system may know in advance that certain authentication information is needed to receive the enterprise media asset. In those cases, passwords, certificates, and other authentication information can be provided along with the original request for the enterprise media asset.
- FIG. 19 provides a simplified component drawing of a system 1900 with a federated search service 1901 that is a service implementation over a separate, pluggable search engine, such as search engine 1910.
- the search engine may be a commercial product or bespoke. Expertise, cost and other factors will influence which approach is taken, and these factors can vary over time, resulting in transitioning between commercial products, from bespoke to commercial, or vice versa.
- the pluggable engine 1910 includes a query service 1911 to allow clients to submit search requests and includes one or more search indices 1912, 1913, 1914.
- the search indices can represent different (types of) media assets as well as related entities (such as people and organizations, for example) and that those separate indices include information provided by the relationship registry (1851 in Fig. 18) that allows them to be federated and cross-referenced, such that a record in Asset Index 1912, for example, contains enough information to look up related assets in Asset Index 1913.
- the indices can represent different asset types, different subsets of the same asset type sourced from different systems (e.g., geographically distributed source systems), and other subsets of assets.
- the pluggable search engine 1910 may be implemented as a single program running on a single computer server, in one example implementation it is implemented as a cluster of multiple network servers, each running the search engine program/application for purposes of availability, reliability, and scalability. Each network server with the pluggable search engine 1910 executing on it operates on the same data as all others, and with client search queries being randomly directed to any member of the cluster.
- the federated search service 1901 provides an application programming interface that insulates client applications from the underlying implementation of the search engine. It can expose the asset types independently, or as a single search service that operates across all of the underlying asset subsets. It communicates with the pluggable search engine 1910 over a computer network 1999.
- the federated search service 1901 While in practice, it is beneficial for the federated search service 1901 to be in close network proximity to the pluggable search engine 1910, it is not required.
- the federated search service 1901 exposes an application programming interface (API) that allows clients to query for each of the known asset types individually, as well as a generic search capability that retrieves information about one or more assets, regardless of type.
- API application programming interface
- the federated search service 1901 can be implemented as a single program running on a single computer server, but in one example implementation of the invention, the federated search service 1901 includes multiple computer servers running the federated search service 1901 for purposes of availability, reliability and scalability. In one example implementation, the federated search service 1901 executes on multiple computer servers, each running the federated search service 1901 and capable of conducting requests to one or more pluggable search engines 1910.
- Client computers communicate with the federated search service 1901 over a computer network 1999.
- Clients can include applications whose sole purpose is inventory exposure and exploration 1920, as well as other programs 1921, 1922, 1923 that seek to retrieve information about one or more media assets.
- the goal of the search index builder system 1800 shown in FIG. 18 is to collect and federate the asset data from the plurality of media DAMs 1831, 1832, 1833, 1834, in combination with the relationship data provided by the relationship (registry) service layer 1870 such that the entire inventory of media assets and associated entities (e.g., people, organizations, locations) is represented such that the pluggable search engine 1810 can construct a logical, queryable representation of all assets present in the plurality of media DAMs 1831, 1832, 1833, 1834 and to leverage known relationships between assets to provide a mechanism for associative search.
- entities e.g., people, organizations, locations
- sociative search here is intended to convey the notion that, in the absence of knowledge of the underlying asset or entity to be retrieved, a user can use information about a related asset to retrieve it, and then use the known relationships to locate the underlying asset or entity for which the user is ultimately searching.
- a user might be trying to obtain information about a specific television episode but have no specific information about the date (or dates) that the episode aired, or even the title of the episode.
- the user can retrieve the Show, and then from the Show, examine all Seasons (chronologically grouped episodes) for that Show. If the user has no information at all about when the episode aired, the user can still examine all Seasons of the Show. In each season, the user can examine all episodes of that Season. In this manner, the user can find the target episode without knowing any specific information that would allow the episode to be retrieved directly. In this example, only via its association to other known assets (Shows or Seasons) can the episode be located.
- FIG. 20 provides a simplified algorithmic outline of one example implementation of a full search index build process in accordance with the invention.
- full search index indicates that the searchable information for all media assets and related entities is generated "from scratch.”
- a more selective, incremental index update is also described subsequently. Heuristically speaking, this algorithm proceeds from the edge of the system— from the individual satellite DAMs— and proceeds inward to the central relationships registry in order to determine the identifiers of related assets so that the asset type indices can be cross-referenced such that if media asset 1 is related to media asset 2, that media asset 2 is listed as a related asset in the search record of media asset 1, even if it is of a different (asset) type.
- the process begins in block 2005 with the search index builder program retrieving a list of all managed assets from one of the satellite media DAMs. Due to the flexibility of the central asset registry architecture, this can be accomplished in a number of fashions: from the central registry's composition service layer (FIG. 1, reference numeral 160) through any of the DAM services (FIG. 1 reference numerals 141, 142, 143, 144) or directly from the satellite DAMs themselves (FIG. 1 reference numerals 131, 132, 133, 134).
- searchable information of a media type can include its title, the geographical origin of the media, a list of the people participating in the media content, the name of the person or people that created the media as well as technical characterizations of the media and system "audit" information (e.g., the date and time the record for the media asset was created in the internal systems, and by whom; and/or the date and time the record was last updated).
- the satellite DAMs that relationships between media assets and people and organizations are stored.
- those relationships can be maintained by the relationship registry across the plurality of media DAMs.
- the relationships between some of the media assets are stored in the underlying media DAMs, and determining the full breadth of relationships both within and between media asset types includes merging the relationship data in some of the individual media DAMs with that relationship data stored in the relationship registry.
- FIG. 21 illustrates an example incremental update process. As expected, many of the same steps are involved in this incremental update process but are limited to assets described in the change event. Note, that for this process to proceed in this form, the search engine itself supports partial updates of constructed search indices.
- an event in the event stream produced by the central asset registry captures a change to a single asset, so that the list of assets described in block 2107 is a single asset.
- an additional component monitors that event stream and singularizes multiple events occurring over a limited window in time and produces a derivative event that includes information for all the assets updated during that window in time.
- the event produced by the central asset registry and carried over the event stream can include multiple events.
- the system determines the type of updated asset using information included in the event, and in block 2113 the system retrieves all searchable information about the asset from its source and includes it in the search update record. The system then uses the relationship registry to find all assets directly related to the (current) asset in block 2117.
- the search record is further constructed in block 2121 where the related assets' identifying information is included in the search record.
- the updated record is submitted to the search engine for indexing.
- the process (blocks 2109-2125) repeats when there are remaining assets in the event in block 2108. Otherwise, in block 2129 the system creates and sends an event including a list of all assets updated during the process, and the process ends.
- a user can use the federated search application 1920 (in FIG. 19) to search for "Lombok," a city in Indonesia.
- the search engine 1910 can identify all media assets with "Lombok” in the title, or in other relevant information, such as the location where the media was recorded.
- episodic content, titles, and locations are associated and stored at the "abstract episode” representation.
- the search index data is built by traversing relationships (shown in FIG. 16) provided by the relationship registry (e.g., reference numeral 151 in Fig. 1 and 1851 in Fig. 18).
- the search application is able to identify not just the abstract episode as matching "Lombok,” but different variants and versions of the abstract episode (e.g., episodes in different video formats or edited for different time or sponsorships).
- the search engine 1910 then returns this information to the search application 1920.
- Closed caption files are also media assets and are managed independently in a DAM in the plurality of satellite DAMs federated by the central asset registry (such as central asset registry 101 in FIG. 1 or 1801 in Fig. 18).
- the text of the closed caption files is also indexed by the search engine 1920, so that any program mentioning the word "Lombok" in the dialogue of the show can be identified.
- the "Has Part” relationship e.g., 1630
- that closed caption media asset can be linked back to the version with which it is associated.
- FIG. 16 is an adaption of FIG. 4, depicting the properties and relationships in one example system that illustrate this use case.
- the term “Lombok” is present in the closed caption text file 1629 (i.e., "... unlike its neighboring city of Lombok, Sakra has .").
- the "Instance” relationship 1628 links that closed caption file to the closed caption asset 1627.
- the closed caption asset 1627 is linked to an episode “Version 1" 1615.
- the "Version 1" asset 1615 is linked to a "Variant” node 1610 representing a distinct video format (Variant 1).
- search result #1 Abstract Episode 1601.
- the "Recipe” asset 1662 has metadata ("Source”) that includes the “Lombok” term (i.e., “Source: Lombok, Indonesia”). Following the “Reference” relationship 1660 to the "Abstract Episode 2" 1603 to which it is associated, results in search result #3.
- the Caption metadata for the "Image” asset 1666 includes the term “Lombok.” (i.e., “Dinner in Lombok: Mother and daughter prepare chicken curry”). Following the “Reference” relationship 1664 to the "Abstract Episode 2" 1603 to which it is associated, results in a duplicate of search result #3.
- video programs feature heavily in these examples, note that no single media asset type is required.
- a recipe can be related to an image and still have the properties of both the recipe and the image (as well as the nature of the relationship) indexed for search purposes.
- any of the media assets can be related to a person, either through a "Has Part” relationship or a specific role that person may have in that particular media asset.
- “Bobby Smith” can be shown as related via a "Host” relationship to "Abstract Episode n” 1605) or an organization, such as a Publisher.
- Those entities as well, can be managed in a satellite system that— while not a Media DAM per se— would participate as a satellite system and participate in relationships with managed media assets.
- a user can use the federated media search application (1920 in Fig.
- the search engine 1910 can identify all media assets with a relationship to the person "Bobby Smith” or assets with “Bobby Smith” in the descriptive metadata for the media asset. Episodic content, titles, and descriptions are associated and stored at the "abstract episode” representation. Because the search index data is built by traversing relationships provided by the relationship registry (151, 1851) the federated media search application 1920 identifies not just the abstract episode as matching "Bobby Smith” but different variants and versions of the abstract episode (e.g., in different video formats or edited for a different time or sponsorship).
- FIG. 17 is an adaptation of FIG. 16, depicting the properties and relationships in one example system that has been used to illustrate an example of searching for content associated with talent.
- the name "Bobby Smith” is present in the closed caption text file 1729 (i.e., "... famous celebrity chef, Bobby Smith .").
- the "Instance” relationship 1728 links that closed caption file to the closed caption asset 1727.
- the closed caption asset 1727 is linked to an episode “Version” (e.g., "Version 1" 1715).
- the "Version” asset 1715 is linked to a "Variant 1" node 1710 representing a distinct video format.
- search result #1 Abstract Episode 1 1701.
- automated matching against either the audio tracks of the "Binary Video File” 1725 or to facial recognition of Bobby Smith in the video frames can also score a match, and that following the "Instance” relationship 1724 to the "Version 1" asset 1715.
- "Version 1" 1715 has a “Has Version” 1723 relationship to the "Variant 1" asset 1710. It, in turn, is linked to "Abstract Episode 1" 1701 via the "Has Concrete” relationship 1722 between the "Abstract Episode 1" asset 1701 and the "Variant 1" asset 1710. This can be an alternate path to including Abstract Episode 1 1701 as a search result, or potentially a duplicate result if multiple paths to the episode are present.
- the Subject metadata for the "Image” asset 1766 includes the (Subject) name “Bobby Smith.” Following the "Reference” relationship 1764 to the "Abstract Episode 2" 1703 to which it is associated, results in a duplicate of search result #3.
- a user is searching for media assets in order to complete some business function that is related to that media asset.
- the invention builds upon its knowledge of the asset returned in a search result in combination with the knowledge that the central asset registry system has of the underlying media DAMs to provide a mechanism for the user to perform a variety of actions on that media asset.
- a user Prior to the invention, a user would need to have access and knowledge of the source DAMs and/or other business systems and applications in order to complete those actions.
- the user is provided multiple mechanisms to edit the available information in the recipe (e.g., author, title, servings, ingredients, preparation steps, and other recipe information) with an example editing icon 2205 illustrated in FIG. 22.
- the federated media search application 1920 transfers the user directly to the exact spot in the culinary application (a DAM for digital recipes) in which the recipe metadata can be changed, without guidance from the user.
- the user does not need to have knowledge or familiarity with the structure or navigation of the culinary application that manages recipe assets because the search application is aware of all recipe-related identifiers for the recipe media asset.
- the search application transfers that information to the culinary application, which initializes processing within the specific recipe.
- the search application provides a simple mechanism (e.g., a button 2210 next to the search result) that will export and download the recipe in a different digital format from the source DAM. This is also illustrated in FIG. 22.
- a simple mechanism e.g., a button 2210 next to the search result
- the user is provided multiple mechanisms to edit the available information in the video (e.g. title, description, associated talent, keyword classifications, and other video attributes) with examples 2215 also illustrated in FIG. 22.
- the search application directs the user to the exact spot in the video metadata application (e.g., a DAM for digital video) in which the video metadata can be changed, without guidance from the user.
- the user does not need to have knowledge or familiarity with the structure or navigation of the video metadata application that manages video assets because the search application is aware of all video-related identifiers for the video media asset and transfers that information to the video metadata application, which is then able to initialize its processing with the specific video.
- the search application allows the user to easily view the contractual agreement that provided for the commission of the episode.
- the user does not need to have knowledge or familiarity with the structure or navigation of the digital DAM that manages media contracts because the search application is aware of all video-related identifiers for the video media asset and transfers that information to the system that makes, retrieves, and displays contractual information, which is then able to initialize its processing with the specific video.
- FIG. 22 illustrates an editing mechanism 2225 in the search result details that allows the user to view the contractual details for the episode.
- the search application uses like capabilities to Episode metadata editing, provides multiple mechanisms 2215, 2230 for editing the available descriptive metadata for a Season of a television show.
- the search application uses like capabilities to Episode and Season metadata editing, provides multiple mechanisms (e.g., 2235) for editing the available descriptive metadata for a television show.
- the Media Cart can include a heterogeneous collection of media assets, though the search application presents them segregated by asset type.
- the search application provides multiple mechanisms to add media assets to the Media Cart singularly and in bulk.
- Cart Actions 2305 can be performed to add all 20 recipes on the page or all recipes matching search criteria to the media cart as one action.
- a single episode in a page of search results can be added 2310 to the media cart.
- an example 2315 where all episodes in a season or one individual episode can be added to the media cart, and another example 2320 where all non-linear videos in a collection or one individual non-linear video can be added to the media cart.
- Users can perform actions on the collection of media assets for a given asset type. Some actions apply to all media asset types. Others apply to a single type or subset of media asset types.
- users can request a video transcode (i.e., converting a video encoded in one format or specification to another) be performed on a video or videos.
- users can bulk edit the metadata for a program, changing the location or categorical classification of all episodes to the same value in one action.
- users can review the list of assets of a given type present in the media cart as a file readable by other applications, such as Microsoft's Excel.
- the central asset registry can manage enterprise assets in a variety of media asset management systems, including satellite locations. Assets in the satellite locations can be registered as local media assets outside the view of the enterprise, or can be registered as enterprise media assets and tracked and utilized as a part of the enterprise under the watch of the central registry. The system does not need to move physical assets from satellite locations to other databases or repositories.
- the central asset registry provides an enterprise-wide view of all the enterprise assets. In this manner, system network traffic is minimized, there are fewer calls to access and move assets, and the assets can be stored most efficiently.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Library & Information Science (AREA)
- Software Systems (AREA)
- Multimedia (AREA)
- Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
Claims
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/US2020/045377 WO2022031293A1 (en) | 2020-08-07 | 2020-08-07 | Systems and methods for federated searches of assets in disparate dam repositories |
Publications (2)
Publication Number | Publication Date |
---|---|
EP3991059A1 true EP3991059A1 (en) | 2022-05-04 |
EP3991059A4 EP3991059A4 (en) | 2023-04-05 |
Family
ID=80118422
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP20897618.3A Pending EP3991059A4 (en) | 2020-08-07 | 2020-08-07 | Systems and methods for federated searches of assets in disparate dam repositories |
Country Status (2)
Country | Link |
---|---|
EP (1) | EP3991059A4 (en) |
WO (1) | WO2022031293A1 (en) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2024059226A1 (en) * | 2022-09-16 | 2024-03-21 | Shutterstock, Inc. | Language agnostic architecture for a search engine |
CN117931812B (en) * | 2024-03-25 | 2024-06-07 | 北京大数据先进技术研究院 | Digital object element registry system facing data space and searching method |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7136866B2 (en) * | 2002-08-15 | 2006-11-14 | Microsoft Corporation | Media identifier registry |
US8214394B2 (en) * | 2006-03-01 | 2012-07-03 | Oracle International Corporation | Propagating user identities in a secure federated search system |
US10372883B2 (en) * | 2016-06-24 | 2019-08-06 | Scripps Networks Interactive, Inc. | Satellite and central asset registry systems and methods and rights management systems |
WO2018144536A1 (en) * | 2017-01-31 | 2018-08-09 | Scripps Networks Interactive, Inc. | Satellite and central asset registry systems and methods and rights management systems |
-
2020
- 2020-08-07 EP EP20897618.3A patent/EP3991059A4/en active Pending
- 2020-08-07 WO PCT/US2020/045377 patent/WO2022031293A1/en unknown
Also Published As
Publication number | Publication date |
---|---|
EP3991059A4 (en) | 2023-04-05 |
WO2022031293A1 (en) | 2022-02-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10769248B2 (en) | Satellite and central asset registry systems and methods and rights management systems | |
US10452714B2 (en) | Central asset registry system and method | |
US20240160701A1 (en) | Systems and methods for federated searches of assets in disparate dam repositories | |
US20190050471A1 (en) | Display of media asset information | |
CN102713965B (en) | The scalable theme of data source is assembled | |
US6574655B1 (en) | Associative management of multimedia assets and associated resources using multi-domain agent-based communication between heterogeneous peers | |
US20120124478A1 (en) | Metadata Browser | |
JP6062863B2 (en) | Method and apparatus for aggregating server-based media content and LAN-based media content to enable efficient search | |
JP2012531688A (en) | Method for accessing file system file according to metadata, and apparatus for implementing the method | |
EP3577587B1 (en) | Satellite and central asset registry systems and methods and rights management systems | |
EP3991059A1 (en) | Systems and methods for federated searches of assets in disparate dam repositories | |
Hunter | Working towards MetaUtopia-a survey of current metadata research | |
Candela et al. | Current digital library systems: user requirements vs provided functionality | |
US20070271264A1 (en) | Relating objects in different mediums | |
Hunter | A survey of metadata research for organizing the web | |
Gogouvitis et al. | Vision cloud: A cloud storage solution supporting modern media production | |
Detyniecki et al. | Adaptive Multimedia Retrieval. Understanding Media and Adapting to the User: 7th International Workshop, AMR 2009, Madrid, Spain, September 24-25, 2009, Revised Selected Papers | |
Lyu et al. | Architecture & Data Management of XML-Based Digital Video Library | |
Primmer et al. | Creating a relational distributed object store | |
Bailer et al. | Use Case Scenarios | |
Anadiotis et al. | The Content Level (CoMid) | |
Lim et al. | Implementation of Next Generation Digital Libraries |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: UNKNOWN |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20210614 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
RIN1 | Information on inventor provided before grant (corrected) |
Inventor name: KILLINGSWORTH, DENNIS Inventor name: BOEHMANN, BRANT Inventor name: CLIFT, JARROD Inventor name: LOPEZ, PEDRO Inventor name: SEETO, LISA Inventor name: ROBERTS, MELISSA Inventor name: GOODACRE, CHRIS Inventor name: HURST, CHUCK Inventor name: JACKSON, BETH |
|
A4 | Supplementary search report drawn up and despatched |
Effective date: 20230307 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: G06F 21/62 20130101ALI20230301BHEP Ipc: G06F 16/48 20190101ALI20230301BHEP Ipc: G06F 16/41 20190101ALI20230301BHEP Ipc: G06F 16/907 20190101ALI20230301BHEP Ipc: G06F 16/78 20190101ALI20230301BHEP Ipc: G06F 16/71 20190101ALI20230301BHEP Ipc: G06F 16/908 20190101ALI20230301BHEP Ipc: G06F 16/90 20190101ALI20230301BHEP Ipc: G06F 16/901 20190101ALI20230301BHEP Ipc: G06F 16/903 20190101ALI20230301BHEP Ipc: G06F 16/20 20190101ALI20230301BHEP Ipc: G06F 16/22 20190101ALI20230301BHEP Ipc: G06F 16/24 20190101AFI20230301BHEP |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) |