Improved conflict resolution within synchronized composite part-based digital assets

Abstract

Embodiments of the present disclosure are directed to improved conflict resolution within synchronized composite part-based digital assets. The present disclosure is directed to a digital asset conflict resolution system that provides conflict resolution for synchronized composite part-based digital assets. In particular, the digital asset conflict resolution system detects conflicts within composite part-based digital assets and resolves conflicts at the composite part level (i.e., composite part level) within the digital asset based on format-specific rules. In various embodiments, the digital asset conflict resolution system utilizes format-specific rules and rule sets to automatically resolve conflicts at the composite part level within the digital asset without copying the digital asset and without requiring immediate user involvement.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of and priority to U.S. Provisional Patent Application No. 62 / 745,283, filed on October 12, 2018. The entire contents of the foregoing patent application are incorporated herein by reference. Technical Field

[0003] Embodiments of the present disclosure are directed to a digital asset conflict resolution system that provides conflict resolution for synchronized digital assets based on composite parts. Background Art

[0004] The advent of computers and computer technology has provided many benefits to individuals. Some of these benefits include the ability to store files on a network-based server to allow access from multiple devices or by multiple users. For example, various file management systems enable an individual or a group of people to synchronize files across multiple client devices and access their files on the cloud (e.g., via the Internet). Even with these and other advantages, conventional file management systems still have several disadvantages.

[0005] As an example disadvantage, conventional file management systems often limit the ability to access files from multiple locations, particularly if multiple individuals attempt to edit a file at more than one location. For example, conventional file management systems often prevent an individual from modifying a file at one location if the file is also being accessed at another location. Instead, conventional file management systems limit an individual to read-only access at one or each of the locations.

[0006] In some cases, when a certain person accesses a file from a second location simultaneously, many conventional file management systems require that the individual create a copy of the file before the individual can make changes to the file. The practice of creating copies can cause several problems. For example, creating copies can double the amount of storage required to store the file. This includes doubling the amount of storage at each location where the file is stored. Similarly, increasing the number of file copies on the client device can also increase the processing requirements required to access, open, edit and / or remove files.

[0007] Further, by creating copies of files, conventional file management systems waste bandwidth to transfer the file copies. For example, when a copy is created on a client device, the client device transfers a complete copy of the file to a remote storage location. Further, if the file is synchronized to an additional device, the file management system then transfers a copy of the file to each of those locations. As the size of the file increases, the amount of wasted bandwidth also increases.

[0008] As another example, creating a complete copy of a file removes the copy from the original file. For example, by having multiple copies of a file, an individual is often confused about which file is the latest one. For example, if one or more copies of a file include revisions, the individual is left to figure out which copies contain which revisions, whether to merge the revisions between the multiple copies, and / or whether to delete one or more copies that are duplicate versions or outdated versions. Further, these file copies clutter an individual's client device (e.g., multiple copies of the same file begin to appear in folders and directories). As a result, the individual is confused about how to handle each file copy, and in some cases, mistakenly deletes files that include desired revisions.

[0009] Some newer systems have attempted to address the duplicate copy problem. However, if a file has been modified at multiple locations simultaneously, these newer systems have problems with conflict resolution. In fact, these newer systems often encounter conflicts that cannot be resolved. In response, some of these newer systems attempt to resolve such conflicts by merging multiple versions or copies of the file together. However, this often creates a damaged file that the corresponding application cannot open. In another example, some of these newer systems attempt to dispose of one file version in favor of another version. This data loss can be non-optional or problematic.

[0010] Additionally, some of these newer systems attempt to fix the unresolvable change problem by forking the entire file (e.g., creating multiple documents) and then asking the user at a later time which version they want to keep. As discussed above, this is computationally expensive (e.g., the forked document itself needs to be synchronized and stored in duplicate form on all devices), confusing (e.g., the user will have to figure out which parts of the two files are actually different), and complex (e.g., the user may have to copy / paste different parts of the two documents in order to reach the desired resolution).

[0011] Accordingly, conventional and newer document management systems present these and additional challenges and problems.Thus, there remains a need for improvement in the field of document management. Summary of the invention

[0012] One or more embodiments of the present disclosure utilize systems, non-transitory computer-readable media, and methods for improving conflict resolution for composite-part-based synchronized digital assets to provide benefits and / or solve one or more of the foregoing and other problems in the art. In particular, in some embodiments, the system and method detect conflicts within composite-part-based digital assets and resolve conflicts at the composite-part level (e.g., element, attribute, component, or node level) within the digital asset. In fact, the system and method can utilize format-specific rules to automatically resolve composite-part conflicts without duplicating the digital asset.

[0013] For illustration, in various embodiments, these systems and methods detect conflicts between different versions of digital assets. Based on the detected conflicts, these systems and methods traverse the hierarchy of digital asset versions (e.g., step by step through attributes, elements, components, and subnodes) to accurately find differences at the composite part level. For example, when conflicts are identified in different versions of the same composite part (e.g., component) (including the situation where the composite part is modified in one version but removed in another version), these systems and methods identify the format-specific rule set applied to the composite part. Then, using the format-specific rule set, these systems and methods resolve the conflict at the composite part level. If these systems and methods cannot resolve the conflict, these systems and methods propagate the conflict higher up in the hierarchy of the digital asset until the conflict is resolved. In this way, these systems and methods can resolve conflicts without invalidating the digital asset (e.g., making the digital asset unsolvable or damaged), without requiring immediate user attention, and without requiring the digital asset to be copied.

[0014] These and additional features and advantages of one or more embodiments of the present disclosure are outlined in the description that follows and, in part, will be apparent from the description, or may be learned by practicing such example embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] As briefly described below, the present disclosure describes one or more embodiments with additional particularity and detail through the use of the accompanying drawings.

[0016] Figure 1 An overview of detecting and resolving conflicts within a composite-part-based digital asset is illustrated in accordance with one or more embodiments.

[0017] Figure 2 An example manifest showing composite portions of a digital asset is illustrated in accordance with one or more embodiments.

[0018] FIG. 3A to FIG. 3C Illustrated are example schematic diagrams and sequence diagrams for detecting conflicts within composite-part-based digital assets in accordance with one or more embodiments.

[0019] Figure 4 An example schematic diagram illustrating different versions of the same digital asset in accordance with one or more embodiments is illustrated.

[0020] Figure 5 A flow diagram is illustrated for resolving conflicts within a composite-part-based digital asset in accordance with one or more embodiments.

[0021] FIG. 6A to FIG. 6B Illustrated are examples of format-specific rule sets in accordance with one or more embodiments.

[0022] Figure 7 An example schematic diagram of a digital asset conflict resolution system according to one or more embodiments is illustrated.

[0023] Figure 8 Illustrated is an example environment in which a digital asset conflict resolution system may operate in accordance with one or more embodiments.

[0024] Fig. 9 A flow diagram illustrating a series of actions for resolving conflicts within a composite-part-based digital asset in accordance with one or more embodiments.

[0025] Fig.10 A flow diagram is illustrated of a series of actions for resolving conflicts utilizing a format-specific set of rules within a composite-part-based digital asset in accordance with one or more embodiments.

[0026] Fig.11 A block diagram of an exemplary computing device is illustrated in accordance with one or more embodiments. DETAILED DESCRIPTION

[0027] One or more embodiments of the present disclosure include a digital asset conflict resolution system that semantically, efficiently, and effectively resolves conflicts in composite-part-based synchronized digital assets. In particular, the digital asset conflict resolution system (or simply "conflict resolution system") detects conflicts within composite-part-based digital assets and resolves conflicts at the composite-part level within the digital asset based on format-specific rules. In fact, in various embodiments, the conflict resolution system utilizes format-specific rules to automatically resolve conflicts at the composite-part level within the digital asset without duplicating the digital asset.

[0028] For illustration, in one or more embodiments, a conflict resolution system detects conflicts between different versions of a digital asset. Based on the detected conflicts, the conflict resolution system traverses the hierarchy of digital asset versions (e.g., step by step through attributes, elements, components, and subnodes) to identify differences at the composite part level. When conflicts are identified within different versions of the same composite part, the conflict resolution system identifies one or more format-specific rule sets that apply to the composite part. Using the format-specific rule sets, the conflict resolution system resolves semantic conflicts at the composite part level. If the conflict resolution system cannot resolve the conflict, the conflict resolution system propagates the conflict higher up within the hierarchy of the digital asset until the conflict is resolved. In this way, the conflict resolution system can resolve conflicts without invalidating the digital asset (e.g., making the digital asset unsolvable or damaged) and without requiring the entire digital asset to be copied.

[0029] As briefly summarized, a composite-part-based digital asset (or simply a "digital asset") comprises a composite of multiple composite parts. Each composite part includes content within the defined boundaries of the digital asset and can be modified without affecting other composite parts of the digital asset (such as image layers, document pages, or vector graphics of artboards). Some composite parts are themselves composites (e.g., composite parts include child-composite parts or sub-composite parts). Further, as described below with reference to Figure 2 As further described, a manifest can define how composite parts (e.g., components, attributes, elements, and subnodes) constitute a digital asset. In one or more embodiments, a composite-part-based digital asset (e.g., a composite-based digital asset) uses a digital composite technology ("DCX") framework.

[0030] Additionally, the conflict resolution system can synchronize digital assets across multiple devices. Once the digital asset is downloaded from the cloud-based server device to the client device, the conflict resolution system need only synchronize new or modified composite parts (e.g., components, attributes, elements) of the digital asset. However, because the digital asset is accessible on multiple client devices or by multiple applications on the same client device, it is possible that the same composite part may be modified simultaneously from different client devices, users, applications, and / or sources - resulting in the composite parts (e.g., component files) conflicting. FIG. 3A to FIG. 3C Provides additional details on detecting composite section conflicts.

[0031] As mentioned above, the conflict resolution system detects conflicts and resolves these conflicts within the digital asset at the composite part level (e.g., component level). The conflict resolution system can perform conflict detection and resolution at a client device or a server device. For example, in one or more embodiments, the conflict resolution system is located on a cloud-based server device that maintains the digital asset and synchronizes the digital asset. During the synchronization of the digital asset, the conflict resolution system detects composite part conflicts between different versions of the digital asset and can resolve conflicts in real time when synchronizing the digital asset. In fact, the conflict resolution system can resolve semantic conflicts for digital assets in a software-independent manner, even if a given digital asset is only accessible by a specific software application that is not installed on the server device. Further, the conflict resolution system can resolve conflicts within the background synchronization process on a client device or a server device.

[0032] To further explain, the conflict resolution system resolves conflicts at the composite part level based on identifying and applying format-specific semantic rule sets (or simply "rule sets") having format-specific rules (or simply "rules"). In one or more embodiments, the conflict resolution system identifies which rule sets apply to a given composite part (e.g., a component with multiple conflicting versions) based on the composite part's media type (e.g., component file format). In some embodiments, when multiple rule sets are applicable, the conflict resolution system executes only a subset of the applicable rule sets based on rule set priority and specificity.

[0033] Upon selecting one or more applicable rules, the conflict resolution system may apply the selected rules to the conflicting composite part to implement a resolution. In the instance of a conflicting component, typically, the conflict resolution system writes new data to the component to implement a conflict resolution. In practice, based on the media type of the composite part (e.g., component) and the conflict type, the conflict resolution system understands the semantics (i.e., context) of the conflict and applies a resolution that enables the digital asset to remain a valid resolvable file (e.g., the resolved digital asset complies with the grammatical rules of the corresponding software application).

[0034] In various embodiments, the conflict resolution system cannot effectively resolve conflicts of components or other composite parts. In these embodiments, the conflict resolution system can propagate conflicts upward along the hierarchy of the digital asset to be resolved at a higher level. For example, in the case of conflicts of child nodes, the conflict resolution system can resolve conflicts at the parent level based on rules related to the parent node. In this way, the conflict resolution system can resolve conflicts at a higher level within the digital asset, but still prevent the entire digital asset from being copied.

[0035] As shown below Figure 5 As described in more detail, the conflict resolution system can resolve the conflicting composite parts in a variety of ways. Examples of solutions include removing, merging, retaining, restoring, overwriting, propagating the conflicting data between different versions of the composite parts, invalidating or forking the conflicting data. In many embodiments, the conflict resolution system also inserts a flag, notification, or other indication to signal how the conflict was resolved. In this manner, when the user next accesses the resolved digital asset, the conflict resolution system will indicate the solution to the user.

[0036] A digital asset may include multiple conflicts. Therefore, in many embodiments, the conflict resolution system traverses different branches (e.g., conflicting versions) of the digital asset to compare the differences of each composite part (e.g., attributes, elements, components, and child nodes). For each detected difference, the conflict resolution system can identify applicable rules and resolve the conflict at the lowest hierarchical level of the digital asset.

[0037] As mentioned above, the conflict resolution system utilizes semantic rules corresponding to the specific format of the component, attribute type, or element. FIG. 6A to FIG. 6B As described in more detail, rules are organized by format version, level and / or type. Further, each rule includes a rule type, a condition, and a resolution action. The resolution action further includes a trigger and a resolution. In some cases, the conflict resolution system writes semantic data to the digital asset to ensure that the digital asset generates a valid resolvable file as part of the conflict resolution process. Additionally, the conflict resolution system maintains a set of default rules that can be applied to any composite part in the absence of applicability of more specific rules.

