CTNF 18/949,321 CTNF 99224 -DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Allowable Subject Matter 12-151-08 AIA 07-43 12-51-08 Claim s 12,13,17 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Claim Rejections - 35 USC § 103 07-20-aia AIA The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. 07-21-aia AIA Claim(s) 1-8,9- 11,14-16,18-20, are reject ed under 35 U.S.C. 103 as being unpatentable over Lebare dian(US-20220101619-A1) in view of Kass(US-20200051030-A1). As per c laim 1, Lebaredian discloses “One or more processors comprising processing circuitry to: access a scene graph representative of a computer-generated environment that includes one or more scene elements comprising one or more scene features, wherein each scene feature of the one or more scene features is defined by one or more scene primitives comprised in at least one scene layer of one or more scene layers of the scene graph,” (Lebaredian discloses at para.[0043] “In accordance with disclosed embodiments, assets of a virtual environment may be defined in a scene description, which may be in the form of a scene graph comprising properties and values, and/or a language (in textual form) that describes the properties and values according to one or more schemas. Changes to portions of scene descriptions (e.g., textual description) at the server(s) 112 may be replicated to the client(s) 106 over the channel(s), and vice-versa. ” that a content management system includes a data store manager and communications manager implemented on one or more servers, that the system stores data representative of assets and metadata used to define one or more 3D environments, and that ; Lebaredian further discloses at para. [0048] that examples of assets include “layers, objects . . . stages (top level or root scene graphs), scenes, primitives, classes, and/or combinations thereof,” and that the scene description may be “in accordance with the Universal Scene Description (USD) framework,” which corresponds to a scene graph representative of a computer-generated 3D environment having scene elements/features defined by primitives in scene layers). The processors are further configured to “access an override feature scene graph based at least on tracking one or more changes associated with the one or more scene primitives” (Lebaredian discloses at para.[0029] “Assets may be described in terms of properties and values, and the properties and values of a particular asset may be defined and/or inherited through the asset relationships defined in the scene description, as well as overrides to one or more inherited properties (e.g., via layering and/or explicit overrides). (e.g., via layering and/or explicit overrides),” meaning that assets may be described in terms of properties and values, that those properties and values may be defined through asset relationships, and further at para.[0031] “Changes to portions of scene description may be tracked with respect to those versions of the content items, and difference data may be provided to the content management system for distribution to other subscribing clients;” which teaches tracking changes to scene-graph/layer content and representing those changes as override/difference information) create at least one override layer of the scene graph, the at least one override layer comprising a representation of the override feature scene graph (Lebaredian discloses at para.[0055] “Furthermore, in at least one embodiment, one or more properties of an asset(s) that is inherited from one or more other assets may be defined and/or specified in scene description with an override to the one or more properties from the other asset. An override to a property may, for example, replace or supersede the value(s) of the property and/or the property with a different value(s) and/or property. ” and further from para.[0056-0057 “In at least one embodiment, a layer may be provided in a scene description of a 3D virtual environment. A layer may contain or group zero or more other asset types such as objects and classes, which in turn may describe values for properties of those and/or other assets. In some examples, each layer may include an identifier that can be used to construct references to the layer from other layers. In some embodiments, each layer corresponds to a respective file (e.g., of scene description) used to represent the layer within the data store 114 . … For example, the list or stack may be ordered from strongest layer to weakest layer. Layers may be used to modify properties and/or values of existing assets in scene description without modifying their source in order to change virtually any aspect by overriding it in a stronger layer; ” which teaches creating/using an override layer of a scene graph that represents override information for modified scene features) propagate the at least one override layer to one or more client nodes of a collaborative content creation platform (CCCP), each client node executing at least one instance of a content creation application (CCA) (Lebaredian discloses at para.[0005]-[0006] and [0027]-[0030] that its cloud-centric platform enables multiple content creators to work on the same asset or scene simultaneously, that a publish/subscribe model is implemented in which clients subscribe to portions of a shared scene description, that changes are served to subscribing clients, and that differences between versions of content may be exchanged rather than entire descriptions, which teaches propagation of scene-description/layer changes to subscribed client nodes in a collaborative content creation platform) wherein the computer-generated environment is encoded using a three dimensional (3D) graphics data format (Lebaredian discloses at para.[0049] that the schemas, formats, languages, and interfaces for asset definitions may be “in accordance with the Universal Scene Description (USD) framework,” which is a 3D graphics scene description format). However, Lebaredian is does not disclose that the propagated difference/override information is propagated specifically as the claimed “at least one override layer,” Kass discloses that remaining limitation (Kass discloses at para.[0028] that one or more 3D content creation applications are coupled to a USD-based database, that subscribers identify assets/objects of interest and collaborate through real-time editing, and that the database is “In embodiments, the database is based on the Universal Scene Description (USD) format and schema. The entries or elements in the database are referred to herein as “assets.” ”; Kass further discloses at para.[0042] “More specifically, in embodiments, an asset can be loaded across a network from the server 104 to a first client 102 a . The client 102 a can make a change or changes (an update) to the asset. In embodiments according to the invention, after the update is made, the client 102 a advantageously loads and saves to the database 106 only the update to the asset. That is, the client 102 a does not return the entire, updated asset to the database 106 ; instead, the client 102 a saves only the part(s) (e.g., object, property, attribute) of the asset that changed. In turn, the changes to the asset can be provided to one or more of the other clients 102 b - n that, for example, subscribe to that asset ” which teaches propagating only changed scene-feature information through a collaborative USD platform. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to to apply Kass’s known USD-based incremental update/delta synchronization to Lebaredian’s USD layer/override scene-description system because both references address the same problem of enabling real-time collaboration among heterogeneous 3D content creation applications without transferring entire scene files or asset descriptions; the combination would predictably reduce network traffic and computational load while preserving accurate synchronized scene state across subscribed client nodes. As per claim 2 the combination of Lebaredian and Kass disclose all the elements of claim 1 as discussed above. Lebaredian also discloses wherein the 3D graphics data format comprises open universal scene description (OpenUSD),” Lebaredian discloses the claimed 3D graphics data format comprising OpenUSD/USD (Lebaredian discloses at para.[0050] “Assets may be defined, specified, formatted, and/or interfaced with in accordance with one or more schemas, one or more domain-specific schemas, and/or one or more scene description languages. In non-limiting examples, the schema, format, languages, and/or interfaces (e.g., APIs) may be in accordance with the Universal Scene Description (USD) framework ” which teaches that the computer-generated 3D environment is encoded using a USD/OpenUSD-type 3D graphics data format). As per claim 3 the combination of Lebaredian and Kass disclose all the elements of claim 1 as discussed above. Lebaredian discloses wherein the one or more processors are further to synchronize the one or more scene layers of the scene graph, (Lebaredian discloses synchronizing scene layers of the scene graph at para.[0028] “Aspects of the disclosure provide for the fast and bi-directional (e.g., between client and server) replication of content throughout content creation platforms while exchanging rich descriptions of 3D virtual environments with fidelity and consistency. Thus, multiple content creators may work on the same asset or scene simultaneously while each is presented with a consistent, current, and accurate state. Additionally, disclosed approaches may allow for the content creators to use diverse content creation tools without needing to manually export, exchange, then import entire files in order to view each other's work. As such, data loss, the consumption of computational resources, and long transfer times can be avoided;” that multiple content creators may work on the same asset or scene simultaneously while each is presented with a consistent and current state, and that, rather than transferring entire descriptions of assets or files, clients and the content management system exchange “data representative of differences between versions of content” to construct updated versions of the content; Lebaredian further discloses that assets may be defined through “layering and/or explicit overrides,” and that changes to portions of scene description are tracked and distributed to subscribing clients, which teaches synchronizing the scene layers/scene-description portions of the scene graph across the collaborative platform). As per claim 4 the combination of Lebaredian and Kass disclose all the elements of claim 1 as discussed above. Lebaredian also discloses wherein the one or more processors are further to generate one or more override primitives based at least on tracking the one or more changes associated with the one or more scene primitives to generate the override feature scene graph, Lebaredian discloses or at least renders obvious generating override-type primitive/delta information based on tracked changes to scene primitives (Lebaredian discloses at para.[0098] that a client may update content incrementally by supplying a “client 106 may create, delete, and/or modify content of the 3D virtual environment. Updating a file and/or resource may be done incrementally by the client 106 supplying a delta or difference for the content. This may, for example, occur with respect to a local copy or version of the content. For example, where the client 106 received one or more items of content from the content management system 104 (e.g., in association with one or more subscriptions), the content manager 410 at the client 106 may track such edits made to the content (e.g., scene description portion);” which teaches generating override information based on tracking changes to scene-description elements/properties/values in layers). Lebaredian further discloses that changes to scene description may propagate through relationships including “overrides,” that differences may be identified and used to update property/value resolution data, and that updates may include “changes—or differences—between versions of a scene description portion(s),” including added, deleted, and/or modified properties and values, which corresponds to generating change/override primitives for affected scene primitives. However, to the extent Lebaredian is argued not to expressly disclose the exact phrase “override primitives” or that the tracked override/difference information is used “to generate the override feature scene graph,”. As per claim 5 the combination of Lebaredian and Kass disclose all the elements of claim 1 as discussed above. Labaredian also discloes wherein the one or more processors are further to send a message to at least one server node of the CCCP to cause the at least one server node to add the at least one override layer; Lebaredian discloses or at least renders obvious sending a message/update from a client to a server node of the collaborative platform to cause the server to store/add the changed layer or override information (Lebaredian discloses at para.[0097] “client 106 may create, delete, and/or modify content of the 3D virtual environment. Updating a file and/or resource may be done incrementally by the client 106 supplying a delta or difference for the content. This may, for example, occur with respect to a local copy or version of the content. For example, where the client 106 received one or more items of content from the content management system 104 (e.g., in association with one or more subscriptions), the content manager 410 at the client 106 may track such edits made to the content (e.g., scene description portion);” which teaches a client-side message/update conveying changed override/layer information to the content management system). Lebaredian further discloses that if live updating is enabled, a client content manager “may publish the delta(s) to the content management server (e.g., through the API layer),” and another subscribed client may then receive the delta and update its local shared representation, which teaches sending the claimed message to a server node of the collaborative platform so the server can add/store and propagate the changed scene-description/layer information. However, Lebaredian does not expressly disclose that the message causes the server node to add “the at least one override layer” specifically, Kass discloses that remaining limitation or at least renders it obvious (Kass discloses at para.[0042] More specifically, in embodiments, an asset can be loaded across a network from the server 104 to a first client 102 a . The client 102 a can make a change or changes (an update) to the asset. In embodiments according to the invention, after the update is made, the client 102 a advantageously loads and saves to the database 106 only the update to the asset. That is, the client 102 a does not return the entire, updated asset to the database 106 ; instead, the client 102 a saves only the part(s) (e.g., object, property, attribute) of the asset that changed;” which teaches sending an update message from a client to a server database to cause the server to add/store the changed asset/property/layer information rather than the entire asset). Kass also discloses at para.[0048] “As mentioned above, in embodiments, the database 106 is based on the USD format and schema. USD provides the ability to layer together a series of “opinions” about properties for collections of objects.”, which makes it obvious that a client update message may cause the server to add/store a USD layer or layer update for subsequent notification and synchronization. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teachings of Kass into the teachings of Lebaredian in order to implement Lebaredian’s published client deltas/overrides using Kass’s server/database synchronization and USD layer-control mechanism because both references use a cloud-based collaborative 3D content platform in which heterogeneous client applications publish changes to a shared USD-style scene description; sending the changed override/layer information to the server so the server adds/stores it would predictably enable real-time propagation to subscribers while reducing network traffic and avoiding transfer of entire scene assets. As per claim 6 the combination of Lebaredian and Kass disclose all the elements of claim 1 as discussed above. Lebaredian also discloses “wherein the at least one override layer is generated by a first instance of a first CCA subscribed with the CCCP to at least a portion of the computer-generated environment and propagated to at least one of: one or more second instances of the first CCA or one or more instances of at least one second CCA subscribed with the CCCP to the at least the portion of the computer-generated environment,” Lebaredian discloses or at least renders obvious the claimed generation and propagation between subscribed CCA instances (Lebaredian discloses at para.[0028]-[0030] that a content management system maintains a scene description representing a 3D virtual environment, that clients subscribe to content items represented as portions of the scene description, that when a portion of the scene description is modified by a client, changes are served to subscribing clients and services, and that difference data may be provided to the content management system for distribution to other subscribing clients; Lebaredian also discloses at para.[0029] “Assets may be described in terms of properties and values, and the properties and values of a particular asset may be defined and/or inherited through the asset relationships defined in the scene description, as well as overrides to one or more inherited properties (e.g., via layering and/or explicit overrides);” which teaches that changed/override layer information generated by a subscribed client can be distributed to other subscribed clients of the same scene-description portion). Lebaredian further discloses at para.[0043] “In at least one embodiment, the communications manager 110 of the content management system 104 may be configured to establish and maintain one or more communications channels with one or more of the client(s) 106 . For example, the communications manager 110 may provide a respective bidirectional communications channel(s) to each client 106 ;” meaning that that clients connect to the server through bidirectional communication channels and a common API, that changes to portions of scene descriptions at the server may be replicated to clients and vice versa, and that the clients may include different applications such as physics simulation applications, AI applications, game engines, computer graphics applications, renderers, graphics editors, VR applications, AR applications, and scripting applications, which teaches propagation to second instances of the same type of application or to instances of different CCAs subscribed to the same shared 3D environment). However, does not expressly disclose that the propagated information is the claimed “at least one override layer” generated by the first CCA instance, Kass discloses the same subscribed-client propagation structure in a USD-based collaborative content platform (Kass discloses at para.[0028]-[0034] that a graphics editor such as Photoshop may connect to an asset in a database to add texture while a computer graphics or animation tool such as Maya may connect to the asset to animate it, that the two applications interoperate and collaborate, that subscribers identify assets or objects of interest, and that clients include different types of applications communicating with a server through an API). Kass further discloses at para.[0044]-[0046] that updates from any one client can be replicated to the database and then to other clients at interactive speeds, that a change made by one client prompts each subscriber to consider the change, and that an asset changed by a first client may also be changed by a second different type of client, which teaches propagation of changed scene/asset information from a first CCA instance to subscribed second instances of the same or different CCAs). It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to apply Kass’s subscribed heterogeneous-client replication to Lebaredian’s USD layer/override scene-description system because both references address real-time collaborative editing of the same 3D virtual environment by multiple content creation applications; propagating a generated override/delta layer from a first subscribed CCA to other subscribed CCA instances would predictably maintain consistent shared scene state while allowing different tools to operate on the same subscribed scene portion without transferring entire assets or files. As per claim 7 the combination of Lebaredian and Kass disclose all the elements of claim 1 as discussed above. Lebaredian also discloses wherein the at least one override layer is encoded according to a 3D graphics data format; (Lebaredian discloses at para.[0047]-[0049] that assets of a virtual environment include “layers,” “stages (top level or root scene graphs),” “scenes,” and “primitives,” that the assets of a virtual environment may be defined in a scene description “in the form of a scene graph comprising properties and values,” and that the schemas, formats, languages, and interfaces for asset definitions may be “in accordance with the Universal Scene Description (USD) framework,” which teaches encoding scene layers and primitives using a 3D graphics data format). Lebaredian further discloses at para.[0054]-[0057] that an override may replace or supersede inherited property values, that a layer may be provided in a scene description of a 3D virtual environment, and that layers may be used to modify existing assets without modifying their source “by overriding it in a stronger layer,” which teaches USD-style layer-based override information within the 3D scene-description format. However, to the extent Lebaredian is argued not to expressly disclose that the particular propagated override/delta layer is itself “encoded according to a 3D graphics data format,” Kass discloses the use of a USD-based collaborative content platform in which 3D content creation applications interact with a database “based on the Universal Scene Description (USD) format and schema,” and changed object/property/attribute information is saved and synchronized as incremental changes/deltas rather than as entire assets. As per claim 8 the combination of Lebaredian and Kass disclose all the elements of claim 1 as discussed above. Lebaredian also discloses wherein the override feature scene graph comprises one or more override primitives to override parameters of at least one of the one or more scene primitives of the computer-generated environment, at least one scene primitive of the one or more scene primitives being associated with at least one of: a geometry of one or more elements of the computer-generated environment, a surface texture of one or more elements of the computer-generated environment () , a material composition of one or more elements of the computer-generated environment (Lebaredian teaches at para.[0063] “Additionally, the asset 220 may be defined as an instantiated asset of the asset 250 , which is a source asset with respect to the asset 220 (e.g., a class). Thus, the asset 220 may inherit property-value pairs 252 and 254 from the asset 250 and the property-value pair 228 from the asset 222 (which is overridden in this example) providing an example of multiple inheritance where an instantiated asset may have multiple source assets. … For example, the asset 220 may represent a propeller of an airplane and both the asset 220 and an asset representing an airport hangar could inherit from the asset 250 so they each include properties of a shiny metal surface. Thus, in various embodiments, property inheritance may operate along a transform hierarchy, as well as from multiple classes.” This means that an asset has an attribute relating to the material composition, in this example “shiny metal” can be overridden.) , a surface color of one or more elements of the computer-generated environment (Lebaredian teaches in para.[0063] “In the example shown, the assets 216 , 218 , and 220 may each be defined in scene description as referencing assets to the asset 230 of the layer 204 , which may be an incorporated asset with respect to the assets 216 , 218 , and 220 . Thus, the assets 216 , 218 , and 220 may each inherit properties and/or values from the asset 230 . The scene description for the asset 230 may include a property-value pair 236 assigning a color property to green.” This means that the surface color attribute of an asset can be overridden, in this case being assigned to green. ) , a lighting environment of one or more elements of the computer-generated environment, a weight value of one or more elements of the computer-generated environment, or an inventory quantity of one or more elements of the computer-generated environment (As the claim element recites “at least one of” the prior art only need to disclose ) . As per claim 9 the combination of Lebaredian and Kass disclose all the elements of claim 1 as discussed above. Lebaredian also discloses wherein the at least one override layer represents a chronological sequence of override primitives generated based at least on a chronological order of the one or more changes associated with the one or more scene primitives, (Lebaredian discloses at para.[0101] “For example, on demand, the content manager 410 may construct a delta (diff) file for each content item (e.g., layer) that describes any changes made since the corresponding local representation was last synchronized with an external representation. In examples, a user may drag an object, creating a sequence of changes to the position values of the object. The content manager 410 may only send messages to the content management server 104 to reflect some of the states of the content—or may send all of the changes. In either case, the messages may be sent periodically or as available, such as to achieve a predetermined frame or update rate (e.g., about every 30 milliseconds for 30 frames per second) for content updates to the client(s) 106 (a single message may in some embodiments describe multiple states or versions of changes to content). The content manager 410 of a client 106 may generate, transmit, and apply delta files to and from an external source (e.g., the content management system 104 ), such as to bring a local representation(s) of content into correspondence with a remote and shared representation(s).” This means that a content manager may construct a delta/diff file for each content item, such as a layer, that describes changes made since the local representation was last synchronized; Lebaredian further discloses that when a user drags an object, this creates “a sequence of changes to the position values of the object,” and that the content manager may send messages reflecting “some of the states” or “all of the changes,” with a single message in some embodiments describing “multiple states or versions of changes to content,” which teaches representing a chronological sequence of scene-primitive/property changes in propagated delta/layer information). However, Lebaredian does not expressly disclose the exact limitation that the layer represents a “chronological sequence of override primitives” generated according to the chronological order of changes, Kass discloses the same ordered-change context in a collaborative 3D platform (Kass discloses at para.[0041] “In embodiments, the server 104 also includes a synchronizer 108 . As mentioned above, one or more of the clients 102 a - n can make changes to an asset. The synchronizer 108 synchronizes those changes with the data of the asset, and also synchronizes the data of the changed (updated) asset with other clients interested in that asset (e.g., other subscribers to the asset). ” which teaches generating and distributing deltas in the order of asset changes/versions. Kass further discloses that subscribers may work at the same time or different times while a version-control system manages changes to maintain integrity and fidelity, which supports using chronological/version ordering for update sequences.) It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teachings of Kass into the teachings of Laberedian in order to apply Kass’s version-controlled incremental update synchronization to Lebaredian’s delta/layer/override scene-description system such that override primitives are represented in chronological order, because both references synchronize collaborative edits to shared 3D scene content; preserving the order of tracked changes would predictably allow clients to reconstruct the correct updated scene state, avoid stale or out-of-order application of updates, and maintain consistency across subscribed content creation applications. As per claim 10 the combination of Lebaredian and Kass disclose all the elements of claim 1 as discussed above. Lebaredian also discloses wherein the one or more processors are further to apply a timestamp in the at least one override layer indicating a time that the one or more changes associated with the one or more scene primitives were made, (Lebaredian discloses at para.[0045] “Elements of an asset may include structural and/or non-structural elements, as described herein. Metadata (e.g., in a JSON) for content items may describe where the underlying data is located, Access Control Lists (ACLs) for which users are allowed to view and/or modify a content item, timestamps, lock and unlock statuses, data type information, and/or other service information ” meaning that metadata for content items may describe, among other service information, “timestamps,” and Lebaredian further discloses at para.[0047] “The data store manager 108 may operate one or more delta servers (e.g., one per metadata instance). A delta server may coalesce or collapse a series of delta changes (e.g., to scene description) into a new version of content, as described herein. For example, the changes may be received from a particular client 106 and may be collapsed into a keyframe version that is shared with other client(s) 106 so that the new incoming client(s) 106 may receive a relatively compact version of the content that reflects the changes. ” which teaches associating time/version metadata with scene-description content and delta changes).Lebaredian also discloses that updates may include the “changes—or differences—between versions of a scene description portion(s),” including added, deleted, or modified properties/values, and that changes may propagate through relationships such as “overrides,” which teaches timestamped/versioned change tracking in a layered scene-description system. However, Lebaredian does not expressly disclose applying the timestamp in the at least one override layer specifically to indicate the time the scene-primitive changes were made, Kass discloses the related version-control and synchronization context (Kass discloses at para.[0004]-[0008] that a synchronizer synchronizes client changes with a server database, that subscribers work together while “a version control system is used to manage changes,” and that updates are provided as “incremental updates (deltas) to the previous version of the asset,” which teaches managing the timing/order/versioning of collaborative 3D scene changes). It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teachings of Kass into the teachings of Lebaredian in order to include timestamps in Lebaredian’s override/delta layer information when applying Kass’s version-controlled incremental synchronization because both references synchronize collaborative edits to shared 3D scene data; timestamping the override/delta layer would predictably allow the system to determine when changes were made, maintain chronological ordering, support version control, resolve stale or conflicting updates, and ensure consistent application of scene changes across subscribed client applications. As per claim 11 the combination of Lebaredian and Kass disclose all the elements of claim 1 as discussed above. Lebaredian also discloses wherein the one or more processors are further to: process one or more second override layers; and selectively apply one or more override primitives of the one or more second override layers to the one or more scene primitives of the one or more scene layers, (Lebaredian discloses at para.[0029] In some respects, a content management system may maintain a scene description that represents elements of a 3D virtual environment with support for rich relationships between assets, in which assets may contain other assets, may be instantiated from other assets, may reference other assets, and/or may incorporate or inherit one or more portions of other assets. Assets may be described in terms of properties and values, and the properties and values of a particular asset may be defined and/or inherited through the asset relationships defined in the scene description, as well as overrides to one or more inherited properties (e.g., via layering and/or explicit overrides).” This means that clients may subscribe to different subsets of the scene description, that changes to modified portions of the scene description are served to subscribing clients, and that different clients use their subscribed subsets to resolve properties and values of assets, which teaches processing received override/layer change information and selectively applying only the portions relevant to that client’s subscribed scene-description content). Lebaredian also discloses at para.[0065]-[0066] that a client may resolve only the portions or content items of the scene description to which it is subscribed and may not use unsubscribed portions for resolution or composition, which corresponds to selectively applying override/layer information to scene primitives/properties in scene layers. Lebaredian also more specifically discloses at para.[0141] “The method 800 , at block B 806 includes transmitting the differences to the client based on the subscription thereby causing the client to resolve a value of the second content item based on the differences and the override. For example, the notifier 404 of the content management system 104 may transmit the differences to the client 106 A based on the subscription. The client 106 A may, for example, resolve a value of the property-value pair 236 based on the differences and the override specified for the corresponding property in the layer 204 . ” However, Lebaredian is does not expressly disclose processing “one or more second override layers” and selectively applying “override primitives” by those exact names, Kass discloses the same subscriber-side processing and selective application concept in a USD-based collaborative platform (Kass discloses at para.[0046] “In embodiments, a change to an asset in the database 106 made by one of the clients (application) 102 a - n prompts each subscriber to consider the change. That is, in embodiments, a subscriber processes or performs operations in response to being notified of the change or by receiving the change (e.g., by synchronizing with the database 106 ). For example, an animation tool (e.g., Autodesk Maya®) can be used to animate an object in a virtual scene, and a physics simulation application or physics engine (e.g., PhysX) can be used to simulate real-world physics associated with the object in the virtual scene” which teaches that a receiving client processes received changes and selectively acts on/apply them depending on relevance to that client). It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teachings of Kass into the teachings of Labaredian in order to a apply Kass’s filtered subscriber notification and client-specific processing of USD layer/property updates to Lebaredian’s layer/override/difference system because both references concern collaborative editing of shared USD-based 3D scene descriptions by heterogeneous client applications; selectively applying only relevant override primitives/layer changes would predictably reduce unnecessary processing, allow each CCA to operate only on scene primitives within its subscribed or relevant scene layers, and maintain correct client-specific resolved views of the shared scene. As per claim 14, the combination of Lebaredian and Kass disclose all the elements of claim 1 as discussed above. Lebaredian also discloses wherein the processing circuitry is comprised in at least one of : a control system for an autonomous or semi-autonomous machine; a perception system for an autonomous or semi-autonomous machine; a system for performing simulation operations; a system for performing digital twin operations; a system for performing light transport simulation; a system for performing collaborative content creation for three-dimensional assets (Lebaredian teaches that the system is comprised in a system for performing collaborative content creation for three-dimensional assets (Lebaredian teaches at (para. [0005]) “Aspects of the disclosure provide for the fast and bi-directional (e.g., between client and server) replication of content while exchanging rich descriptions of 3D virtual environments with fidelity and consistency.” This teaches a system for exchanging and synchronizing 3D virtual-environment content. Lebaredian further teaches at (para. [0028]) “multiple content creators may work on the same asset or scene simultaneously while each is presented with a consistent, current, and accurate state.” This further teaches that the system performs collaborative content creation for three-dimensional assets. Lebaredian further teaches at (para. [0027]) that the disclosed approaches “allow for the content creators to use diverse content creation tools without needing to manually export, exchange, then import entire files in order to view each other's work.” This teaches a collaborative content creation platform for 3D assets using different content creation tools) Since the claim element states “at least one of” this disclosure is enough to reject the entire claim.) ; a system for performing deep learning operations; a system for performing remote operations; a system for performing real-time streaming; a system for generating or presenting one or more of augmented reality content, virtual reality content, or mixed reality content; a system implemented using an edge device; a system implemented using a robot; a system for performing conversational AI operations; a system implementing one or more vision language models (VLMs); a system implementing one or more large language models (LLMs); a system for generating synthetic data; a system for generating synthetic data using AI; a system incorporating one or more virtual machines (VMs); a system implemented at least partially in a data center; or a system implemented at least partially using cloud computing resources. As per claim 15, A system comprising one or more processors to: generate one or more override primitives based at least on tracking one or more changes associated with one or more scene primitives of one or more scene layers that collectively define elements of a virtual scene, the one or more scene layers defined using a 3D graphics format and hosted using one or more server nodes of a collaborative content creation platform , Lebaredian teaches a system having processors/server components for tracking changes to scene-description/layer content in a collaborative 3D platform (Lebaredian teaches at (para. [0048]) “Examples of assets include layers, objects (e.g., models and/or model groups), stages (top level or root scene graphs), scenes, primitives, classes, and/or combinations thereof.” Lebaredian’s assets include the claimed scene layers, virtual-scene elements, and primitives. Lebaredian further teaches at (para. [0050]) “In non-limiting examples, the schema, format, languages, and/or interfaces (e.g., APIs) may be in accordance with the Universal Scene Description (USD) framework.” USD is a 3D scene-description/graphics format. Lebaredian further teaches that the collaborative platform hosts and synchronizes scene-description content using server nodes at (para. [0076]) “In accordance with aspects of the disclosure, a publish/subscribe model may be operated by the data store manager 108 (one or more database servers) to provide one or more portions of scene description of a 3D virtual environment to the client(s) 106 .” This teaches server-hosted scene-description portions in a collaborative content creation platform. Lebaredian further teaches tracking changes associated with scene-description portions including layer content at (para. [0101]) “the content manager may construct a delta (diff) file for each content item (e.g., layer) that describes any changes made since the corresponding local representation was last synchronized with an external representation.” This teaches tracking changed layer/scene-description content, although the support is partial because Lebaredian describes deltas/differences and layer overrides rather than using the exact term “override primitives”); create at least one override layer comprising a representation of the one or more override primitives , Lebaredian teaches creating or using a layer that represents override-based changes to scene-description properties (Lebaredian teaches at (para. [0054]) “one or more properties of an asset(s) that is inherited from one or more other assets may be defined and/or specified in scene description with an override to the one or more properties from the other asset.” This teaches override information for scene-description properties. Lebaredian further teaches at (para. [0056]) “Layers may be used to modify properties and/or values of existing assets in scene description without modifying their source in order to change virtually any aspect by overriding it in a stronger layer.” This teaches using a stronger layer to represent override-based modifications, which is analogous to an override layer comprising a representation of override information, but Lebaredian does not expressly use the claimed term “override primitives”); and propagate the at least one override layer to one or more client nodes coupled to the one or more server nodes of the collaborative content creation platform based at least on instructing the one or more server nodes to add the at least one override layer to the one or more scene layers that collectively define the virtual scene , Lebaredian teaches propagating client-generated update/difference information to subscribed client nodes through server nodes of the collaborative platform (Lebaredian teaches at (para. [0104]) “When the communications manager of the content management system receives an incremental update for a client, it may, using the subscription manager, directly forward the update (e.g., the message and/or difference data) to all other client(s) . . . subscribed to the corresponding content.” This teaches propagating client update/difference information to subscribed client nodes. Lebaredian further teaches at (para. [0105]) “The data store manager may keep track of all updates to each content item (e.g., file or resource) in a list” and “may periodically coalesce a base or original version of the content and a series of delta updates from one or more client(s) into a new version of the content.” This teaches that the server receives, stores, and incorporates update information into hosted scene content, which partially corresponds to instructing the server to add the override/update information to the hosted scene layers). However, Lebaredian does not expressly disclose generating “override primitives” and instructing the server nodes to add “the at least one override layer” using that exact override-layer terminology. Kass supplies or reinforces the missing limitations in the same USD collaborative-content context (Kass teaches at (para. [0004]) “The synchronizer can synchronize a change made by a client coupled to the server and data of the assets to include the change in the database, and can also synchronize changes in the database and data of clients coupled to the server.” This teaches a client change being added to server-hosted asset data and synchronized to clients. Kass further teaches at (para. [0049]) “Assets may be defined, specified, formatted, and/or interfaced with in accordance with one or more schemas, one or more domain-specific schemas, and/or one or more scene description languages. In non-limiting examples, the schema, format, languages, and/or interfaces (e.g., APIs) may be in accordance with the Universal Scene Description (USD) framework. The data store manager 108 and/or the client(s) 106 (and/or content managers 410 , renderers 414 , services 412 , described herein) may analyze asset definitions of a scene description in order to resolve the properties and values of assets of a 3D virtual environment. Schemas may ascribe meanings to the properties and values of the scene description (e.g., written in textual form using a scene description language), such as (for example and without limitation) any or a combination of: geometry, lights, physics (e.g., for rigid bodies, flexible materials, fluids and gases), materials, rigs, and the way their properties vary over time.” This teaches USD layer-based representation of changed property information. Kass further teaches at (para. [0051]) “Updates to assets in the database 106 are communicated back to clients that are subscribers to those assets.” This teaches propagation of added changed/layer information to subscribed client nodes). It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teachings of Kass into the teachings of Labaredian in order to combine Lebaredian’s USD scene-description layers, overrides, and publish/subscribe delta propagation with Kass’s USD database synchronizer that saves only changed object/property/attribute data and communicates those updates to subscribed clients, because both references address real-time collaborative editing of shared 3D virtual environments using heterogeneous content creation applications. The predictable technical benefit would be compactly representing scene-feature changes as layer/override-style update data, adding those updates to the server-hosted USD scene representation, and propagating them to subscribed client nodes while reducing network traffic, avoiding transfer of entire assets, and maintaining a consistent shared virtual scene. As per claim 16 the combination of Lebaredian and Kass disclose all the elements of claim 15 as discussed above. Lebaredian also discloses wherein the at least one override layer represents the one or more override primitives based at least on a scene graph data structure that represents the virtual scene , Lebaredian teaches representing scene layers, including override-based layer information, using scene graph data structures that represent the virtual scene (Lebaredian teaches at (para. [0048]) “Examples of assets include layers, objects (e.g., models and/or model groups), stages (top level or root scene graphs), scenes, primitives, classes, and/or combinations thereof.” This teaches that the virtual scene may include layers, primitives, and root scene graphs. Lebaredian further teaches at (para. [0048]) “The assets of a virtual environment may be defined in a scene description, which may be in the form of a scene graph comprising properties and values.” This teaches that the virtual scene is represented using a scene graph data structure. Lebaredian further teaches at (para. [0055]) “one or more properties of an asset(s) that is inherited from one or more other assets may be defined and/or specified in scene description with an override to the one or more properties from the other asset.” This teaches override information associated with scene-description properties. Lebaredian further teaches at (para. [0057]) “Layers may be used to modify properties and/or values of existing assets in scene description without modifying their source in order to change virtually any aspect by overriding it in a stronger layer.” This teaches that override-based modifications may be represented in a stronger layer of the scene description. Lebaredian further teaches at (para. [0064]) “The layers 202 and 204 may be defined by scene description in terms of scene graphs, which resolve to a scene graph of the resolved view 206 by merging the scene graphs according to resolution rules.” This teaches that layers are represented based on scene graph data structures that resolve into the virtual scene representation). However, Lebaredian does not expressly disclose the exact phrase “override primitives,” nor does it expressly state that an “override layer” represents “override primitives” using that terminology. Kass supplies or reinforces the same USD scene-graph/layer context (Kass teaches at (para. [0028]) “the database is based on the Universal Scene Description (USD) format and schema.” This teaches a 3D scene-description framework for representing virtual scenes. Kass further teaches at (para. [0049]) “USD provides the ability to layer together a series of ‘opinions’ about properties for collections of objects” and “Layering allows properties across objects in the layer (group) to be changed.” This teaches USD layer-based representation of property changes, which reinforces the use of scene-description layers to represent changed/override property information). It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teachings of Kass into the teachings of Labaredian in order to represent Lebaredian’s override/delta layer information using the same USD scene graph data structure that represents the virtual scene, in view of Kass’s USD layer-based property-change teachings, because both references use USD-style scene descriptions and layers to represent shared 3D virtual environments. The predictable technical benefit would be allowing override/delta information to be composed, resolved, and selectively applied to corresponding scene primitives using the same scene graph/layer structure already used by the collaborative 3D platform. As per claim 18, wherein the at least one override layer represents a chronological sequence of override primitives generated based at least on a chronological order of the one or more changes associated with the one or more scene primitives , Lebaredian teaches representing tracked scene-description changes in an ordered or versioned sequence of delta/difference information associated with scene layers and scene primitives/properties (Lebaredian teaches at (para. [0102]) “For example, on demand, the content manager 410 may construct a delta (diff) file for each content item (e.g., layer) that describes any changes made since the corresponding local representation was last synchronized with an external representation . In examples, a user may drag an object, creating a sequence of changes to the position values of the object ” This teaches generating delta/difference information for a content item such as a layer based on tracked changes and that changes to scene-description properties may occur in a sequence corresponding to the order in which the changes are made. Lebaredian further teaches at (para. [0101]) “The content manager 410 may only send messages to the content management server 104 to reflect some of the states of the content—or may send all of the changes. ” This teaches representing multiple ordered states or versions of scene changes, which is analogous to a chronological sequence of changed scene-property/primitive information. Lebaredian further teaches at (para. [0055]) “Furthermore, in at least one embodiment, one or more properties of an asset(s) that is inherited from one or more other assets may be defined and/or specified in scene description with an override to the one or more properties from the other asset. ” and at (para. [0057]) “Layers may be used to modify properties and/or values of existing assets in scene description without modifying their source in order to change virtually any aspect by overriding it in a stronger layer. ” This teaches override-based layer information, although Lebaredian does not expressly state that the ordered delta sequence is a chronological sequence of “override primitives” in an “override layer”). However, Lebaredian does not expressly disclose that the at least one override layer represents a chronological sequence of override primitives generated based on chronological order using that exact terminology. Kass supplies or reinforces the ordered/version-controlled incremental update context (Kass teaches at (para. [0008]) “Subscribers can work together at the same time or at different times while a version control system is used to manage changes to maintain the integrity and fidelity of the work product from potentially multiple simultaneous accesses and/or collaborators.” This teaches managing collaborative changes using version control. Kass further teaches at (para. [0009]) “updates to an asset are provided from the clients as incremental updates (deltas) to the previous version of the asset,” and that updates from the server are also provided “as deltas to the previous version of the asset.” This teaches ordered/version-relative delta updates used to maintain the state of shared 3D assets). It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teachings of Kass into the teachings of Lebaredian in order to represent Lebaredian’s override/delta layer information as a chronological sequence of override-style primitives in view of Kass’s version-controlled incremental-update synchronization because both references address synchronizing collaborative edits to shared 3D scene content. The predictable technical benefit would be preserving the order of tracked changes so subscribed client applications can reconstruct the correct current scene state, avoid stale or out-of-order application of changes, and maintain consistency across the collaborative platform. As per claim 19, wherein the system is comprised in at least one of: a control system for an autonomous or semi-autonomous machine; a perception system for an autonomous or semi-autonomous machine; a system for performing simulation operations; a system for performing digital twin operations; a system for performing light transport simulation; a system for performing collaborative content creation for three-dimensional assets (Lebaredian teaches that the system is comprised in a system for performing collaborative content creation for three-dimensional assets (Lebaredian teaches at (para. [0005]) “Aspects of the disclosure provide for the fast and bi-directional (e.g., between client and server) replication of content while exchanging rich descriptions of 3D virtual environments with fidelity and consistency.” This teaches a system for exchanging and synchronizing 3D virtual-environment content. Lebaredian further teaches at (para. [0028]) “multiple content creators may work on the same asset or scene simultaneously while each is presented with a consistent, current, and accurate state.” This further teaches that the system performs collaborative content creation for three-dimensional assets. Lebaredian further teaches at (para. [0027]) that the disclosed approaches “allow for the content creators to use diverse content creation tools without needing to manually export, exchange, then import entire files in order to view each other's work.” This teaches a collaborative content creation platform for 3D assets using different content creation tools). Since the claim element states “at least one of” this disclosure is enough to reject the entire claim.) ; a system for performing deep learning operations; a system for performing remote operations; a system for performing real-time streaming; a system for generating or presenting one or more of augmented reality content, virtual reality content, or mixed reality content; a system implemented using an edge device; a system implemented using a robot; a system for performing conversational AI operations; a system implementing one or more vision language models (VLMs); a system implementing one or more large language models (LLMs); a system for generating synthetic data; a system for generating synthetic data using AI; a system incorporating one or more virtual machines (VMs); a system implemented at least partially in a data center; or a system implemented at least partially using cloud computing resources. As per claim 20, A method comprising: tracking, across one or more instances of one or more content creation applications, one or more changes associated with one or more scene primitives organized across one or more scene definition layers representing one or more elements of a virtual scene environment , Lebaredian teaches tracking changes across content creation applications to scene-description portions including layers, primitives, properties, and values of a virtual scene environment (Lebaredian teaches at (para. [0044]) “The client(s) 106 may include one or more types of applications, software, and/or services, such as, but not limited to: a physics simulation application, an artificial intelligence (AI) application, a global illumination (GI) application, a game engine, a computer graphics application, a renderer, a graphics editor, a virtual reality (VR) application, an augmented reality application, or a scripting application. In embodiments where the applications or services are different from each other, the client(s) 106 may be referred to as “heterogeneous clients.” ” This teaches one or more instances of content creation applications operating in the platform. Lebaredian further teaches at (para. [0048]) “Examples of assets include layers, objects (e.g., models and/or model groups), stages (top level or root scene graphs), scenes, primitives, classes, and/or combinations thereof.” This teaches scene primitives organized across layers and other scene-description structures. Lebaredian further teaches at (para. [0048]) “The assets of a virtual environment may be defined in a scene description, which may be in the form of a scene graph comprising properties and values.” This teaches scene definition layers/elements representing a virtual scene environment. Lebaredian further teaches at (para. [0102]) “For example, on demand, the content manager 410 may construct a delta (diff) file for each content item (e.g., layer) that describes any changes made since the corresponding local representation was last synchronized with an external representation. .” This teaches tracking changes associated with scene-description content such as layers, although Lebaredian describes deltas/differences and layer overrides rather than using the exact term “override feature scene graph”); and propagating the one or more changes to one or more client nodes of a collaborative content creation platform (CCCP) that are subscribed, through the CCCP, to the one or more scene primitives , Lebaredian teaches propagating tracked changes to subscribed clients of a collaborative content creation platform (Lebaredian teaches at (para. [0007]) “A publish/subscribe model may be implemented in which clients subscribe to content items that correspond to respective portions of the shared scene description.” This teaches clients subscribed to portions of the virtual scene description. Lebaredian further teaches at (para. [0007]) “When changes are made to content, the changes may be served to subscribing clients.” This teaches propagating changes to subscribed client nodes. Lebaredian further teaches at (para. [0105]) “When the communications manager 110 of the content management system 104 receives an incremental update for a client 106 , it may, using the subscription manager 402 , directly forward the update (e.g., the message and/or difference data) to all other client(s) 106 (and in some embodiments the services 412 or renderers 414 ) subscribed to the corresponding content.” This teaches forwarding changed scene-description/difference information to subscribed client nodes); wherein the propagating comprises generating an override feature scene graph based at least on the one or more changes, creating at least one override layer comprising a representation of the override feature scene graph , Lebaredian teaches generating override/difference information based on tracked changes and representing override-based property changes in scene-description layers (Lebaredian teaches at (para. [0055]) “Furthermore, in at least one embodiment, one or more properties of an asset(s) that is inherited from one or more other assets may be defined and/or specified in scene description with an override to the one or more properties from the other asset. ” This teaches override information for scene-description properties. Lebaredian further teaches at (para. [0056]) “Layers may be used to modify properties and/or values of existing assets in scene description without modifying their source in order to change virtually any aspect by overriding it in a stronger layer.” This teaches creating or using a stronger layer to represent override-based modifications. Lebaredian further teaches at (para. [0102]) “For example, on demand, the content manager 410 may construct a delta (diff) file for each content item (e.g., layer) that describes any changes made since the corresponding local representation was last synchronized with an external representation. ” This teaches creating layer-associated delta/difference information based on tracked changes, which is analogous to an override layer representing an override feature scene graph, but Lebaredian does not expressly use the exact phrase “override feature scene graph”); and instructing a server node of the CCCP to add the at least one override layer to a representation of the virtual scene environment , Lebaredian teaches publishing client update/difference information to a server node and incorporating the update information into hosted scene content (Lebaredian teaches at (para. [0105]) “When the communications manager 110 of the content management system 104 receives an incremental update for a client 106 , it may, using the subscription manager 402 , directly forward the update (e.g., the message and/or difference data) to all other client(s) 106 (and in some embodiments the services 412 or renderers 414 ) subscribed to the corresponding content. .” This teaches sending update/difference information to a server node for propagation. Lebaredian further teaches at (para. [0106]) “The data store manager 108 may keep track of all updates to each content item (e.g., file or resource) in a list. The difference determiner 408 may periodically coalesce a base or original version of the content and a series of delta updates from one or more client(s) 106 into a new version of the content. ” This teaches that the server stores and incorporates the received update information into the hosted representation of the virtual scene, partially corresponding to adding the claimed override layer). However, Lebaredian does not expressly disclose generating an “override feature scene graph” or instructing the server to add “the at least one override layer” using that exact terminology. Kass supplies or reinforces the missing limitations in the same USD collaborative-content context (Kass teaches at (para. [0005]) “The synchronizer can synchronize a change made by a client coupled to the server and data of the assets to include the change in the database, and can also synchronize changes in the database and data of clients coupled to the server.” This teaches adding client-generated changes to server-hosted scene/asset data and synchronizing those changes with clients. Kass further teaches at (para. [0042]) “the client . . . does not return the entire, updated asset to the database; instead, the client . . . saves only the part(s) (e.g., object, property, attribute) of the asset that changed.” This teaches compact changed scene-feature information analogous to override/update primitives. Kass further teaches at (para. [0048]) “USD provides the ability to layer together a series of ‘opinions’ about properties for collections of objects” and “Layering allows properties across objects in the layer (group) to be changed.” This teaches USD layer-based representation of changed property information. Kass further teaches at (para. [0051]) “Updates to assets in the database are communicated back to clients that are subscribers to those assets.” This teaches propagation of server-added changed/layer information to subscribed client nodes). It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teachings of Kass into the teachings of Lebaredian to combine Lebaredian’s USD scene-description layers, overrides, and publish/subscribe delta propagation with Kass’s USD database synchronizer that saves only changed object/property/attribute data and communicates those updates to subscribed clients, because both references address real-time collaborative editing of shared 3D virtual environments using heterogeneous content creation applications. The predictable technical benefit would be compactly representing scene-feature changes as layer/override-style update data, adding those updates to the server-hosted virtual scene representation, and propagating them to subscribed client nodes while reducing network traffic, avoiding transfer of entire assets, and maintaining a consistent shared virtual scene. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRIS ALEJANDRO PUNTIER whose telephone number is (703)756-1893. The examiner can normally be reached M-F 7:30-5:00. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Daniel Hajnik can be reached at 571-272-7642. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /CHRIS ALEJANDRO PUNTIER/Examiner, Art Unit 2616 /DANIEL F HAJNIK/Supervisory Patent Examiner, Art Unit 2616 Application/Control Number: 18/949,321 Page 2 Art Unit: 2616 Application/Control Number: 18/949,321 Page 3 Art Unit: 2616 Application/Control Number: 18/949,321 Page 4 Art Unit: 2616
Prosecution Insights