[0038] As briefly described above, the conflict resolution system provides many advantages over conventional file management systems. For example, the conflict resolution system provides increased flexibility and improved computing functionality by enabling multiple users, applications, and / or devices to access and edit the same digital asset simultaneously. In addition, the digital asset conflict resolution system enables simultaneous access and editing of any type of composite part-based (e.g., modular) digital assets, not just specific file types. Conventional systems and methods are generally unable to enable multiple users, applications, and / or devices to access and edit the same digital asset simultaneously due to the inability to effectively resolve conflicts across multiple types of digital assets.

[0039] In addition, the conflict resolution system enables computing devices to perform functions faster than conventional file management systems. In particular, the conflict resolution system can take advantage of the efficiency gained by synchronizing only modified composite portions of digital assets rather than synchronizing the entire digital asset. For example, when a conflict is detected for a composite portion, when the conflict is resolved, the conflict resolution system only resolves and synchronizes the resolved composite portion (e.g., component) rather than synchronizing a duplicate copy of the digital asset. Therefore, the conflict resolution system provides improved efficiency to client devices by reducing the computing resources required by the client device to synchronize and store digital assets. Similarly, as an additional advantage, the conflict resolution system provides bandwidth-efficient synchronization between devices so that only a portion of the digital asset is transmitted when the conflicting composite portion is resolved.

[0040] Furthermore, as mentioned above, the conflict resolution system provides improved flexibility by enabling the conflict resolution system to operate with a range of digital assets regardless of their type (e.g., images, documents, presentations, videos, animations, infographics, and other media types). Additionally, the conflict resolution system improves computational flexibility by resolving composite part conflicts at a semantic level rather than just a syntactic level. In practice, conventional systems that attempt to resolve conflicts at a syntactic level are limited to text-based files and / or often create corrupted digital assets that the corresponding application cannot open and / or result in data loss.

[0041] Further, the conflict resolution system provides the benefit of automatically detecting and resolving conflicting versions of digital assets without requiring immediate involvement of an application or user. In this manner, the conflict resolution system can be flexibly utilized on any device (e.g., a client device and / or a server device). In addition, the conflict resolution system provides flexibility by allowing resolution to occur at any time, which enables users to make changes to digital assets in an offline environment and resolve conflicts when the user synchronizes their changes at a later date.

[0042] In view of the following description, additional advantages and benefits of the conflict resolution system will become apparent. Further, as illustrated by the foregoing discussion, the present disclosure utilizes various terms to describe the features and advantages of the conflict resolution system. For example, the term "digital asset" as used herein generally refers to digital data with corresponding usage rights. For example, a user is authorized to create, view, modify and / or delete a digital asset. Examples of digital assets include, but are not limited to: files such as documents (e.g., documents, spreadsheets, and presentations); electronic information; images (e.g., illustrations, animations, and photographs); video; audio content; three-dimensional data; and other digital data that a user can transfer between computing devices.

[0043] Further, the term "composite-part-based digital asset" (or simply "digital asset") includes a composite of multiple composite parts. Examples of composite parts include, but are not limited to, attributes, elements, components, and child nodes. In various embodiments, the digital asset includes a manifest identifying each composite part that makes up the digital asset and the arrangement of the composite parts relative to each other. In addition, the digital asset forms a tree hierarchy (or any structured graph) of composite parts arranged according to attributes, components, and child nodes. Figure 2 Examples of digital assets, lists, and tree hierarchies are provided.

[0044] As used herein, the term "component" refers to a portion of a digital asset. A set of components primarily constitutes a digital asset, including versions of a digital asset (e.g., a digital asset based on composite parts). Generally, each component in a digital asset is an independent file that is modifiable but does not affect other components of the digital asset. However, in some instances, a limited number of components are linked, and changes to one component affect other components. Further, components themselves can be in a composite format to include sub-components (e.g., a table in a document application including vector graphics native to an illustration application or an image from an image application embedded in a page of a layout application).

[0045] In addition, the style of components (e.g., frames) is often based on boundaries within the digital asset and / or based on the type of digital asset. For example, a digital image asset includes layers and sub-layers as components; a digital video asset or video project digital asset includes shorter video clips, titles, and static graphics as components; a digital document asset includes pages, canvases, drawing boards, bitmaps, vector graphics, text boxes and image boxes, rows, columns, and / or graphics as components; and a three-dimensional model digital asset includes grids, maps, scenes, and skins as components. In other cases, the user can select boundaries / parameters for components of a digital asset.

[0046] As mentioned above, each component is associated with an independent file. As used herein, the term "independent file" generally refers to digital data recorded separately in a storage medium. In this way, a file can be accessed, modified, transmitted and / or removed separately from other data files. Since the component is a discrete part of a digital asset, each component can be stored on a computing device as a separate file, stored in a file location or directory that is independent of the location of other components of the digital asset. Therefore, compared with an integral file (which stores all data belonging to a file in a single location), the components in a digital asset can be stored as files distributed on a storage medium (e.g., a local database or cloud storage), such as, on one or more client devices and / or a remote server device.

[0047] The term "format-specific rules" (or simply "rules") refers to guiding data used to help detect and resolve conflicts. In particular, the term "rule" includes a text string that assigns actions to specific composite parts or objects (attributes, components, or nodes) of a digital asset. FIG. 6A to FIG. 6B As described in detail, a rule may include a rule type, a condition, and a resolution action. A resolution action further includes a trigger and a solution. Further, rules may be organized by format version, level, and / or type. In various embodiments, rules are stored in a specific format, such as a domain specific language ("DSL"). Further, rules for a specific media type format or a group of related formats may be grouped into a rule set.

[0048] As used herein, a "format-specific rule set" (or simply a "rule set") is a collection of related rules. For example, a rule set is an encoded text file with a specified extension and rule type. In addition to the rules, a rule set may also include a header portion that defines the rule format version, media types, and the rule set name. In various embodiments, each rule in a rule set corresponds to the same one or more media types specified in the header portion of the rule set. In some embodiments, the rule set is organized by rule specificity, where more specific rules for particular media types and / or conditions are sorted before (or after) more general rules for the same media type and / or condition.

[0049] As used herein, the term "conflict" refers to a difference between versions of a digital asset or a portion thereof. For example, a conflict is detected by a conflict resolution system when two versions of the same digital asset are not identical or equal. In some cases, the conflict resolution system detects two or more unequal coexisting versions of the same digital asset (e.g., an original version, a first modified version, and a second modified version). FIG. 3A to FIG. 3C Additional details are provided for detecting conflicts of digital assets and / or composite portions of digital assets.

[0050] Now refer to Figure 1 , Figure 1 An overview of detecting and resolving conflicts within a composite-part-based digital asset according to one or more embodiments is illustrated. As shown, Figure 1 A series of actions 100 that a conflict resolution system can implement to detect and resolve conflicts are included. In one or more embodiments, the conflict resolution system is located on a server device and implements the series of actions 100 as part of synchronizing digital assets across client devices. In some embodiments, the conflict resolution system is located on a client device.

[0051] The series of actions 100 includes an action 102 of detecting conflicts between different versions of a composite part within a digital asset. As shown, a conflict resolution system (i.e., a digital asset conflict resolution system) can identify multiple concurrent versions of a digital asset. In some embodiments, the conflict resolution system initially identifies different concurrent versions of the same digital asset from two sources. In these embodiments, the conflict resolution system can traverse attributes, components, and child nodes to identify differences between two versions.

[0052] Additionally or alternatively, the conflict resolution system identifies different concurrent versions of the same composite part within different versions of the digital asset. Figure 1 A file A' having compound part 1A and compound part 2 and a file A'' having compound part 1B and compound part 2 are shown. Here, the conflict resolution system determines that compound part 1A of file A' conflicts with compound part 1B of file A''. For example, a user modified compound part 1 at a first source to generate compound part 1A, and a user separately modified compound part 1 at a second source to generate compound part 1B.

[0053] The series of acts 100 also includes an act 104 of identifying one or more format-specific rule sets based on the media type of the first composite part. In particular, when a conflict between different versions of composite part 1 is determined, the conflict resolution system identifies the media type (e.g., component file format) of composite part 1. The conflict resolution system then identifies an applicable rule set corresponding to the media type of the composite part. As in Figure 1 As shown in , the conflict resolution system identifies rule sets 1 to 3 that store rules corresponding to media type A.

[0054] Further, as shown, the series of actions includes an action 106 of resolving the conflicting composite part based on the identified rule set without duplicating the digital asset. In various embodiments, the conflict resolution system utilizes the identified rule set to determine a manner of resolving the conflicting composite part versions. For example, the conflict resolution system merges two modified versions of composite part 1 (i.e., composite part 1A and composite part 1B) or forks two modified versions of composite part 1 (i.e., composite part 1A and composite part 1B). Alternatively, the conflict resolution system replaces, selects, or deletes one of the modified versions of composite part 1. Refer to the following Figure 5 Describes additional details about using rule sets to resolve conflicts.

[0055] When the conflicting composite parts are resolved, in various embodiments, the conflict resolution system can synchronize the resolved composite parts to the corresponding client devices (and / or applications). For example, if two client devices provide different modified versions of composite part 1 (e.g., composite part 1A and composite part 1B), the conflict resolution system provides the updated composite part 1C to both client devices. If the conflict resolution system is located on the client device, the conflict resolution system can synchronize the updated composite part 1C to the server device. As previously mentioned, the conflict resolution system does not need to synchronize the entire updated digital asset, but only needs to synchronize the portion of the digital asset that has been updated (e.g., composite part 1C).

[0056] In some instances, the conflict resolution system cannot resolve conflicts at the composite component level. However, in order to maximize efficiency, the conflict resolution system does not need to copy or fork the entire digital asset. For illustration, when faced with an unresolvable conflict at the component level, the conflict resolution system only forks those parts of the digital asset that contain the unresolvable conflict. For example, if the conflict resolution system detects that the digital asset has a base version with a blue background for a given component, a first modified version with a yellow background for the given component, and a second modified version with a green background for the given component (e.g., one user changes the given component from blue to yellow, and another user changes the given component from blue to green), the conflict resolution system can only fork the given component so that the resolved digital asset contains two versions of the given component—one version with a yellow background and another version with a green background.

[0057] In this manner, the conflict resolution system only needs to synchronize two modified versions of a given component across various client devices, rather than forking and synchronizing two different modified versions of the entire digital asset. Further, the conflict resolution system still resolves conflicts in a manner that is obvious to the user. For example, a user who next accesses the resolved digital asset can easily see the yellow background version and the green background version within the digital asset and decide whether one version should be kept instead of the other.

[0058] As mentioned above, a digital asset can consist of multiple composite parts. For illustration, Figure 2Additional details about the structure of digital assets (i.e., digital assets based on composite parts) are provided. As shown, digital asset 200 is defined by manifest 202 (i.e., composite part manifest). In some embodiments, manifest is a file or list that includes composite parts (such as attributes, components, and child nodes organized into a tree structure). For example, manifest 202 is a JSON file that models the structure of digital asset 200 in hierarchical pairs of nodes. In an alternative embodiment, the manifest is organized as another type of structured graph.

[0059] In many embodiments, the hierarchy of the manifest follows the internal structure. For example, a sketchbook is organized into page components, and an image may consist of a hierarchy of layer components. In addition to the order of the components, the internal structure is typically encoded using child nodes (i.e., Node 1 and Node 2). Child nodes may inherit many of the attribute properties of the root node (i.e., parent node).

[0060] As shown, each node in the node includes attributes, components, and optional child nodes. For example, the root node 204 includes an attribute array 206, a component array 208, and a child node array 210. The attribute array 206 includes metadata attributes that define the node. For example, the attribute array 206 includes metadata attributes, such as, an identifier ("id"), a name, a media type, and a tag. Each attribute is assigned one or more values. For demonstration purposes, the identifier attribute property can serve as a unique identifier for the root node. For example, a conflict resolution system can use the value of the identifier attribute property to determine whether two digital assets correspond to each other.

[0061] Attribute array 206 may include any number of attribute properties in root node 204, including optional attribute properties. Examples of attribute properties include name, type, type version, creation date, modification date, tags, manifest format version, status, and units. In more detail, name provides a user-readable name for digital asset 200. Type includes a content type indicating that digital asset 200 is a composite of components and / or other composite parts. Type version indicates the current version of the type, as types may change over time. Created and modified attributes indicate the creation date and modification date of digital asset 200. Tags (i.e., tag #1) provide organization and identification of digital assets and / or components. In addition, manifest format version indicates the version number of the manifest itself (which may be different from the version number of the digital asset). Status indicates information stored by manifest 202 about its own current state and, by extension, the state of the embedded composite.

[0062] Component array 208 includes components included in digital asset 200. As shown, root node 204 includes component 1 208a and component 2 208b. Each component can be associated with an independent file (e.g., file 1 218a and file 2 218b). In detail, if digital asset 200 is an image, the components can correspond to layers within digital asset 200, wherein each layer is stored separately on a client device and / or a cloud-based server device. In practice, the components represent separate files that make up the digital asset, and their file locations are indicated within manifest 202.

[0063] As shown, each component may include a separate attribute array. Examples of attribute properties of a component include an identifier ("id"), a name, a path, a media type, and a relationship ("rel"). In more detail, a name is a user-readable descriptor of a component. In various embodiments, a path indicates a relative (unique) address of a component from a root node 204 of a digital asset 200. In some embodiments, a conflict resolution system utilizes a path when resolving links (e.g., URLs) that reference other components. A media type indicates the media type of a component. A relationship attribute indicates the relationship of a component to a manifest structure. Further, a component's attribute array may include additional attributes based on the component's media type. For example, additional attributes include timestamp, length, width, height, pixel density, and link.

[0064] As mentioned above, the root node 204 includes a child node array 210. The child node array 210 lists which child nodes (if any) constitute the digital asset 200. As shown, the list includes two child nodes (i.e., node 1 210a and node 2 210b). Each child node in the child node can include elements similar to the root node 204, such as, attribute characteristics, components, and other child nodes (e.g., grandchild nodes). In this way, each child node in the child node array 210 can provide the same function as a single component. In addition, the child node inherits many of the attribute characteristics of the root node 204. Further, unlike the root node 204, each child node in the child node includes a relationship attribute characteristic to indicate the relationship between the node and the root node 204 and / or its sibling nodes.

[0065] In additional embodiments, the root node 204 and / or child nodes may also include one or more elements. An element is a special node (e.g., an embedded compound) that may have a different media type than the node in which the element resides. For example, if a node of media type A includes an embedded element of media type B, the conflict resolution system may utilize different rules (in the same or different rule sets) when resolving conflicts within the element that are appropriate for the element's media type. In fact, when an element is encountered during conflict resolution, the conflict resolution system may automatically switch rule sets to utilize element-specific rules.

[0066] Although the following description describes conflicts primarily in terms of component conflicts, conflicts may occur between attributes and child nodes. The actions and methods described herein for the conflict resolution system 302 to resolve component conflicts may be applied to resolve attribute and / or child node conflicts. For example, the conflict resolution system 302 utilizes a rule set for resolving conflicts between attribute characteristics detected between two different versions of a root node. In another example, the conflict resolution system 302 detects and resolves conflicts between different elements within corresponding nodes of different versions of a digital asset (e.g., an element was modified in one version and deleted in another version).

[0067] Turning to the next set of figures, additional details are provided regarding the digital asset conflict resolution system detecting conflicts in various scenarios. In particular, FIG. 3A to FIG. 3C A schematic diagram and sequence diagram for detecting conflicts within a digital asset according to one or more embodiments are illustrated. In particular, Figure 3A The manner in which a conflict resolution system (ie, a digital asset conflict resolution system) can detect component conflicts caused by one or more computing devices (client devices and / or server devices) is illustrated. Figure 3B Additional details are provided regarding a conflict resolution system detecting local component conflicts caused by different sources (eg, applications) on a client device. Figure 3C Additional details are provided regarding a conflict resolution system detecting remote component conflicts caused by different devices (eg, between a client device and a server device).

[0068] As shown in the figure, Figure 3A The system includes a client device 300 and a server device 301. The client device 300 includes a digital asset conflict resolution system 302 (or simply referred to as "conflict resolution system 302"), a local application A 304a and a local application B 304b. The server device 301 includes a cloud storage device 306 for digital assets.

[0069] Generally, a component conflict occurs when the conflict resolution system 302 detects two independently modified versions of a composite part (eg, a component). FIG. 3A to FIG. 3CResolving conflicts between conflicting components is discussed for ease of explanation. It is to be understood that the conflict resolution system 302 can resolve conflicts between any composite parts (e.g., nodes, attributes, elements). Typically, when the conflict resolution system 302 detects a single modified version of a component, there is no conflict because the conflict resolution system 302 replaces the previous version with the modified version. However, in some instances, as described below, a single modified version may cause a conflict if the replaced component version is not the previous version on which the modified version is based.

[0070] For illustration, Figure 3A A local component conflict scenario is shown in which the conflict resolution system 302 can detect a component conflict (312) between two locally modified versions of a component (i.e., local component 1A 310a and local component 1B 310b). Local component conflicts typically occur when two applications access and modify the same component. For example, local application A 304a and local application B 304b provide different modified versions of component 1 to the conflict resolution system 302, which then detects a component conflict between the two locally modified versions. Figure 3B Additional details on local component conflict scenarios are provided.

[0071] Figure 3A Also shown is a remote component conflict scenario in which the conflict resolution system 302 can detect a component conflict between a local modified version and a remote modified version of a component (i.e., local component 1A 310a and remote component 1C 314). A remote component conflict typically occurs when two client devices modify the same component before each device can synchronize with the other device (via the central server device 301). For example, the client device 300 and another client device that has synchronized with the cloud storage 306 on the server device 301 each provide a different modified version of component 1 to the conflict resolution system 302. As a result, during synchronization, the conflict resolution system 302 detects a remote component conflict between the two modified versions. Figure 3C Additional details on remote component conflict scenarios are provided.

[0072] As mentioned above, Figure 3B The sequence diagram of the conflict resolution system 302 detecting local component conflicts is illustrated. As shown in the figure, Figure 3BA client device 300 is included having a conflict resolution system 302 and a local application A 304a and a local application B 304b. In particular, the conflict resolution system 302 provides a component (e.g., component 1) to the local application A 304a (330). For example, the local application A 304a requests component 1 when a user accesses a digital asset that includes component 1. In various embodiments, the conflict resolution system 302 provides a copy of the component to the local application A 304a and maintains the original version or copy.

[0073] As shown, local application A 304a modifies a component (332). For example, a user adds data to a component within local application A 304a. In practice, local application A 304a modifies component 1 to component 1A (eg, a first modified component version) based on user input.

[0074] Before the conflict resolution system 302 receives the first modified component version (e.g., component 1A) from local application A 304a (334), the conflict resolution system 302 provides the component to local application B 304b (336). In this way, local application A 304a and local application B 304b have both received the same version of the component (e.g., component 1).

[0075] As shown, local application B 304b modifies the component (338). For example, the user removes data within the component within local application B 304b. In effect, local application B 304b modifies component 1 to component 1B (e.g., a second modified component version) based on the user input. Then, conflict resolution system 302 receives the second modified component version (e.g., component 1B) from local application B 304b (340).

[0076] Conflict resolution system 302 detects a component conflict between two modified versions of a component (e.g., component 1A and component 1B) (342). In some embodiments, conflict resolution system 302 receives component 1A and component 1B simultaneously and determines that both modified versions are different from a currently maintained version of a component (e.g., component 1). For example, conflict resolution system 302 performs a checksum hash to quickly determine that component 1A and component 1B are different from component 1 and from each other.

[0077] In an alternative embodiment, conflict resolution system 302 has replaced component 1 with component 1A prior to receiving component 1B. However, before replacing component 1A with component 1B, conflict resolution system 302 recognizes that both component 1A and component 1B branch off from component 1. Therefore, conflict resolution system 302 detects that component 1B causes a component conflict with the currently updated component 1A (342).

[0078] When a component conflict is detected, conflict resolution system 302 resolves the conflict (344). For example, conflict resolution system 302 utilizes a format-specific rule set to resolve component conflicts. Figures 5 to 6B Provides additional details on conflict resolution.

[0079] As mentioned above, Figure 3C The sequence diagram of the conflict resolution system 302 detecting remote component conflicts is illustrated. As shown in the figure, Figure 3C The client device 300 includes a conflict resolution system 302 and a local application A 304a. In addition, Figure 3C The server device 301 includes a cloud storage device 306. For ease of explanation, Figure 3B and Figure 3C Repeated actions between share the same call number. For example, in Figure 3C Actions 330, 334, 342, and 344 are repeated.

[0080] As in Figure 3C , conflict resolution system 302 synchronizes a component (e.g., component 1) with server device 301 (350). For example, in one or more embodiments, client device 300 provides component 1 to server device 301 to add the component in cloud storage 306 or to update the component in cloud storage 306. In an alternative embodiment, server device 301 provides a copy of component 1 to client device 300 during the synchronization process. Component 1 may be provided in conjunction with other components belonging to the same digital asset.

[0081] As also shown, the conflict resolution system 302 provides a component (e.g., component 1) to the local application A 304a (330). Additionally, the local application A 304a modifies the component (332). As described above, component 1 becomes component 1A (e.g., a first modified component version) when modified by the local application A 304a. Further, as described above, the conflict resolution system 302 receives the first modified component version (e.g., component 1A) from the local application A 304a (334).

[0082] Before conflict resolution system 302 receives component 1A from local application A 304a or before conflict resolution system 302 can synchronize component 1A with server device 301, server device receives a second modified component version (e.g., component 1B) (352). For example, a second user on another client device synchronizes component 1B to cloud storage 306 on server device 301 while the first user locally modifies the component on client device 300 within local application A 304a.

[0083] As shown, conflict resolution system 302 receives a second modified component version (e.g., component 1B) (354), for example, during a synchronization update. At this point, conflict resolution system 302 detects a component conflict between two modified versions of a component (e.g., component 1A and component 1C) as previously described (342). Additionally, upon detecting a component conflict, conflict resolution system 302 resolves the conflict as explained above (344). Further, as shown, conflict resolution system 302 can synchronize the resolved component with server device 301 (356).

[0084] Although FIG. 3A to FIG. 3C The diagram illustrates a component conflict scenario detected by a conflict resolution system 302 located on a client device. However, when the conflict resolution system 302 is located on a server device 301, a similar component conflict scenario may be detected. In particular, when the conflict resolution system 302 is located on the server device 301, the conflict resolution system 302 detects component conflicts when synchronizing different modified versions of a component with multiple client devices. The conflict resolution system 302 may resolve the component conflicts and provide the resolved components to the corresponding client devices.

[0085] Steering Figure 4 , describes an example component conflict. To illustrate, Figure 4 Examples of different versions of the same digital asset that can result in several component conflicts are shown. In particular, Figure 4 Three versions or branches of a digital asset are shown—a base version 410 ("base"), a first modified version 420 ("version 1"), and a second modified version 430 ("version 2"). The first modified version 420 and the second modified version 430 of the component are both based on the base version 410 of the component (e.g., both version 1 and version 2 extend from the base).

[0086] Each version of the digital asset includes a list of nodes (e.g., a root node and child nodes) that make up the digital asset. Further, each node includes attributes, components, and child nodes as described above. For example, the base version 410 includes a root node with an attribute array 412, a component array 414, and a child node array 416. The first modified version 420 includes a root node with an attribute array 422, a component array 424, and a child node array 426. The second modified version 430 includes a root node with an attribute array 432, a component array 434, and a child node array 436. The above combined Figure 2 Provides descriptions of attributes, components, and child nodes.

[0087] As shown, the first modified version 420 and the second modified version 430 of the digital asset are different from each other and from the base version 410 of the digital asset at the structural level. For illustration, the base version 410 includes two components and one child node. The first modified version 420 removes the components from the base version 410 and adds two child nodes. The second modified version 420 maintains the same number of components from the base version 410 and adds child nodes.

[0088] In addition, the first modified version 420 and the second modified version 430 are different from each other and from the base version 410 of the digital asset at the composite part level. For example, the second modified version 420 adds a tag ("Tag #1") to the attribute array 432 in the root node of version 2. Further, the nodes and components themselves can be different between versions of the digital asset. For example, the added child node 2 of the first modified version 420 can be different from the added child node 2 of the second modified version 430 of the digital asset.

[0089] Based on the differences between the base version 410 and the modified version, the conflict resolution system 302 detects multiple component conflicts. For illustration, Figure 5 FIG. 3 is a flow chart for resolving detected conflicts within a composite-part-based digital asset according to one or more embodiments. In many embodiments, the conflict resolution system 302 implements a combination of Figure 5 Describes the action. Figure 4 The digital asset is described in Figure 5 The conflict resolution process shown in .

[0090] As shown, conflict resolution system 302 detects conflicts between multiple versions of a digital asset (502). For example, conflict resolution system 302 determines differences in modification dates, version numbers, sizes, and / or other attribute characteristics between base version 410, first modified version 420, and second modified version 430 of the digital asset. In addition, conflict resolution system 302 may detect different numbers of components or child nodes between the three versions. In general, as described above for Figure 3A As described, the conflict resolution system 302 detects digital asset conflicts when synchronizing modified versions of digital assets.

[0091] After detecting a conflict, the conflict resolution system 302 examines each element and component in the version of the digital asset to identify the origin of the conflict. For example, in various embodiments, the conflict resolution system 302 examines the types between each of the digital asset versions in the digital asset version at the root node of each of the digital asset versions (504). In particular, the conflict resolution system 302 performs a three-way differential (or simply "3-way diff") on the types (e.g., media types and / or file types) against the corresponding attribute arrays to determine if there are any root node media type conflicts.

[0092] In the rare case that the types of the three branches are not the same, conflict resolution fails. In fact, if the user changes the type (e.g., file format) of the root node in one of the modified versions (e.g., changes the digital asset from a photo application file to a document application file), the conflict resolution system 302 cannot resolve any further conflicts between the versions of the digital asset. Instead, the conflict resolution system 302 separates the modified versions of the digital asset with different types into new files and replaces the base version 410 with the remaining modified versions that share the same type as the base version 410.

[0093] The conflict resolution system 302 may also verify that other root node attributes match between versions of the digital asset. For example, the conflict resolution system 302 verifies that the identifier attribute matches between the base version 410, the first modified version 420, and the second modified version 430. Similarly, the conflict resolution system 302 may also verify that the name matches between versions.

[0094] When a type and / or other attribute property match between different digital asset versions is determined, the conflict resolution system 302 traverses the version hierarchy to detect any composite part conflicts (506). For example, the conflict resolution system 302 starts with a root node. For each node, the conflict resolution system 302 compares attribute property values ​​with attribute property values, components with components, and recursively, child nodes with child nodes. Similarly, when present, the conflict resolution system 302 can also compare elements with elements within corresponding nodes in different versions of the digital asset.

[0095] In various embodiments, when comparing the attributes of the nodes, the conflict resolution system 302 can match the names of the attribute properties. In one or more embodiments, the conflict resolution system 302 creates a list of all attribute property names of the version 1 node and the version 2 node, and then iterates through the list of attribute property names and finds the different attribute properties in the three branches (i.e., versions).

[0096] When comparing the components of a node, the conflict resolution system 302 can match the components by the paths of the components. In this way, the conflict resolution system 302 can handle the situation where the same component is created using different identifiers in different versions of the digital asset. Further, when comparing child nodes, the conflict resolution system 302 can match the nodes in different versions by the identifiers of the nodes in different versions. Accordingly, the conflict resolution system 302 can detect and handle the position movement of child nodes. It is worth noting that when a modified version of a digital asset has moved a child node to a different parent node, the conflict resolution system 302 regards the movement as removing the node from one parent node and adding the new node to the other parent node.

[0097] For each traversed component, the conflict resolution system 302 performs a comparison (such as a 3-way difference) to determine whether there is a conflict between the base version 410, the first modified version 420, and the second modified version 430. As described above, when the components do not match, the conflict resolution system 302 detects a component conflict (508). For example, when traversing the component array of the root node, the conflict resolution system 302 detects a conflict with component 2 between the base version 410, the first modified version 420, and the second modified version 430 (i.e., the first modified version 420 has removed component 2, while the second modified version 430 has maintained / modified component 2).

[0098] When a component conflict is detected, the conflict resolution system 302 identifies and loads a rule from the rule set for the media type of the conflicting component (510). FIG. 6A to FIG. 6B As described, in many embodiments, a rule set is specific to a media type or group of media types (e.g., document / *+dcx). Thus, when a component conflict is detected, the conflict resolution system 302 identifies one or more rule sets corresponding to the media type (e.g., file format) of the conflicting component (i.e., a format-specific rule set).

[0099] In some embodiments, the conflict resolution system 302 initially identifies and loads a rule in the rule set that matches the media type identified in the root node. If the conflicting components share the same media type, the conflict resolution system 302 has pre-loaded rules to apply when needed. Alternatively, the conflict resolution system 302 identifies and loads a different rule (from another rule set) in the rule set that corresponds to the media type of the component with the detected conflict. Similarly, if the conflict resolution system 302 detects a conflict for an element (e.g., an embedded element) within a node or component that has a different media type than the currently loaded media type, the conflict resolution system 302 can update the loaded rules to match the media types of the conflicting elements.

[0100] Typically, the conflict resolution system 302 loads multiple rule sets. If the conflict resolution system 302 identifies multiple rule sets (512), the conflict resolution system 302 determines the rule set priority or continues to operate with a single identified rule set (514). At least one rule set contains default rules for all media types, so the conflict resolution system 302 will always identify at least one conflict resolution rule set.

[0101] As mentioned above, when multiple rule sets are identified (512), the conflict resolution system 302 determines a priority order for the multiple rule sets (514). Although the conflict resolution system 302 loads and applies all identified rule sets, the conflict resolution system 302 may favor one rule set over another. For example, the conflict resolution system 302 prioritizes more specific rule sets over more general sets. For example, a rule set for the exact media type of the conflicting component is more specific than a rule set corresponding to multiple media types. If there is a rule set overlap or conflict between two rule sets, the conflict resolution system 302 utilizes the rule set with a higher priority and / or greater specificity.

[0102] In some embodiments, the conflict resolution system 302 bypasses, skips, and / or ignores the lower priority rule set. For example, the conflict resolution system 302 applies the higher priority rule set first. If all conflicts in the conflict are resolved, then when the conflict resolution system 302 applies the lower priority rule set, no rules are triggered because there are no conflicts. Alternatively, when there are no conflicts, the conflict resolution system 302 can bypass the lower priority rule set. However, if conflicts still exist after applying the higher priority rule set, the conflict resolution system 302 can apply the rules in the lower priority rule set to resolve the conflicts.

[0103] When one or more rule sets are selected, the conflict resolution system 302 utilizes the identified rule sets to resolve the conflict of components (516). More specifically, the conflict resolution system 302 utilizes one or more rules in the rule set to identify conditions and resolution actions for the conflict. FIG. 6A to FIG. 6B Additional details are provided regarding utilizing rules to resolve component conflicts.

[0104] When the rule set is applied, the conflict resolution system 302 determines whether the conflict is resolved (518). For example, the conflict resolution system 302 determines whether one rule in the rule set is applied appropriately. For example, when updating a component in the base version 410 to a resolved version of the component, the conflict resolution system 302 determines that the component conflict is resolved. In another example, the conflict resolution system 302 again compares the component between the three versions to determine whether executing the rule in the identified rule set has resolved the conflicting component.

[0105] If the conflicting components are resolved, the conflict resolution system 302 updates the digital asset with the resolved components. Additionally, the conflict resolution system 302 determines whether there are additional components (or other composite parts) (524). If so, the conflict resolution system 302 traverses the version hierarchy to detect any additional conflicts (506). Further, if a conflict is detected, the conflict resolution system 302 repeats the previous actions 508 to 518. Alternatively, the conflict resolution system 302 synchronizes the updated digital assets between the corresponding client devices (and / or server devices) (526).

[0106] However, as in Figure 5 , if the conflict is not resolved, the conflict resolution system 302 propagates the conflict up the version hierarchy (520). For example, in one or more embodiments, the conflict resolution system 302 moves up the tree structure hierarchy back to the parent node in searching for a set of rules that dictate a way to resolve the conflict. In this manner, the conflict resolution system 302 uses common programming language terminology to "throw" and "catch" component conflicts. Thus, the conflict resolution system 302 can largely avoid the need for immediate user intervention and find alternative ways to resolve component conflicts when one or more previous attempts have failed.

[0107] As shown, the conflict resolution system 302 resolves component conflicts at a higher level in the version hierarchy (522). In many embodiments, the conflict resolution system 302 resolves propagated component conflicts by forking the components or nodes with conflicts. However, in some embodiments, the conflict resolution system 302 identifies a rule or set of rules that provides a more seamless solution. However, rarely, if a matching rule cannot be found, the conflict resolution system 302 may cause different versions of the digital asset to be split into multiple digital assets even after propagation to the root node.

[0108] When component conflicts are resolved at a higher level in the version hierarchy, the conflict resolution system 302 updates the digital asset with the resolved components. Additionally, the conflict resolution system 302 determines whether there are additional components (or composite parts) (524). If so, the conflict resolution system 302 traverses the version hierarchy (506) to detect any additional conflicts and, if conflicts are detected, repeats the previous actions 508 to 524. Alternatively, the conflict resolution system 302 synchronizes the updated digital asset among the corresponding client devices (and / or server devices) by synchronizing any resolved components (526).

[0109] Additionally, as part of resolving component conflicts, at the component level or at a higher level, conflict resolution system 302 can annotate, mark, signal, or otherwise indicate the resolved conflict to a user. For example, in various embodiments, conflict resolution system 302 provides a graphical user interface notification to the next one or more users who access the digital asset indicating the resolution performed by conflict resolution system 302. In some embodiments, conflict resolution system 302 enables the user to select an option to undo the resolution and / or perform a different resolution.

[0110] In some embodiments, the conflict resolution system 302 resolves component conflicts in a manner that is apparent to the user when the user next accesses the digital asset. Figure 1 Given an example where the base version of a component has a blue background, the first modified version has a yellow background, and the second modified version has a green background, the conflict resolution system 302 resolves the component conflict by replacing the single blue base version with two components—the first component with a yellow background and the second component with a green background. In this manner, when a user next accesses the digital asset, they will easily notice the yellow background version and the green background version and decide whether they should keep one version instead of the other.

[0111] Additionally, in various embodiments, the conflict resolution system 302 adds flags, labels, and / or other indicators to components and / or nodes to indicate a resolution and whether additional action is required. For example, the conflict resolution system 302 adds new attribute properties to the attribute array of a component or parent node that specify the type of conflict, how to resolve the conflict, and / or whether additional action is required by the conflict resolution system 302 or a user. Examples of special attributes added include "conflict-restored=true", "conflict-invalidated: true", and "conflict-forked: true".<original id> ”.

[0112] Figure 5 Various embodiments are described for resolving composite part conflicts (e.g., conflicts between attributes, components, and child nodes) within a digital asset. Figure 5 The described actions and algorithms provide example structures and actions for performing steps for resolving conflicts at the component level (or composite part level) of a digital asset based on one or more format-specific rule sets without duplicating the digital asset. Figure 5 One or more actions 502 through 526 shown in FIG. 5 may provide a structure / action for implementing resolved components when component conflicts are detected between multiple versions of the same component of a digital asset.

[0113] In addition, Figure 5 The description of the previous figures describes maintaining a digital asset including a first component and a second component (wherein the first component and the second component are stored as separate files) and identifying a first modified version of the first component and identifying a second modified version of the first component. Figure 5 The description of the previous figures describes determining a conflict between a first modified version of a first component and a second modified version of the first component. Further, Figure 5 and previous figures describe providing resolved digital assets to a client device.

[0114] Now turn to FIG. 6A to FIG. 6B , provides additional details about the application of format-specific rules. For example, FIG. 6A to FIG. 6B Example format-specific rules are illustrated. As described above, rules are included in rule sets corresponding to specific media types or groups of media types. Therefore, the conflict resolution system 302 first determines one or more rule sets that apply to components (or nodes), and then applies the rules in the rule sets to the conflicting components. For context, Fig. 6A First, an example composition of format-specific rules is provided. Then, Figure 6B Examples of rules in a rule set are provided, including attribute rules, component rules, and child node rules. Figure 6B The description of provides an example rule set.

[0115] Fig. 6A Format-specific rules 600 (or simply "rules 600") are included. As shown, rule 600 includes three clauses—rule type clause 602, condition clause 604, and action clause 606. In general, rule type clause 602 specifies whether the rule applies to attributes of a node, component, or child node (e.g., a property in an attribute array). Figure 6B Examples of three rule types are shown in .

[0116] In some embodiments, the rule type includes additional information (e.g., an expression) that further specifies where within a component the rule applies. For example, for a component rule, the rule type clause "component (application / rdf+xml)" specifies that the rule applies to components that include a specific media type (e.g., XML). As another example, the rule type clause 602 "attribute (timestamp)" specifies that the attribute specified in the conditional clause should be interpreted as a string containing a timestamp.

[0117] The conditional clause 604 (e.g., a selector clause) indicates the circumstances under which the rule 600 should be applied (e.g., a portion or composite portion of a component to which the rule is directed). For example, in various embodiments, the conditional clause 604 specifies the portion of the component to be compared (or attributes / subnodes, depending on the rule type) and the nature of the difference between two independently modified portions. Accordingly, the conditional clause 604 includes a path (e.g., ":", " / :", " / *:", and " / **:") and a selector (e.g., "created", "modified", or "removed"). In practice, the rule type clause 602 and the conditional clause 604 together direct the conflict resolution system 302 as to the portions of the rule 600 to be applied with respect to a digital asset and under what circumstances the rule 600 should be applied.

[0118] In addition, different rule types for attributes, components, and child nodes can each have different conditional clauses specific to the rule type. For illustration, example conditional clauses for attribute rule types include ":*", ":width", " / :width", " / stack / *:width", and " / stack / children[0]:width". Example conditional clauses for component rule types include " / :*", " / **", " / :components[rel='rendition']", and " / stack / children[0]:components[type='image / png']".

[0119] As in Figure 6B As shown in , conditional clause 604 is " / :components[rel='rendition']". The conditional clause 604 directs the conflict resolution system 302 to identify a root-level component having a "rel" (i.e., relationship) attribute value set to "render", which indicates that the component has been rendered with other components (e.g., the component has been flattened with the other components to form a single image for viewing). The conditional clause " / :*" refers to any attribute in the root node, and " / **" refers to any node or component in the manifest of the digital asset. As another example, " / stack / children[0]:components[type="image / png"]" refers to all PNG components on the first child node of the node with path " / stack".

[0120] In various embodiments, the action clause 606 specifies the manner in which the conflict resolution system 302 processes the rule when a condition in a digital asset or component is triggered. In practice, the conflict resolution system 302 executes the instructions in the action clause 606 to resolve a conflict between two independently modified components or other conflicting composite parts in a digital asset. As with the condition clause 604, the types of actions allowed in the action clause 606 generally depend on the rule type clause 602. Although the action clauses 606 described herein relate to conflict resolution action clauses (e.g., action clauses 606 beginning with "resolve"), the conflict resolution system 302 may utilize other types of action clauses.

[0121] As shown, action clause 606 includes trigger 608 and solution 610. In some embodiments, trigger 608 includes a descriptor of how two independently modified portions (e.g., components) of a digital asset differ. Examples of trigger 608 include: resolve conflict, modified solution, new solution, deleted solution, different solution, resolve conflict, resolve version 1 changes, and resolve version 2 changes.

[0122] In various embodiments, trigger 608 indicates various types of differences between two independently modified portions of a digital asset. For example, trigger 608 may account for unmodified, modified, new, or removed changes between two portions. Examples of conflicting trigger scenarios include (version 1 listed before version 2): modified-unmodified, deleted-unmodified, unmodified-modified, modified-modified, deleted-modified, new-new, deleted-new, unmodified-deleted, modified-deleted, and new-deleted. In additional embodiments, the type of trigger 608 may vary based on a combination of differences between two independently modified portions of a digital asset.

[0123] The solution 610 indicates the manner in which the conflict resolution system 302 can resolve the particular conflict specified by the trigger 608. The action clause 606 can include multiple solutions. Example solutions for components include forking, invalidating, or merging (e.g., for XML metadata components). Example solutions for attributes include propagating, removing, retaining version 1, retaining version 2, restoring, making smaller, making larger, and merging (e.g., setting attributes and dictionary attributes). In one or more embodiments, child node rules follow the same structure and parameters as component nodes for triggers and solutions.

[0124] As shown, the action clause 606 of rule 600 is "resolve the conflict by invalidating..." In this case, the conflict resolution system 302 retains the conflicting component (e.g., version 2) and marks it with a special attribute indicating that the version is invalid (e.g., "conflict#invalid = true"). For example, a good candidate for invalidation is when the root level rendition contains renditions of multiple components. In this way, the application that next accesses the digital asset detects the conflict#invalid flag and updates the component (or node) (e.g., performs a new rendition). As an alternative to the invalidation resolution, the conflict resolution system 302 can remove the conflicting version (e.g., version 2). In some instances, removing version 2 signals the application that next accesses the digital asset to expect data loss and to restore the data when it is next opened.

[0125] In addition to the invalidation solutions mentioned above, other example solutions include select one, calculate, and propagate. With select one, rule 600 directs conflict resolution system 302 to select one version over another. In one or more embodiments, conflict resolution system 302 can accept changes from a modified version as long as the difference descriptor contains unmodified or deleted keywords (i.e., in one of the versions, the data in question is not affected).

[0126] However, for some kinds of conflicts, it is more preferable to have one of the versions overwrite the other, even if the data has been modified in both branches. For example, version 1 has indicated that a component is marked as visible, but version 2 has not. In this case, it is more preferable to discard the change without having to fork the component or node. In another example, a shared resource of a component (or node) is deleted in one version, but not in the other version. Here, the conflict resolution system 302 does not know whether the resource is still used in the resulting resolved branch. Therefore, the conflict resolution system 302 applies the rule for restoring resources from the version in which the resource was not deleted. Moreover, in this case, the conflict resolution system 302 marks the restored component (or node) with a special attribute (e.g., "conflict#restored=true") to signal a solution.

[0127] With respect to the computational solution mentioned above, if the data in question is modified or created in both versions (e.g., modified-modified or new-new), the ideal solution is to merge the two versions. However, this solution is only possible for a limited number of data types (such as attribute sets, attribute dictionaries, and component XMP metadata). For some attribute types, the conflict resolution system 302 can compare different values ​​and resolve conflicts by taking the smaller or larger value. For example, the conflict resolution system 302 implements this solution for integer, number, and timestamp attributes.

[0128] With respect to the propagation solution mentioned above, as a last resort, the conflict resolution system 302 employs a "throw and catch" type of resolution. As described above, propagating conflicts passes (e.g., "throws") conflicts up the hierarchy of digital assets to a higher level rule set that detects conflicts (e.g., "catches"). Typically, the conflict resolution system 302 resolves propagated conflicts by bifurcating components (or nodes) (such as artboards, layers, or pages in a digital asset). These kinds of components (or nodes) represent natural bifurcation points in the composite format of a digital asset.

[0129] In practice, similar to the throw / catch mechanism found in many programming languages, the conflict resolution system 302 creates a first rule in the rule set that propagates (e.g., "throws") conflicts that cannot be resolved at lower levels of the digital asset hierarchy and a second rule that detects (e.g., "catches") propagated conflicts at higher-level nodes. For example, the first rule might state "if a PNG image component that is a child of a canvas node has been modified in two versions, propagate the conflict," and the second rule might state "if a conflict is propagated anywhere within a canvas node, fork the node." In this example, the conflict resolution system 302 specifies which parts of the digital asset can be forked, and therefore, avoids forking or duplicating the entire digital asset.

[0130] In various embodiments, when a component (or node) is forked, the conflict resolution system 302 applies a special attribute (e.g., "conflict#forked={id}") to the propagated component or node to signal the propagation to the application that next accesses the digital asset. For example, in response to detecting the special attribute, the application regenerates any invalid renditions. Further, after detecting the special attribute, the application can indicate the forked components to the user. In practice, the user can discover these forked composite parts and decide whether to keep one or both of them.

[0131] As described above, the rules in the rule set enable the conflict resolution system 302 to apply semantic solutions. More specifically, the conflict resolution system 302 can utilize rules to write new data into the digital asset to achieve conflict resolution and ensure that the digital asset retains a valid resolvable file. In one or more instances, as previously explained, the conflict resolution system 302 resolves semantic conflicts by incorporating special attribute characteristics into nodes and components. In certain embodiments, the conflict resolution system 302 adds or changes the data of a node or component based on the action clause 606 of the rule when applying a conflict resolution method. In general, as described above, the rule provides context (e.g., semantics) information about a given node or component corresponding to the relevant rule, and the context (e.g., semantics) information enables the conflict resolution system 302 to know where and how to add additional data to resolve the conflict and make the digital asset a legal digital asset. In this way, the conflict resolution system 302 can resolve conflicts without requiring immediate user action and without requiring the entire digital asset to be copied.

[0132] If the conflict resolution system 302 cannot find a higher-level node that can handle the propagated conflict, the conflict resolution system 302 cannot implement a solution, accepts the modification in version 1, and copies version 2 as a forked digital asset (or vice versa). Accordingly, the forked digital asset is a derivative of the original digital asset (e.g., updated to version 1) that has special metadata (e.g., recorded in XML) that identifies it as a forked digital asset of version 1. In this way, applications will be able to detect forked digital assets and allow users to decide whether to proceed with the modified version and the forked version.

[0133] By executing the rules in the rule sets, the conflict resolution system 302 can identify and resolve most conflicts between different concurrent versions of digital assets. As previously mentioned, when the conflict resolution system 302 detects multiple rule sets, the conflict resolution system 302 prioritizes more specific rule sets over less specific rule sets. For example, the conflict resolution system 302 includes a default rule set that applies to all digital assets. Therefore, if the conflict resolution system 302 identifies the default rule set and another rule set corresponding to a given media type, the conflict resolution system 302 will apply the other rule set before applying the default rule set.

[0134] As mentioned earlier, Figure 6B Examples of rules in a rule set are shown. In particular, Figure 6B Included are attribute rules 612, component rules 614, and subnode rules 616. Listing 1 below includes a rule set that includes attribute rules 612, component rules 614, and subnode rules 616 in the context of the rule set.

[0135]

[0136]

[0137] List 1

[0138] As shown in Listing 1, a rule set includes a header and rules. The header includes a rule-format version, a media type, and a rule set name. In various embodiments, the rule-format-version is used to ensure that the rule set can evolve into different formats. Accordingly, the conflict resolution system 302 can reject any rule set with a rule-format-version that is greater than what is programmed for processing.

[0139] As mentioned above, the media type specifies the digital asset format or format group of the application rule set. In some embodiments, a given media type must end with +dcx. As explained earlier, when the rule is applied to a digital asset (or an element in a digital asset), the conflict resolution system 302 first collects all rule sets that are applied to a given media type. For example, for a component with the media type documents / vnd.application.cls+dcx, the conflict resolution system 302 can find the following three rule sets that support the following media types: 1) documents / vnd.application.cls+dcx, 2) documents / *+dcx and 3) * / *+dcx. The third example media type corresponds to a default rule set that is applicable to all media types (e.g., all digital assets based on composite parts).

[0140] Also, as described above, a compound may be embedded in other compounds of different media types as an element. In these instances, when processing an element (e.g., an embedded compound) having different media types as an embedded element, the conflict resolution system 302 may identify the element and switch to the appropriate class set of the rule set when processing the element.

[0141] As previously explained, the name of the rule set is for informational purposes only. The conflict resolution system 302 can utilize the rule set name in the log to identify which rule sets have been utilized. In many embodiments, the rule set name should be a human-readable string that identifies the rule set and the specific version of the rule set.

[0142] Now turn to Figure 7 , provides additional details about an example architecture of a digital asset conflict resolution system ("conflict resolution system 302"). In particular, Figure 7An example schematic diagram of a conflict resolution system 302 according to one or more embodiments is illustrated. As shown, the conflict resolution system 302 resides on a computing device 700 (such as a client device or a server device). Fig.11 Additional details regarding computing device 700 are provided.

[0143] As shown in the illustrated embodiment, the conflict resolution system 302 is part of a digital asset synchronization system 702 (or simply "synchronization system 702"). In alternative embodiments, the conflict resolution system 302 is located on the client device 300 independently of the synchronization system 702. For example, the conflict resolution system 302 and the synchronization system 702 are located on separate computing devices that communicate with each other.

[0144] In general, the synchronization system 702 facilitates the management, storage, access, and synchronization of digital assets, particularly composite-part-based digital assets. For example, the synchronization system 702 provides increased flexibility and improved computing functionality by enabling multiple users, applications, and / or devices to simultaneously access and edit the same digital asset, regardless of its type (e.g., images, documents, presentations, videos, animations, and infographics). When the synchronization system 702 detects a change to a composite part of a digital asset, the synchronization system 702 automatically propagates the change to other users, applications, and / or devices that are simultaneously accessing the digital asset.

[0145] Additionally, the synchronization system 702 exploits the efficiencies gained by synchronizing only modified composite parts of a digital asset rather than synchronizing the entire digital asset. In effect, the synchronization system 702 provides bandwidth-efficient synchronization between devices such that only a portion of a digital asset is transmitted when a modification occurs. Further, the synchronization system 702 enables many versions of a digital asset to be maintained (locally and remotely) with little additional storage cost by maintaining multiple manifests (e.g., mappings) linked to different arrangements of composite parts (including different versions of the composite parts).

[0146] In some embodiments, the synchronization system 702 operates on a client device and a server device that communicate with each other, for example, to facilitate synchronization of digital assets between the devices. Figure 8 An example environment is provided in which a local digital asset synchronization system operates on a client device and a remote digital asset synchronization system operates on a server device.

[0147] Back to Figure 7, conflict resolution system 302 includes digital asset manager 704, digital asset synchronizer 714, rule set 716, and digital asset database 718. Digital asset manager 704 includes resolution manager 706 having conflict detector 708, rule executor 710, and resolution validator 712. Digital asset database 718 includes digital assets 720 having manifest 722 and composite part 724.

[0148] The digital asset manager 704 generally facilitates identifying, accessing, and modifying digital assets, including composite parts of digital assets. As part of this process, the digital asset manager 704 identifies the composite parts of the digital asset (e.g., within a digital asset manifest). For example, when a user creates a new digital asset in an application, the digital asset manager 704 creates a composite part manifest (e.g., a mapping) that links each composite part stored as a separate, independent file to the digital asset.

[0149] As mentioned above, the digital asset manager 704 includes a resolution manager 706. In one or more embodiments, the resolution manager 706 detects and resolves conflicts between digital assets. In a simple scenario, when a user modifies a digital asset, the resolution manager 706 detects the change and updates the digital asset. In more complex scenarios, the resolution manager 706 detects and resolves digital asset conflicts and / or composite part conflicts between multiple modified versions of the same digital asset and / or composite part.

[0150] As shown, the resolution manager 706 includes a conflict detector 708, a rule executor 710, and a resolution validator 712. The conflict detector 708 generally detects when a conflict occurs between two modified versions of a digital asset. In particular, as described above in conjunction with FIG. 3A to FIG. 3C As described, conflict detector 708 determines when two versions (or branches) of a digital asset differ from a common base version. Figure 5 As described, conflict detector 708 also determines which composite parts (eg, attributes, elements, components, and / or child nodes) of different digital asset versions conflict.

[0151] Further, the resolution manager 706 includes a rule executor 710. In various embodiments, the rule executor 710 identifies rules that apply to the conflicting components, attribute properties, or child nodes. For example, the rule executor 710 identifies one or more rule sets using the rule type and / or media type of the conflicting composite part. For example, the rule executor 710 stores the loaded rules for the media type in a memory during the conflict resolution process. FIG. 6A to FIG. 6B Provides examples of rule sets.

[0152] In various embodiments, the rule executor 710 also executes the rules in the identified rule set for the conflicting composite parts. For example, the rule executor 710 resolves the composite part conflict by applying the resolution action according to the rules in the rule set to the part of the composite part that triggers the rule. Figure 5 Further described is resolving digital asset conflicts based on executing rules.

[0153] In addition, the resolution manager 706 includes a resolution validator 712. In some embodiments, the rule executor 710 fails to fully resolve a composite-part conflict (e.g., a component conflict) at the composite-part level. For example, the rule executor 710 propagates the conflict to a higher level within the digital asset manifest. When this occurs, the resolution validator 712 detects that the conflict has not been resolved and invokes the rule executor 710 again to handle the propagated conflict at the higher level. In this manner, the resolution validator 712 ensures that the conflict is resolved without immediate user action. Moreover, the resolution validator 712 ensures that the conflict is resolved in a manner that results in a valid executable file (e.g., the resolved digital assets conform to the grammatical rules of the corresponding software application). In conjunction with the above Figures 5 to 6B These and other actions of the resolution validator 712 are provided.

[0154] As in Figure 7 , the conflict resolution system 302 also includes a digital asset synchronizer 714. Generally, the digital asset synchronizer 714 enables multiple users, applications, and / or devices to access digital assets simultaneously. In addition, the digital asset synchronizer 714 facilitates synchronization of digital assets between multiple devices, such as between multiple client devices and / or between a client device and a server device.

[0155] To demonstrate, in one or more embodiments, the digital asset synchronizer 714 detects when a composite portion of a digital asset is accessed from multiple locations. For example, the digital asset synchronizer 714 communicates with the digital asset database 718 to detect when one or more applications (or users or devices) are viewing and / or modifying the composite portion of a digital asset. For example, the digital asset synchronizer 714 identifies a system call indicating that an application is requesting access to the digital asset database 718. Likewise, the digital asset synchronizer 714 determines when an application has finished accessing the composite portion of a digital asset.

[0156] As mentioned above, the digital asset synchronizer 714 can detect when a modification occurs within a digital asset that is accessed simultaneously by multiple applications (or users or devices). For example, the digital asset synchronizer 714 identifies when the digital asset manager updates the digital asset mapping (i.e., inventory) for the digital assets being accessed simultaneously. In some embodiments, after detecting a change made by a first application, the digital asset synchronizer 714 sends an indication (e.g., a direct message or a multicast message) to the other applications to indicate that the mapping has been modified with the modified composite portion. Alternatively, the digital asset synchronizer 714 indicates to the other applications that a change has occurred to the digital asset mapping for the digital asset, based on which the other applications can interface with the digital asset database 718 to locate the change and apply the change or have the digital asset conflict resolved by the resolution manager 706.

[0157] In addition, the digital asset synchronizer 714 performs synchronization between multiple client devices and / or between a client device and a server device. In several embodiments, digital assets are synchronized across multiple devices. The digital asset synchronizer 714 detects composite part modifications (as described above) and sends (i.e., pushes) the modified version map and corresponding missing files to other devices. In addition, the digital asset synchronizer 714 can request (i.e., pull) version maps and missing files from other devices.

[0158] As shown, the conflict resolution system 302 includes a rule set 716. In one or more embodiments, the rule set 716 is stored in one or more files (e.g., text files) along with the composite parts of the digital assets. For example, when performing conflict resolution between digital assets or parts thereof, the conflict resolution system 302 loads one or more rule sets 716. Figure 6B An example of a rule set is provided in Listing 1 of the description.

[0159] As in Figure 7 , the conflict resolution system 302 includes a digital asset database 718. In some embodiments, the digital asset database 718 is located separately from the conflict resolution system 302, such as on a separate computing device. As shown, the digital asset database 718 includes a digital asset 720 having a manifest 722 and a composite part 724. The manifest 722 may include a list of composite parts that make up the digital asset. For example, each manifest 722 includes attributes, components, and child nodes. Figure 2 An example of a manifest is provided in . Composite part 724 may include a corresponding file storing the contents of the composite part. Alternatively, composite part 724 indicates the file location of the corresponding file, which is stored in a separate location, such as, stored in another storage medium of the computing device hosting the conflict resolution system 302.

[0160] Elements 704 to 724 of the conflict resolution system 302 may include software, hardware, or both. For example, elements 704 to 724 may include one or more instructions stored on a computer-readable storage medium and executable by a processor of one or more computing devices (such as a client device or a server device). When executed by one or more processors, the computer executable instructions of the conflict resolution system 302 may enable (multiple) computing devices to perform the feature learning method described herein. Alternatively, elements 704 to 724 may include hardware, such as a dedicated processing device to perform a specific function or group of functions. Alternatively, elements 704 to 724 of the conflict resolution system 302 may include a combination of computer executable instructions and hardware.

[0161] In addition, for example, elements 704 to 724 of conflict resolution system 302 can be implemented as one or more operating systems, one or more independent applications, one or more modules of applications, one or more plug-ins, one or more library functions and / or cloud computing models that can be called by other applications. Therefore, elements 704 to 724 can be implemented as independent applications, such as desktop or mobile applications. In addition, elements 704 to 724 can be implemented as one or more network-based applications hosted on a remote server. Elements 704 to 724 can also be implemented in a series of mobile device applications or "app". For illustration, elements 704 to 724 can be implemented in one or more applications, including but not limited to: ADOBE CREATIVE CLOUD software. "ADOBE" and "CREATIVE CLOUD" are registered trademarks or trademarks of Adobe in the United States and / or other countries.

[0162] As mentioned above, the digital asset synchronization system 702 (hosted conflict resolution system 302) can reside on the client device, the server device, or both. For illustration, Figure 8 An environment 800 is shown that includes a client device 802 and a server device 804 that each hosts a version of a digital asset synchronization system. As shown, the client device 802 includes a digital asset synchronization system 702a with a digital asset conflict resolution system 302a, and the server device 804 includes a remote digital asset synchronization system 702b and a remote digital asset conflict resolution system 302b. The digital asset synchronization system 702a and the remote digital asset synchronization system 702b embody the above combined Figure 7 Similarly, the digital asset conflict resolution system 302a and the remote digital asset conflict resolution system 302b both embody the above combined Figure 7 A conflict resolution system 302 is described.

[0163] As shown in further detail, the client device 802 includes a digital asset application 806 (or simply "application 806") and a digital asset database 718a (within the digital asset conflict resolution system 302a and the digital asset synchronization system 702a) storing digital assets 720a. The server device 804 includes a remote digital asset conflict resolution system 302b within the remote digital asset synchronization system 702b, which stores user information 820 and remote digital assets 720b corresponding to digital assets 720a on the client device 802.

[0164] As further illustrated, client device 802 communicates with server device 804 via network 822. Fig.11 A sample network is provided. Figure 8 A particular arrangement of devices and elements is illustrated, but various additional arrangements are possible.For example, environment 800 may include any number of client devices.

[0165] The client device 802 may represent various types of client devices. For example, in some embodiments, the client device 802 may be a mobile device such as a mobile phone, a smart phone, a PDA, a tablet computer, a laptop computer, a wearable device, etc. Fig.11 Additional details are discussed with respect to client devices.

[0166] In various embodiments, one or more users interact with client device 802 to access digital assets directly on client device 802 (e.g., digital assets 720a) or remotely on server device 804 via network 822 (e.g., remote digital assets 720b). As used herein, a user can be an individual (i.e., a human user), a group of people, a business, or another entity. For example, colleagues using multiple client devices share a set of digital assets. In this example, each colleague's client device maintains an up-to-date copy of the shared digital assets, which is synchronized via server device 804. Further, as described above, two colleagues modifying the same composite part within a digital asset at approximately the same time can produce a composite part conflict.

[0167] As in Figure 8As shown in and as mentioned above, the client device 802 includes an application 806. The application 806 can communicate with the digital asset synchronization system 702a and the digital asset conflict resolution system 302a to access one or more digital assets 720a in the digital asset database 718a. Generally, the application enables a user to create, view, copy, modify and / or delete digital assets or portions thereof. In many cases, the application relates to a specific type of digital asset. For example, the application is a word processing application connected to a digital document interface. As another example, the application is an image editing application connected to a digital image interface.

[0168] As mentioned above, application 806 accesses digital asset 720a. For demonstration purposes, application 806 interfaces with digital asset synchronization system 702a and digital asset conflict resolution system 302a to obtain a manifest for the digital asset. As described above, application 806 utilizes the manifest to identify the composite parts that make up the digital asset and the file locations (in the case of components) that store the content of those composite parts (because components can be stored in files distributed across client devices 802). By accessing the composite parts, application 806 presents (e.g., displays) the digital asset to the user as a single, integral file.

[0169] Further, in various embodiments, the application 806 detects annotations (e.g., special property flags) placed in the composite part as a result of resolving conflicts. In response, the application 806 can perform application-specific operations to automatically repair or regenerate the portion of the digital asset (e.g., generate a new rendition using the updated composite part). Additionally or alternatively, the application 806 communicates the annotations to a user accessing the digital asset. For example, the application 806 notifies the user of past conflicts and how the conflicts were resolved.

[0170] As further mentioned, in one or more embodiments, application 806 enables a user to modify (e.g., create, change, or delete) one or more composite parts of a digital asset. For example, if the digital asset is an image with multiple layers, application 806 enables a user to edit the content within the layers. Additionally, application 806 may enable a user to add or remove layers. As described above, when application 806 creates or modifies a digital asset, digital asset synchronization system 702a detects changes to the composite parts of the digital asset, updates the mapping of the digital asset, and modifies one or more corresponding files. Then, if a conflict is detected, conflict resolution system 302a resolves the conflict.

[0171] In some embodiments, the application 806 can communicate with the remote digital asset synchronization system 702b and the remote digital asset conflict resolution system 302b to directly access the remote digital assets 720b. For example, the application 806 provides one or more remote digital assets 720b to the user (e.g., displays a preview of one or more remote digital assets 720b) ​​and enables the user to select a digital asset to be fully displayed or modified within the application. Further, in some embodiments, the application 806 accesses previous versions of digital assets and / or specific composite parts from the remote digital asset database 718b, such as when the digital asset database 718a on the client device 802 does not maintain previous versions of the digital assets, but the remote digital asset database 718b maintains previous versions.

[0172] In one or more embodiments, the client device 802 includes multiple applications. For example, a user uses two or more applications on the client device 802 to access the same digital asset simultaneously. As previously mentioned, when a user modifies a composite part within one application, the digital asset synchronization system 702a and the digital asset conflict resolution system 302a update the other applications to reflect the changes in the digital asset. Alternatively, if the digital asset is modified in both applications before cross-application synchronization, the conflict resolution system 302a detects and resolves the conflict.

[0173] As mentioned above, the server device 804 includes the remote digital asset synchronization system 702b and the remote digital asset conflict resolution system 302b. In addition, the server device 804 includes a remote digital asset database 718b. In short, the remote digital asset database 718b typically includes more digital assets than those found on the client device because the client device does not synchronize the user's entire digital asset collection locally. Generally, the server device 804 has a larger storage capacity than the client device, especially the mobile client device.

[0174] For illustration, the remote digital asset database 718b may store a complete set of digital assets, while the client device maintains only a partial set. As another example, as a result of the additional storage capacity of the server device 804, the remote digital asset database 718b stores one or more previous versions (e.g., version manifests and composite part files) of the digital assets or composite parts as mentioned above. In this manner, the remote digital asset synchronization system 702b and the remote digital asset conflict resolution system 302b can provide previous versions to the client device upon request.

[0175] In one or more embodiments, the remote digital asset database 718b also includes user information 820. For example, the remote digital asset database 718b maintains digital assets for multiple users. In this way, the remote digital asset synchronization system 702b and the remote digital asset conflict resolution system 302b associate each digital asset with one or more users who have rights to the digital asset. Because the remote digital asset synchronization system 702b and / or the remote digital asset conflict resolution system 302b can store each composite part of the digital asset in a file distributed across the remote database (or in another storage location), the remote digital asset synchronization system 702b and / or the remote digital asset conflict resolution system 302b can store files from different users together.

[0176] For illustration, the remote digital asset conflict resolution system 302b stores a first set of files from User 1 and User 2 together in a first directory, and stores a second set of files from User 1 and User 2 in a second directory. In this way, the remote digital asset synchronization system 702b and / or the remote digital asset conflict resolution system 302b can use the user information 820 to identify the composite portion of digital assets belonging to a particular user. In some examples, the remote digital asset synchronization system 702b and / or the remote digital asset conflict resolution system 302b adds the user information 820 to the inventory (e.g., mapping) of remote digital assets stored in the remote digital asset database 718b.

[0177] As a note, although in Figure 8 Only one server device 804 is shown in the figure, but it is understood that the remote digital asset synchronization system 702b and the remote digital asset conflict resolution system 302b can operate across multiple server devices or be located on separate client devices. Further, although the remote digital asset conflict resolution system 302b and the remote digital asset database 718b are illustrated on the server device 804, in some embodiments, the remote digital asset database 718b is stored on a separate computing device or a group of computing devices. For example, the remote digital asset database 718b is distributed across a cloud-based storage network.

[0178] As described above, the client device 802 communicates with the server device 804 to synchronize digital assets. More specifically, the digital asset synchronization system 702a and the digital asset conflict resolution system 302a on the client device 802 communicate with the remote digital asset synchronization system 702b and the remote digital asset conflict resolution system 302b to share one or more digital assets and resolve digital asset conflicts. For example, the client device 802 sends (e.g., uploads) digital asset data including newly created digital assets, modified composite parts (including digital asset lists and modified files), and / or other data to the server device 804. Similarly, the client device 802 receives (e.g., downloads) corresponding digital asset data from the server device 804. While downloading the digital asset data, the client device 802 may send a confirmation indication to the server device 804 indicating that the digital asset data was successfully received.

[0179] When synchronizing data, the remote digital asset conflict resolution system 302b can detect conflicts between versions of digital assets stored on different client devices. For example, a first user has been offline and has not synchronized digital assets for a period of time. Meanwhile, at least one other user has modified the digital assets one or more times. When the first user synchronizes her versions of digital assets, the remote digital asset conflict resolution system 302b detects and resolves conflicting digital assets for both the first user and the second user.

[0180] Additionally, as mentioned above, the remote digital asset conflict resolution system 302b can perform semantic digital asset conflict resolution on digital assets of a particular digital asset application independently of the digital asset application itself. More specifically, by utilizing a rule set corresponding to the media type of the composite part on the server device 804, the remote digital asset conflict resolution system 302b can resolve composite part conflicts during the synchronization process without opening or accessing the digital asset application corresponding to the digital asset (e.g., resolving PHOTOSHOP component conflicts on the server device 804 without accessing the PHOTOSHOP application). In general, the digital asset conflict resolution system 302 (e.g., local or remote) provides superior flexibility by executing different implementations of the conflict resolution system in different locations and at different times according to different modes.

[0181] Figures 1 to 8 , corresponding text and examples provide several different systems, methods, techniques, components and / or devices of the digital asset conflict resolution system 302 according to one or more embodiments. In addition to the above description, one or more embodiments may also be described according to a flowchart including actions for achieving a particular result. For example, Fig. 9 and Fig.10The flowchart of an exemplary sequence of actions according to one or more embodiments is illustrated. In addition, more or fewer actions may be utilized to perform Fig. 9 and Fig.10 Further, the actions may be performed in a different order. Additionally, the actions described herein may be repeated or performed in parallel with each other, or with different instances of the same or similar actions.

[0182] Although Fig. 9 and Fig.10 A series of actions according to a particular embodiment is illustrated, but alternative embodiments may omit, add to, reorder, and / or modify any of the actions shown. Fig. 9 and Fig.10 Alternatively, a non-transitory computer-readable medium may include instructions that, when executed by one or more processors, cause a computing device (e.g., a client device and / or a server device) to perform Fig. 9 and Fig.10 In further embodiments, a system performs Fig. 9 and Fig.10 The series of actions in .

[0183] In addition, the present invention may be implemented on one or more computing devices (such as computing device 700, client device 300, 802 or server device 301, 804). Fig. 9 and Fig.10 In addition, in some embodiments, the digital asset management system can be implemented in a digital environment for performing digital asset management on a composite file. Fig. 9 and Fig.10 In various embodiments, the series of actions in may be implemented on a computing device having a memory. Fig. 9 and Fig.10 The memory stores a digital asset comprising a first composite part and a second composite part, wherein the first and second composite parts are stored as separate files, and wherein each composite part has defined boundaries within the digital asset, the defined boundaries being modifiable without affecting other composite parts of the digital asset.

[0184] For illustration, Fig. 9A flow chart of a series of actions 900 for resolving conflicts within a composite-part-based digital asset according to one or more embodiments is shown. The series of actions 900 includes an action 910 of maintaining a digital asset including a first composite part and a second composite part. In particular, action 910 may involve maintaining a digital asset including the first composite part and the second composite part. In one or more embodiments, the digital asset further includes a manifest indicating properties of the digital asset and the composite part, the composite part of the digital asset including the first composite part and the second composite part.

[0185] The series of acts 900 also includes an act 920 of identifying a first modified version of the digital asset and a second modified version of the digital asset. In particular, act 920 may involve identifying a first modified version of the digital asset including a second composite part and a first modified version of the first composite part, and identifying a second modified version of the digital asset including the second composite part and a second modified version of the first composite part. In one or more embodiments, the first modified version and the second modified version of the first composite part are independently modified at different sources, wherein the first composite part, the first modified version of the first composite part, and the second composite part are components stored as separate component files.

[0186] Additionally, the series of acts 900 also includes an act of determining a conflict between the first modified version and the second modified version of the first composite part 930. In particular, act 930 can involve determining a conflict between the first modified version of the first composite part and the second modified version of the first composite part. In some embodiments, act 930 includes traversing corresponding composite parts in manifests of different versions of the digital asset to identify composite part conflicts.

[0187] As in Fig. 9 , the series of actions 900 further includes an action 940 of identifying a format-specific rule set that is compatible with the file media type of the first composite part. In particular, action 940 may involve: based on determining the conflict, identifying one or more format-specific rule sets that are compatible with the media type of the first composite part. In one or more embodiments, action 940 includes: determining that one or more format-specific rules in the identified rule set that are compatible with the media type of the first composite part do not resolve the conflict; and, in response, propagating the conflict to a parent rule in the identified rule set to resolve the conflict. In an additional embodiment, the parent rule resolves the conflict by separating the first modified version of the first composite part and the second modified version of the first composite part into two separate composite parts within the digital asset without copying the digital asset.

[0188] In various embodiments, action 940 includes identifying a first format-specific rule set and a second format-specific rule set that are compatible with a file media type of the first composite portion. In additional embodiments, action 940 includes updating the first composite portion based on the first format-specific rule set and the second format-specific rule set. In alternative embodiments, action 940 includes identifying an overlap between the first format-specific rule set and the second format-specific rule set, determining that the first format-specific rule set has a greater rule specificity than the second format-specific rule set, and updating the first composite portion by applying the first format-specific rule set and skipping the second format-specific rule set based on the specificity determination.

[0189] The series of actions 900 also includes an action 950 of resolving the conflict based on a format-specific rule set. In particular, action 950 can involve resolving the conflict between the first modified version of the first composite part and the second modified version of the first composite part based on one or more format-specific rule sets to generate a resolved version of the first composite part. In one or more embodiments, action 950 includes: combining the first modified version of the first composite part and portions of the second modified version of the first composite part to make the digital asset unresolvable or corrupted by the corresponding digital asset application, and then updating the first composite part based on the one or more format-specific rule sets to make the digital asset resolvable by the corresponding digital asset application.

[0190] In some embodiments, the digital asset is associated with a first application on a client device, and act 950 includes resolving a conflict between a first modified version of the first composite part and a second modified version of the first composite part at a client device remote from the first application. Additionally, the digital asset is associated with a first application on a client device, and act 950 includes resolving a conflict between the first modified version of the first composite part and the second modified version of the first composite part at a client device that does not host the first application. In various embodiments, act 950 further includes annotating the resolved version of the first composite part to indicate a conflict resolution to a user who subsequently accesses the digital asset having the resolved version of the first composite part.

[0191] As in Fig. 9 , the series of actions 900 further includes providing the resolved version of the first composite part to the remote device 960. In particular, action 960 may involve providing the resolved version of the first composite part to the remote device to replace the first composite part after resolving the conflict. In some embodiments, the remote device is a cloud-based server. In an alternative embodiment, the remote device is a remote client device.

[0192] For illustration, Fig.10 A flow chart of a series of actions 1000 for resolving conflicts using a format-specific rule set within a composite-part-based digital asset according to one or more embodiments is shown. The series of actions 1000 includes an action 1010 of identifying a first modified version and a second modified version of a composite part. In particular, action 1010 may involve identifying a first modified version of a first composite part of a digital asset and a second modified version of the first composite part. In some embodiments, the first modified version of the first composite part and the second modified version of the first composite part share the same composite part identifier and the same path with the first composite part. In one or more embodiments, a first application at a client device generates a first modified version of the first composite part, and a second application at the client device generates a second modified version of the first composite part. In addition, action 1010 may involve traversing a first manifest of a first version of the digital asset and a second manifest of a second version of the digital asset, and comparing the first and second manifests node by node and composite part by composite part to identify that the first composite part in the first manifest is different from the first composite part in the second manifest.

[0193] The series of actions 1000 also includes an action 1020 of detecting a conflict between a first modified version and a second modified version of a composite part. In particular, action 1020 can involve detecting a conflict between a first modified version of a first composite part of a digital asset and a second modified version of the first composite part. For example, action 1020 includes: receiving a plurality of different versions of the first composite part from different sources.

[0194] Additionally, the series of acts 1000 also includes an act 1030 of identifying a format-specific rule set corresponding to the media type of the first composite part. In particular, act 1030 can involve identifying a subset of the format-specific rule set from the rule set corresponding to the file media type of the first composite part. In some embodiments, the rule set is stored in a file, wherein the first composite part and the second composite part are on a client device and / or a server device.

[0195] As in Fig.10, the series of actions 1000 further includes an action 1040 of determining that the first format-specific rule set has a greater specificity than the second format-specific rule set. In particular, action 1040 can involve determining from a subset of format-specific rule sets that, in the subset of format-specific rule sets, the first format-specific rule set has a greater specificity than the second format-specific rule set. In one or more embodiments, action 1040 includes determining that a rule type of the first format-specific rule set matches a media type of the first composite part. In additional embodiments, action 1040 includes determining that a rule type for the second format-specific rule set is a default format-specific rule set that applies to all composite parts.

[0196] The series of actions 1000 also includes an action 1050 of resolving a conflict between the first modified version and the second modified version of the composite part based on the first format-specific rule set. In particular, action 1050 may involve updating the digital asset by resolving the conflict between the first modified version of the first composite part and the second modified version of the first composite part based on the first format-specific rule set. In some embodiments, action 1050 utilizes a software-independent process based on the first format-specific rule set. In additional embodiments, the software-independent process occurs at a server device during synchronization of the digital asset with a client device that provides the first modified version of the first composite part. Action 1050 may involve: accessing a selector clause in the first format-specific rule set that indicates to which portion of the manifest of the first asset the first format-specific rule set applies; determining a trigger clause in the first format-specific rule set that indicates that the first format-specific rule set should be applied; accessing an action clause in the first format-specific rule set; and merging the first modified version of the first composite part and the second modified version of the first composite part according to the action clause.

[0197] As in Fig.10 , the series of actions 1000 further includes providing the resolved composite part to the client device 1060. In particular, action 1060 can involve providing updated digital assets to the client device when the conflict is resolved. In some embodiments, action 1060 includes providing an updated list for the digital asset and one and / or more resolved composite parts.

[0198] As used herein, the term "digital environment" generally refers to an environment implemented as, for example, a standalone application (e.g., a personal computer or mobile application running on a computing device), a portion of an application, a plug-in for an application, one or more library functions, a server device, and / or a cloud computing system. The digital media environment allows the conflict resolution system to perform digital asset management, synchronization, and conflict resolution between and across computing devices.

[0199] As discussed in more detail below, embodiments of the present disclosure may include or utilize a special-purpose or general-purpose computer including computer hardware (such as, for example, one or more processors and system memory). Embodiments within the scope of the present disclosure also include physical readable media and other computer readable media for carrying or storing computer executable instructions and / or data structures. In particular, one or more of the processes described herein may be implemented at least in part as instructions embodied in a non-transient computer readable medium and executable by one or more computing devices (e.g., any of the media content access devices described herein). Generally, a processor (e.g., a microprocessor) receives instructions from a non-transient computer readable medium (e.g., a memory) and executes those instructions to perform one or more processes, including one or more of the processes described herein.

[0200] Computer-readable media can be any available media that can be accessed by a general or special-purpose computer system. A computer-readable medium that stores computer-executable instructions is a non-transient computer-readable storage medium (device). A computer-readable medium that carries computer-executable instructions is a transmission medium. Therefore, by way of example and not limitation, embodiments of the present disclosure may include at least two distinct computer-readable media: a non-transient computer-readable storage medium (device) and a transmission medium.

[0201] Non-transitory computer-readable storage media (devices) include: RAM, ROM, EEPROM, CD-ROM, solid-state drives ("SSD") (e.g., RAM-based), flash memory, phase-change memory ("PCM"), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store computer-executable instructions or desired program code components in the form of data structures and that can be accessed by a general or special purpose computer.

[0202] "Network" is defined as one or more data links that enable electronic data to be transported between computer systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computer through a network or other communication connection (hard-wired connection, wireless connection, or a combination of hard-wired connection or wireless connection), the computer properly regards the connection as a transmission medium. Transmission media may include networks and / or data links that can be used to carry computer executable instructions or data structure forms and that can be accessed by general or special-purpose computers to desired program code components. The combination of the above content should also be included in the scope of computer-readable media.

[0203] Further, when the program code parts of computer executable instructions or data structure form arrive various computer system components, these program code parts can be automatically transferred to non-transient computer readable storage medium (equipment) (or vice versa) from transmission medium.For example, the computer executable instructions or data structure received by network or data link can be buffered in the RAM in the network interface module (for example, "NIC"), and then finally transferred to the computer system RAM and / or the not so volatile computer storage medium (equipment) at the computer system.Therefore, it should be understood that non-transient computer readable storage medium (equipment) can be included in the computer system component that also (or even mainly) utilizes transmission medium.

[0204] Computer executable instructions include, for example, instructions and data that cause a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a specific function or group of functions when executed by a processor. In some embodiments, computer executable instructions are executed by a general-purpose computer to convert a general-purpose computer into a special-purpose computer that implements the elements in the present disclosure. Computer executable instructions can be, for example, binary, intermediate format instructions (such as, assembly language) or even source code. Although the subject matter has been described in a language specific to structural features and / or method actions, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or the actions described above. Instead, the described features and actions are disclosed as example forms of implementing the claims.

[0205] Those skilled in the art will appreciate that the present disclosure can be practiced in a network computing environment with many types of computer system configurations (including: personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablet computers, pagers, routers, switches, etc.). The present disclosure can also be practiced in a distributed system environment, in which local computer systems and remote computer systems linked through a network (by a hardwired data link, a wireless data link, or a combination of a hardwired data link and a wireless data link) all perform tasks. In a distributed system environment, program modules can be located in local memory storage devices and remote memory storage devices.

[0206] Embodiments of the present disclosure may also be implemented in a cloud computing environment. As used herein, the term "cloud computing" refers to a model for implementing on-demand network access to a shared pool of configurable computing resources. For example, cloud computing may be employed in a market to provide universal and convenient on-demand access to a shared pool of configurable computing resources. A shared pool of configurable computing resources may be quickly provided via virtualization, and may be published with less management effort or service provider interaction, and then scaled accordingly.

[0207] The cloud computing model may consist of various features such as, for example, on-demand self-service, broad network access, resource pools, rapid elasticity, measured services, etc. The cloud computing model may also expose various service models such as, for example, software as a service (“SaaS”), platform as a service (“PaaS”), and infrastructure as a service (“IaaS”). The cloud computing model may also be deployed by using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, etc. In addition, as used herein, the term “cloud computing environment” refers to an environment that employs cloud computing.

[0208] Fig.11A block diagram of an example computing device 1100 that can be configured to perform one or more of the processes described above is illustrated. It is to be understood that one or more computing devices (such as computing device 1100) can represent the computing devices described above (e.g., computing device 700, client device 300, 802, or server device 301, 804). In one or more embodiments, computing device 1100 can be a mobile device (e.g., a mobile phone, a smart phone, a PDA, a tablet computer, a laptop, a camera, a tracker, a watch, a wearable device, etc.). In some embodiments, computing device 1100 can be a non-mobile device (e.g., a desktop computer or another type of client device). Further, computing device 1100 can be a server device that includes cloud-based processing and storage capabilities.

[0209] As in Fig.11 As shown in FIG. 1 , computing device 1100 may include one or more processors 1102, memory 1104, storage device 1106, input / output (“I / O”) interface 1108, and communication interface 1110, which may be communicatively coupled via a communication infrastructure (e.g., bus 1112). Fig.11 The computing device 1100 is shown in FIG. Fig.11 The components illustrated in FIG. 1 are not intended to be limiting. In other embodiments, additional or alternative components may be used. Furthermore, in some embodiments, the computing device 1100 includes more than the components illustrated in FIG. Fig.11 The components shown in FIG. will now be described in more detail. Fig.11 Components of computing device 1100 are shown in FIG.

[0210] In certain embodiments, processor(s) 1102 include hardware for executing instructions, such as those that make up a computer program. As an example and not by way of limitation, to execute instructions, processor(s) 1102 may retrieve (or fetch) instructions from internal registers, internal cache memory, memory 1104, or storage device 1106 and decode and execute them.

[0211] The computing device 1100 includes a memory 1104 coupled to the processor(s) 1102. The memory 1104 may be used to store data, metadata, and programs for execution by the processor(s). The memory 1104 may include one or more of a volatile memory and a non-volatile memory, such as a random access memory ("RAM"), a read-only memory ("ROM"), a solid state disk ("SSD"), a flash memory, a phase change memory ("PCM"), or other types of data storage. The memory 1104 may be an internal memory or a distributed memory.

[0212] The computing device 1100 includes a storage device 1106, which includes a storage device for storing data or instructions. As an example and not by limitation, the storage device 1106 may include the non-transient storage medium described above. The storage device 1106 may include a hard disk drive (HDD), a flash memory, a universal serial bus (USB) drive, or a combination of these or other storage devices.

[0213] As shown, computing device 1100 includes one or more I / O interfaces 1108, which are provided to allow a user to provide input (such as user strokes) to computing device 1100, receive output from computing device 1100, and otherwise transfer data to and from computing device 1100. These I / O interfaces 1108 may include a mouse, a keypad or keyboard, a touch screen, a camera, an optical scanner, a network interface, a modem, other known I / O devices, or a combination of I / O interfaces 1108. A touch screen may be activated with a stylus or a finger.

[0214] The I / O interface 1108 may include one or more devices for presenting output to a user, including, but not limited to: a graphics engine, a display (e.g., a display screen), one or more output drivers (e.g., a display driver), one or more audio speakers, and one or more audio drivers. In some embodiments, the I / O interface 1108 is configured to provide graphical data to the display for presentation to the user. The graphical data may represent one or more graphical user interfaces and / or any other graphical content that may serve a particular implementation.

[0215] The computing device 1100 may further include a communication interface 1110. The communication interface 1110 may include hardware, software, or both. The communication interface 1110 provides one or more interfaces for communication (such as, for example, packet-based communication) between the computing device and one or more other computing devices or one or more networks. As an example and not by limitation, the communication interface 1110 may include a network interface controller (NIC) or a network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or a wireless adapter for communicating with a wireless network (such as, WI-FI). The computing device 1100 may further include a bus 1112. The bus 1112 may include hardware, software, or both that connect the components of the computing device 1100 to each other.

[0216] In the foregoing description, the present invention has been described with reference to specific example embodiments thereof. Various embodiments and aspects of the present invention are described with reference to the details discussed herein, and the accompanying drawings illustrate the various embodiments. The above description and drawings are illustrative of the present invention and should not be construed as limiting the present invention. Many specific details are described to provide a thorough understanding of the various embodiments of the present invention.

[0217] Without departing from the spirit or essential characteristics of the present invention, the present invention may be embodied in other specific forms. The described embodiments should be considered in all respects only as illustrative and not restrictive. For example, the method described herein may be performed using fewer or more steps / actions, or the steps / actions may be performed in different orders. Additionally, the steps / actions described herein may be repeated or performed in parallel with each other, or repeated or performed in parallel with different instances of the same or similar steps / actions. Therefore, the scope of the present invention is indicated by the appended claims rather than the foregoing description. All changes within the equivalent meaning and scope of the claims will be included within the scope of the claims.

Claims

1. A non-transitory computer-readable medium storing instructions that, when executed by at least one processor, cause a computer system to: maintaining a digital asset, the digital asset comprising a first composite portion and a second composite portion; identifying a first modified version of the digital asset, the first modified version of the digital asset comprising the second composite part and a first modified version of the first composite part; identifying a second modified version of the digital asset, the second modified version of the digital asset comprising the second composite part and a second modified version of the first composite part; determining a conflict between the first modified version of the first composite part and the second modified version of the first composite part; Accessing a plurality of format-specific rule sets, wherein each format-specific rule set in the plurality of format-specific rule sets comprises: a first portion including specifying the format-specific rule set as a media type for one or more specific composite-part media formats, the first portion being separate from a plurality of format-specific rules included in the format-specific rule set; a second portion including the plurality of format-specific rules, the plurality of format-specific rules each resolving conflicts with a composite portion of the media type having the set of format-specific rules specified in the first portion; and a third portion, comprising rule exceptions, the rule exceptions being applicable to the plurality of format-specific rules within the format-specific rule set; identifying a media format of the first composite part based on determining the conflict; determining, from the plurality of format-specific rule sets, a format-specific rule set having a media type that matches the media format of the first composite portion based on analyzing a media type designation within the first portion of each format-specific rule set; resolving the conflict between the first modified version of the digital asset and the second modified version of the digital asset based on executing one or more format-specific rules in the format-specific rule set on the conflicting version of the first composite part to generate a resolved version of the first composite part while maintaining other composite parts of the digital asset; and The resolved version of the first composite part is provided to a remote device to replace the first composite part within the digital asset after resolving the conflict.

2. The non-transitory computer-readable medium of claim 1 , wherein the first portion of the first composite part and the second modified version of the first composite part are independently modified at different sources, and wherein the first composite part, the first modified version of the first composite part, and the second composite part are components stored as separate files.

3. The non-transitory computer readable medium of claim 1 , wherein: The digital asset is associated with a first application on the client device; and Resolving the conflict between the first modified version of the digital asset and the second modified version of the digital asset occurs on the client device independent of the first application.

4. The non-transitory computer readable medium of claim 1, wherein: The digital asset is associated with a first application on the client device; and Resolving the conflict between the first modified version of the digital asset and the second modified version of the digital asset occurs on a server device without using the first application.

5. A non-transitory computer-readable medium according to claim 4, wherein the instructions cause the computer system to: resolve the conflict between the first modified version of the digital asset and the second modified version of the digital asset based on executing one or more format-specific rules in the format-specific rule set by modifying the content within the first composite part according to the parsing action specified in the format-specific rule set to present the digital asset parsable by the first application.

6. The non-transitory computer-readable medium of claim 1, wherein the first portion comprises a header including the media type that specifies the format-specific rule set to the one or more specific composite-part media formats.

7. The computer-readable medium of claim 6, further comprising instructions that cause the computer system to: identifying overlapping rules between the format-specific rule set and the second format-specific rule set, the overlapping rules each being compatible with the media format of the first composite part; determining a rule in the first format-specific rule set that has greater media-type specificity than an overlapping rule in the second format-specific rule set; as well as Based on the determination of the specificity, the first composite portion is updated based on the rules in the first format-specific rule set while skipping the overlapping rules in the second format-specific rule set.

8. A non-transitory computer-readable medium according to claim 1, wherein the instructions cause the computer system to: resolve the conflict between the first modified version of the first digital asset and the second modified version of the digital asset based on executing one or more format-specific rules in the format-specific rule set, and the one or more format-specific rules annotate the resolved version of the first composite part to indicate the conflict resolution to a user who subsequently accesses the digital asset having the resolved version of the first composite part.

9. The non-transitory computer-readable medium of claim 1, wherein the digital asset further comprises: A manifest indicating a composite part comprising attributes and components of the digital asset, wherein the first composite part is a first component, and wherein the second composite part is a second component.

10. The non-transitory computer-readable medium of claim 1, wherein the instructions cause the computer system to resolve the conflict between the first modified version of the digital asset and the second modified version of the digital asset by: determining that the one or more format-specific rules in the identified rule set that is compatible with the media format of the first composite part do not resolve the conflict; and The conflict is propagated to a parent rule in the format-specific rule set to resolve the conflict.

11. A non-transitory computer-readable medium according to claim 10, wherein the instructions cause the computer system to: resolve the conflict between the first modified version of the digital asset and the second modified version of the digital asset by applying the parent rule and forking the first modified version of the digital asset and the second modified version of the digital asset into two separate composite parts within the digital asset.

12. A system for providing a method for performing complex conflict resolution within a digital asset, the system comprising: One or more computer-readable memories, the one or more computer-readable memories comprising: a digital asset comprising a first composite portion and a second composite portion; and A plurality of format-specific rule sets, including format-specific rule sets, each of the format-specific rule sets comprising: Several format-specific rules; and a media type, the media type specifying at least one composite-part media format, the plurality of format-specific rules in the format-specific rule set corresponding to the at least one composite-part media format, the media type being listed separately from the plurality of format-specific rules in the format-specific rule set; and rule exceptions, the rule exceptions applicable to the plurality of format-specific rules within the format-specific rule set; and A computing device having stored thereon instructions that, when executed by the computing device, cause the system to: identifying a first modified version of the first composite part and a second modified version of the first composite part of the digital asset; detecting a conflict between the first modified version of the first composite part and the second modified version of the first composite part of the digital asset; identifying a media format of the first composite portion of the digital asset; determining, from the plurality of format-specific rule sets, a format-specific rule set having a media type that matches the media format of the first composite part; updating the digital asset by resolving the conflict between the first modified version of the first composite part and the second modified version of the first composite part based on a first format-specific rule set without modifying other composite parts of the digital asset; and The updated digital asset is provided to the client device after resolving the conflict.

13. The system of claim 12, wherein the first modified version of the first composite part and the second modified version of the first composite part share a same composite part identifier and a same composite part path with the first composite part.

14. A system according to claim 12, wherein the instructions cause the system to: identify the first modified version of the first composite part and the second modified version of the first composite part in the digital asset by traversing a first manifest of the first version of the digital asset and a second manifest of the second version of the digital asset, and detect the conflict between the first modified version of the first composite part and the second modified version of the first composite part in the digital asset by comparing the first manifest and the second manifest node by node and composite part by composite part to identify that the first composite part in the first manifest is different from the first part in the second manifest.

15. The system of claim 14, wherein the instructions cause the system to resolve the conflict between the first modified version of the digital asset and the second modified version of the digital asset based on the format-specific rule set by: accessing a selector clause in the format-specific rule set, the selector clause indicating to which portion of the manifest of a first asset the format-specific rule set applies; and A trigger clause in the format-specific rule set is determined, the trigger clause indicating that the format-specific rule set should be applied.

16. A system according to claim 15, wherein the instructions cause the system to: resolve the conflict between the first modified version of the digital asset and the second modified version of the digital asset based on the format-specific rule set by accessing an action clause in the format-specific rule set and merging the first modified version of the first composite part and the second modified version of the first composite part according to the action clause.

17. A system according to claim 12, wherein the instructions cause the system to: update the digital asset by utilizing a software-independent process to resolve the conflict between the first modified version of the digital asset and the second modified version of the digital asset based on the format-specific rule set; and the software-independent process occurs at a server device during synchronization of the digital asset with the client device that provides the first modified version of the first composite part.

18. The system of claim 17, wherein the digital asset comprises one or more composite parts having different media formats.

19. In a digital media environment for performing digital asset management on a composite file, a computer-implemented method for resolving composite portion conflicts within a digital asset, the computer-implemented method comprising: maintaining a digital asset, the digital asset comprising a first composite portion and a second composite portion; identifying a first modified version of the first composite part modified by a first source; identifying a second modified version of the first composite part modified by a second source; determining a conflict between the modified version of the first composite part and the second modified version of the first composite part; Accessing a plurality of format-specific rule sets, wherein one or more format-specific rule sets of the plurality of format-specific rule sets each include: a first portion including specifying the format-specific rule set as a media type for one or more specific composite-part media formats, the first portion being separate from a plurality of format-specific rules included in the format-specific rule set; a second portion including the plurality of format-specific rules, the plurality of format-specific rules each resolving conflicts with a composite portion of the media type having the set of format-specific rules specified in the first portion; and a third portion, comprising rule exceptions, the rule exceptions being applicable to the plurality of format-specific rules within the format-specific rule set; identifying a media format of the first composite part based on determining the conflict; determining, from the plurality of format-specific rule sets, a format-specific rule set having a media type that matches the media format of the first composite portion based on analyzing the first portion of each format-specific rule set; resolving the conflict between the first modified version of the digital asset and the second modified version of the digital asset based on executing one or more format-specific rules in the format-specific rule set on the conflicting version of the first part to generate a resolved version of the first composite part while maintaining other composite parts of the digital asset; and The resolved digital asset is provided to the first source and the second source.

20. The computer-implemented method of claim 19, wherein the first portion comprises a header comprising the media type that specifies the format-specific rule set to the composite-part media format, a name of the format-specific rule set, and a version of the format-specific rule set.

Images