Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This is in response to applicant’s amendments/remarks filed on January 30th, 2026, which have been entered and made of record. Claims 1-20 remain pending. Claims 1, 8, 11, 17 and 20 have been amended. Applicants amendments to the drawings, specifications and claims have overcome each and every objection previously set forth in the Non-Final Office Action mailed October 31st, 2025 and therefore, all have been withdrawn.
Response to Arguments
Applicant’s arguments, see Remarks pages 12-19, filed January 30th, 2026, with respect to the rejections of claims 1, 11 and 20 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of newly found prior art reference Freeman in view of Du and Dagani for independent claims 1 and 20 and Freeman in view of Du, Bhat and Dagani for claim 11 (See claims below for new reasoning/explanation/motivations). Additionally, a new 112(b) rejection has also been provided in relation to the term “Optionally” (see 112(b) rejection reasoning below).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 11 and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1, the phrase "optionally" renders the claim indefinite because it is unclear whether the limitation(s) following the phrase are part of the claimed invention. See MPEP § 2173.05(d). In claim 1, lines 6 and 12 refer to the term “optionally”, proceeded by additional claim language. However, “optionally” can be interpreted as “either/or”, thus implying and potentially making it unclear exactly how much of the claim language following the word “optionally”, in line 6, is considered to be “optional” and what is considered to be “required”. It can be interpreted that “receiving a second input from the user, the second input being in the form of at least one attachable associated with the at least one template character” is just optional and not required to perform the intended use of the claimed invention. Similarly, in line 12, “fitting the at least one attachable associated with the at least one template character to the at least one base character model” can be interpreted to be optional as well and thus, not required to perform the intended use of the claimed invention. However, it is being argued in paragraph 1, of page 15, of the applicant’s arguments/remarks that the prior art Chen’s “virtual try-on functionality is categorically different from the claimed fitting of attachables to base character models as part of generating an optimized data set”, which appears to indicate that the claim language following the term “optionally” in lines 6 and 12, are not actually optional then. Therefore, the term “optionally” should be removed for better overall clarity related to the claim language of claim 1.
Regarding claim 11, similar to claim 1, the word “optionally” is used in lines 7 and 14 and renders the claim indefinite. Again, it can be interpreted that “receiving a second input from the user, the second input being in the form of at least one attachable associated with the at least one template character” and “fitting the at least one attachable associated with the at least one template character to the at least one base character model” are optional and not required to perform the intended use of the claimed invention. However, the previously mentioned arguments appear to argue that these are required, so the term “optionally” should also be removed for better overall clarity related to the claim language of claim 11.
Regarding claim 20, similar to claims 1 and 11 above, the word “optionally” is used in lines 8 and 14 and renders the claim indefinite. Like previously mentioned above, it can be interpreted that “receive a second a second input from the user, the second input being in the form of at least one attachable associated with the at least one template character” and “fit the at least one attachable associated with the at least one template character to the at least one base character model” are optional and not required but that doesn’t appear to be the case from the applicant’s arguments. Therefore, like previously mentioned, the term “optionally” should be removed for better overall clarity related to the claim language of claim 20.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 1-7, 9-10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Freeman (Pub. No.: US 2016/0171738 A1) in view of Du (Pub. No: US 2024/0265634 A1) and Dagani et al. (U.S. Patent: #11,321,907 B1) hereinafter Dagani.
Regarding claim 1, Freeman discloses a computer implemented method for dynamically improving the performance of real-time rendering systems via the creation and rendering of a character model based on an optimized data set (FIG. 6 and paragraph 48 teach that FIG. 6 sets forth a flow diagram of method steps for rigging animated characters via a character rigging hierarchy, according to one embodiment.), the method comprising:
receiving a first input from a user (Paragraph 18 teaches an I/O bridge 107, which may be, e.g., a Southbridge chip, receives user input from one or more user input devices 108), the first input being in the form of at least one template character comprising a template character shape model (Paragraph 29 teaches that the animation rigging system 200 creates new character rigs by combining existing component rigs selected by a user or another software application program. The component rigs include one or more of a root rig, template rigs, and individual character rigs and paragraph 14 teaches that a new character may be rigged by choosing component rigs from the animated character rigging hierarchy. These component rigs include a base character rig, such as a human rig, and one or more template rigs for various character portions, such as a human thin body and a particular face. In other words, a base rig defines a broad category or type of character, such as a human, a horse, or a bird. However, in some embodiments, a base rig may define a non-living character, such as a chair a broom, or an imaginary character, such as a monster or a space alien. Template rigs include more detailed rigging information about a particular portion of a character specified the base rig. For example, template rigs in a hierarchy for a human base rig could include, without limitation, a body rig, a face rig, and a hand rig. In some embodiments, template rigs may have certain qualifiers as well. For example, body template rigs in a hierarchy for a human base rig could include, without limitation, an average body rig, a thin body rig, and a heavy body rig.). However, Freeman fails to disclose a template character texture model.
Du discloses a character texture model (Paragraph 55 teaches that the model data set of the three-dimensional model also includes texture data required for rendering and basic material attribute data different from those of another three-dimensional model. The model mesh data, a texture, and a basic material attribute may be considered as model data corresponding to the three-dimensional model in different dimensions.). Since Freeman teaches a character animation method that allows for receiving inputs from a user to receive template data related to a character model (shape and body data) and Du teaches an animation method for providing three-dimensional character model data sets that provide character texture data for a three-dimensional character that can improve bone animations related to a character model, it would have been obvious to a person having ordinary skill in the art to combine the two features together so that the template character model, in addition of comprising data related to its shape, could also include three-dimensional texture data related to the template character model as well.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Freeman to incorporate the teachings of Du, so that the combined features together would provide additional character model data options for a user to select from, which would then provide more in depth and detailed templates for the user.
Furthermore, Freeman in view of Du disclose optionally, receiving a second input from the user (Paragraph 18 of Freeman teaches an I/O bridge 107, which may be, e.g., a Southbridge chip, receives user input from one or more user input devices 108), the second input being in the form of at least one attachable associated with the at least one template character (Paragraph 39 of Freeman teaches that the human body A fitting 524 includes fitting data, such as “bone” positions and various configuration values, for attaching the human body A rig 520 to a model for a particular animated character.);
receiving a third input from the user (Paragraph 18 of Freeman teaches an I/O bridge 107, which may be, e.g., a Southbridge chip, receives user input from one or more user input devices 108), the third input being in the form of at least one base character model comprising a base character shape model and a base character texture model (Paragraph 43 of Freeman teaches that the creation of rigs for multiple individualized characters is facilitated without the need to create customized rigs for each animated character. For example, by using animated character rigging hierarchies, a new thin human character named Bob could be created by selecting a human base rig, a human thin male template rig, and a “Bob” face rig.);
and generating, by at least one processor, the optimized data set (Paragraph 26 of Freeman teaches that the CPU 102 provides display processor 112 with data and/or instructions defining the desired output images, from which display processor 112 generates the pixel data of one or more output images, including characterizing and/or adjusting the offset between stereo image pairs and paragraph 30 of Freeman teaches that the animation rigging application 210 retrieves an animated character rigging hierarchy from the animation hierarchy database 242 corresponding to the selected root character. The animation rigging application 210 applies parameters and data corresponding to the selected character body type, character face type, and individual character, as specified by the animated character rigging hierarchy and generates one or more rigged characters 250.) comprising:
optionally, fitting the at least one attachable associated with the at least one template character to the at least one base character model (Paragraph 43 of Freeman teaches that with animated character rigging hierarchies, such as animated character rigging hierarchy 300 and animated character rigging hierarchy 400, rigging, rendering, and simulations are accomplished via inheritance of fitting, weights, and simulation data via the hierarchy. The creation of rigs for multiple individualized characters is facilitated without the need to create customized rigs for each animated character. For example, by using animated character rigging hierarchies, a new thin human character named Bob could be created by selecting a human base rig, a human thin male template rig, and a “Bob” face rig. Similarly, a new thin human character named Dallas could be created by selecting the same human base rig, the same, or an alternative, human thin male template rig, and a “Dallas” face rig). However, Freeman in view of Du fail to disclose converting the at least one base character shape model and the at least one base character texture model to an optimized data set.
Dagani discloses converting the at least one base character shape model and the at least one base character texture model to an optimized data set (Col. 8, Lines 8-15 teach that the daemon process may improve textures and geometric models by converting the textures to native formats or applying native compression schemes, removing unused levels of detail that may reduce bandwidth requirements along with the corresponding descriptors that inform the application of the changes; the new assets may be used by the GPU hardware and GPU driver of the device and Col. 11, Lines 3-12 teach that in one embodiment when both conditions are met, the daemon process 110 determines at 222 whether there are any un-optimized shaders and/or data assets for applications that are resident on the device. If so, flow continues to 223 where the daemon process 110 (optionally) compiles and/or converts shaders and/or data assets to be improved and/or optimized for applications that are resident on the device 101. Improved and/or optimized shaders and/or data assets are stored in the database 111. Flow returns to 221.). Since Freeman in view of Du teach a method that allows for receiving inputs from a user to receive template data related to a character model (shape and body data) and Dagani teaches a method for providing three-dimensional character model data sets that provide character texture data for a three-dimensional character, it would have been obvious to a person having ordinary skill in the art to combine the two features together so that the template character model, in addition of comprising data related to its shape, could also include three-dimensional texture data related to the template character model as well.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Freeman in view of Du to incorporate the teachings of Dagani, so that the combined features together would provide additional character model data options for a user to select from, which would then provide more in depth and detailed templates for the user.
Furthermore, Freeman in view of Du and Dagani disclose and generating runtime variations on the optimized data set (Col. 9, Lines 13-20 of Dagani teach that when the application 108 is initiated and the GPU driver 109 begins to compile shaders, textures and/or geometric models of the application 108, the GPU driver 109 communicates with the daemon process 110 to obtain shaders, textures and/or geometric models that may be improved and/or optimized in comparison to the shaders, textures and/or geometric models that the GPU driver 109 may compile at runtime and paragraph 30 of Freeman teaches that the animation rigging application 210 retrieves an animated character rigging hierarchy from the animation hierarchy database 242 corresponding to the selected root character. The animation rigging application 210 applies parameters and data corresponding to the selected character body type, character face type, and individual character, as specified by the animated character rigging hierarchy and generates one or more rigged characters 250.)
Regarding claim 2, Freeman in view of Du and Dagani disclose everything claimed as applied above (see claim 1), in addition, Freeman in view of Du and Dagani disclose wherein the runtime variations are generated by character blending at least two template character shape models with the at least one template character texture model (FIG. 6 and paragraph 79 of Du teach that according to the batch rendering method provided in the embodiment, from the perspective of different merging dimensions, the data information corresponding to the multiple to-be-merged models can be effectively merged in the different merging dimensions through S240 to S270 described below. In addition, paragraph 80 of Du teaches that in S240, multiple model data sets corresponding to the multiple to-be-merged models are acquired, where each of the model data sets includes model mesh data, a texture, and a basic material attribute and paragraph 85 of Du teaches that in S250, data merging is performed in a model mesh dimension according to model mesh data corresponding to each to-be-merged model so that corresponding merged mesh data are obtained.).
Regarding claim 3, Freeman in view of Du and Dagani disclose everything claimed as applied above (see claim 1), in addition, Freeman in view of Du and Dagani disclose wherein the runtime variations are generated by character blending at least two base character shape models with the at least one base character texture model (FIG. 6 and paragraph 79 of Du teach that according to the batch rendering method provided in the embodiment, from the perspective of different merging dimensions, the data information corresponding to the multiple to-be-merged models can be effectively merged in the different merging dimensions through S240 to S270 described below. In addition, paragraph 80 of Du teaches that in S240, multiple model data sets corresponding to the multiple to-be-merged models are acquired, where each of the model data sets includes model mesh data, a texture, and a basic material attribute and paragraph 120 of Du teaches that in S260, data merging is performed in a texture dimension according to a texture corresponding to each to-be-merged model so that corresponding merged texture data are obtained.).
Regarding claim 4, Freeman in view of Du and Dagani disclose everything claimed as applied above (see claim 1), in addition, Freeman in view of Du and Dagani disclose wherein the runtime variations are generated by character blending the at least one template character shape model with the at least one base character shape model and with one of the at least one base character texture model or the at least one template character texture model (FIG. 6 and paragraph 79 of Du teach that according to the batch rendering method provided in the embodiment, from the perspective of different merging dimensions, the data information corresponding to the multiple to-be-merged models can be effectively merged in the different merging dimensions through S240 to S270 described below. In addition, paragraph 156 of Du teaches that in S270, data merging is performed in a material attribute dimension according to a basic material attribute corresponding to each to-be-merged model so that corresponding merged material attribute data are obtained. Furthermore, paragraph 190 of Du teaches that Model 1 has model data in three dimensions: mesh 1, material attribute 1, and texture 1; and model 2 has model data in three dimensions: mesh 2, material attribute 2, and texture 2. By use of the method provided in the embodiment, model mesh data of mesh 1 and mesh 2 may be merged to constitute a merged mesh; material attribute data of material attribute 1 and material attribute 2 may be merged to constitute a merged material attribute; texture data of texture 1 and texture 2 may also be merged to constitute a merged texture; and finally, a batch rendering instruction is sent to a GPU and the GPU may call merged data including the merged mesh, the merged material attribute, and the merged texture through the batch rendering instruction, implementing a rendering presentation of images corresponding to model 1 and model 2.).
Regarding claim 5, Freeman in view of Du and Dagani disclose everything claimed as applied above (see claim 1), in addition, Freeman in view of Du and Dagani disclose wherein the runtime variations are generated by stylizing at least two template character shape models with the at least one template character texture model (Paragraph 83 of Du teaches that for example, for one model, the corresponding model mesh data may include vertex-related data (for example, vertex attribute data and vertex index offsets), skinned mesh data for representing bone animation, and fusion morphology data for representing expression changes of the role. A model tends to be rendered in units of triangular facets. In other words, the rendering on the model is converted to the rendering on multiple triangular facets. Each triangular facet may be represented by three vertices. Therefore, the vertex-related data may be considered as basic data for model rendering.).
Regarding claim 6, Freeman in view of Du and Dagani disclose everything claimed as applied above (see claim 1), in addition, Freeman in view of Du and Dagani disclose wherein the runtime variations are generated by stylizing at least two base character shape models with the at least one base character texture model (Paragraph 84 of Du teaches that in the embodiment, the vertex-related data included in the model mesh data may include data such as vertex coordinates, normals, tangents, shades, and vertex indexes; the skinned mesh data may include data such as bone weights, bone indexes, binding postures, and a bone matrix; and the fusion morphology data may include data such as vertex increments, normal increments, and tangent increments. Texture data are image data required for model mapping and also equivalent to one material attribute of the model. Generally, one model may correspond to multiple textures. Basic material attribute data may include data such as color attributes and brightness attributes for a rendering presentation.).
Regarding claim 7, Freeman in view of Du and Dagani disclose everything claimed as applied above (see claim 1), in addition, Freeman in view of Du and Dagani disclose wherein the runtime variations are generated by stylizing the at least one template character shape model with the at least one base character shape model and with one of the at least one base character texture model or the at least one template character texture model (FIG. 7 and paragraph 191 teach that FIG. 7 is a diagram showing a data structure of model mesh data of to-be-merged models in an example implementation of a batch rendering method according to an embodiment of the present disclosure. As shown in FIG. 7, mesh data include vertex-related mesh data 11, skinned mesh data 12, and fusion morphology mesh data 13; where vertex-related mesh data 11 include vertex description-related data, for example, mesh data such as vertex attribute-related data and vertex index offsets; the skinned mesh data 12 include bone description-related data, for example, data information such as bone attribute-related data and bone index offsets; and fusion morphology mesh data 13 include fusion morphology description-related data, for example, data information such as incremental offsets of data related to face deformation. Additionally, FIG.9 and paragraph 193 of Du teach that FIG. 9 is a diagram showing a merging result of texture data of to-be-merged models in an example implementation of a batch rendering method according to an embodiment of the present disclosure. As shown in FIG. 9, model 1 and model 2 include four textures in total, which are texture 1, texture 2, texture 3, and texture 4, separately. After texture merging, texture 1 may be filled into a first level of a texture array, and textures 2 to 4 may be filled into a second level of the texture array.).
Regarding claim 9, Freeman in view of Du and Dagani disclose everything claimed as applied above (see claim 1), in addition, Freeman in view of Du and Dagani disclose wherein the at least one attachable is associated with a 3D character other than the template character (Paragraph 43 of Freeman teaches that a heavy version of the character Bob could be created by selecting the human base rig, a human heavy male template rig, and the “Bob” face rig, and so on. If two new character rig are created from exactly the same component rigs, then the two characters would be the same as well. That is, if two new character rigs are created by selecting the human base rig, the human thin male template rig, and an “Adam” face rig, then the two characters would appear to be a thin male named Adam and Adam's identical twin. By using a rigging hierarchy, sufficiently populated with component template rigs and individual character rigs, a crowd of fifty or one hundred individual characters could be created in a fraction of the time needed to create fifty or one hundred custom individualized rigs from scratch.).
Regarding claim 10, Freeman in view of Du and Dagani disclose everything claimed as applied above (see claim 9), in addition, Freeman in view of Du and Dagani disclose wherein the step of generating the optimized data set further comprises, prior to the converting step: asset fitting the at least one attachable associated with the 3D character to the template character to yield a template-fitted attachable (Paragraph 40 of Freeman teaches that the human face Bob rig 530 is a level 2 template rig for a human with a face type of “Bob”. The human face Bob rig 530 defines a template for a prototypical face for animated characters based on the “Bob” face type. The human face Bob rig 530 includes human face Bob weights 532 and human face Bob fitting 534. The human face Bob weights 532 include weights for the human face Bob rig 530 template. The human face Bob weights 532 also include digital sculpting data that give specific shape to animated characters based on the “Bob” body type.);
and asset fitting the template-fitted attachable to the at least one base character (Paragraph 41 of Freeman teaches that in some embodiments, the human body A Bob rig 540 inherits weight data from the human weights 512 and the human high resolution weights 514 of the human rig 510. In some embodiments, the human body A Bob rig 540 also inherits human body A weights 522 and human body A fitting 524 from the human body A rig 520 and human face Bob weights 532 and human face Bob fitting 534 from the human face Bob B rig 530.).
Regarding claim 20, the system steps correspond to and are rejected similarly to the method steps of claim 1 (See claim 1 above). In addition, Freeman discloses a system for improving the performance of real-time rendering systems via the creation and rendering of a character model based on an optimized data set (FIG. 1), the method comprising: a processor; and a memory for storing executable instructions (FIG. 1 and paragraph 18 teach that as shown, system 100 includes a central processing unit (CPU) 102 and a system memory 104 communicating via a bus path that may include a memory bridge 105. CPU 102 includes one or more processing cores, and, in operation, CPU 102 is the master processor of system 100, controlling and coordinating operations of other system components. System memory 104 stores software applications and data for use by CPU 102.).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Freeman in view of Du and Dagani, as applied to claim 1 above, and further in view of Vesdapunt et al. (Pub. No: US 2021/0358212 A1), hereinafter Vesdapunt.
Regarding claim 8, Freeman in view of Du and Dagani disclose everything claimed as applied above (see claim 1), however, Freeman in view of Du and Dagani fail to disclose wherein the runtime variations are generated by at least one of: creating character groups, constraining base character models further comprising a base character shape model and a base texture model, constraining the usage of attachables, or constraining the colorization of 3D assets.
Vesdapunt discloses wherein the runtime variations are generated by at least one of: creating character groups, constraining base character models further comprising a base character shape model and a base texture model, constraining the usage of attachables, or constraining the colorization of 3D assets (Paragraph 73 teaches that the process 800 may also include an operation 820 of generating a three-dimensional (3D) model of the face of the human subject based on the 2D image by analyzing the 2D image of the face to produce a coarse 3D model of the face of the human subject, and refining the coarse 3D model through free form deformation to produce a fitted 3D model. The operation 820 may be implemented by the face fitting pipeline 500 illustrated in FIG. 5. Various techniques may be used to produce the coarse 3D model of the face of the human subject included in the 2D image. Some implementations may utilize 3DMM to produce a parametric base model (also referred to herein as a “coarse 3D model”) that provides coarse-scale geometry of the face of the subject. The coarse 3D model may be refined through free-form deformation to generate the fitted 3D model, and an as-rigid-as-possible (ARAP) deformation constraint to regularize the deformation and to prevent the coarse 3D model from deforming into nonsensible shapes.). Additionally, paragraph 40 teaches that the research into 3D face reconstruction may be divided into separate groups based on the input modality (e.g., RGB inputs which include 2D color information or RGB-D inputs which include depth information in addition to the color information), single view or multi-view, optimization-based or learning-based, the face models used, and different constraints being used. Deep learning-based 3D reconstruction approaches have also been developed that either target only for geometry or for both geometry and texture for monocular input. Most of these conventional approaches attempt to boost the reconstruction accuracy by through the addition of prior knowledge, such as by using a parametric face model, or by adding more constraints, such as sparse landmark loss, perception loss, or photometric loss. ReDA follows the latter approach by adding more constraints by adding more discriminating constraints to reduce ambiguities. ReDA utilizes discriminating constraints that go beyond the color constraint used by conventional approaches to 3D face reconstruction such as 3DMM to provide significant improvements in 3D face reconstruction. Implementations of ReDA may utilize depth constraints and a face parsing mask to provide significant improvements in the resulting 3D face model. Other constraints may be used in addition to and/or instead of one or more of these additional constraints to further improve the resulting 3D face model.) Since Freeman in view of Du and Dagani teach the initial method steps for generating the runtime variations of optimized data sets for base character models, including their heads, and Vesdapunt teaches the functionality of applying color constraints and additional constraints to a base 3D head model, it would have been obvious to a person having ordinary skill in the art to combine the two features together so that additional constraints could then be applied to the base character head models to help improve the generation of the optimization data sets.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Freeman in view of Du and Dagani to incorporate the teachings of Vesdapunt, so that the combined features together would help in improving the optimization of the data sets by incorporating different types of constraints to be implemented with colors and/or the shaping of the different base models.
Claims 11-16 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Freeman in view of Du and Bhat et al. (Pub. No.: US 2017/0372505 A1), hereinafter Bhat, and further in view of Dagani.
Regarding claim 11, Freeman discloses a computer implemented method for dynamically improving the performance of real-time rendering systems via the creation and rendering of a character model based on an optimized data set (FIG. 6 and paragraph 48 teach that FIG. 6 sets forth a flow diagram of method steps for rigging animated characters via a character rigging hierarchy, according to one embodiment.), the method comprising:
receiving a first input from a user (Paragraph 18 teaches an I/O bridge 107, which may be, e.g., a Southbridge chip, receives user input from one or more user input devices 108), the first input being in the form of at least one template character comprising a template character shape model (Paragraph 29 teaches that the animation rigging system 200 creates new character rigs by combining existing component rigs selected by a user or another software application program. The component rigs include one or more of a root rig, template rigs, and individual character rigs and paragraph 14 teaches that a new character may be rigged by choosing component rigs from the animated character rigging hierarchy. These component rigs include a base character rig, such as a human rig, and one or more template rigs for various character portions, such as a human thin body and a particular face. In other words, a base rig defines a broad category or type of character, such as a human, a horse, or a bird. However, in some embodiments, a base rig may define a non-living character, such as a chair a broom, or an imaginary character, such as a monster or a space alien. Template rigs include more detailed rigging information about a particular portion of a character specified the base rig. For example, template rigs in a hierarchy for a human base rig could include, without limitation, a body rig, a face rig, and a hand rig. In some embodiments, template rigs may have certain qualifiers as well. For example, body template rigs in a hierarchy for a human base rig could include, without limitation, an average body rig, a thin body rig, and a heavy body rig.). However, Freeman fails to disclose a template character texture model.
Du discloses a character texture model (Paragraph 55 teaches that the model data set of the three-dimensional model also includes texture data required for rendering and basic material attribute data different from those of another three-dimensional model. The model mesh data, a texture, and a basic material attribute may be considered as model data corresponding to the three-dimensional model in different dimensions.). Since Freeman teaches a character animation method that allows for receiving inputs from a user to receive template data related to a character model (shape and body data) and Du teaches an animation method for providing three-dimensional character model data sets that provide character texture data for a three-dimensional character that can improve bone animations related to a character model, it would have been obvious to a person having ordinary skill in the art to combine the two features together so that the template character model, in addition of comprising data related to its shape, could also include three-dimensional texture data related to the template character model as well.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Freeman to incorporate the teachings of Du, so that the combined features together would provide additional character model data options for a user to select from, which would then provide more in depth and detailed templates for the user.
Furthermore, Freeman in view of Du disclose optionally, receiving a second input from the user (Paragraph 18 of Freeman teaches an I/O bridge 107, which may be, e.g., a Southbridge chip, receives user input from one or more user input devices 108), the second input being in the form of at least one attachable associated with the at least one template character (Paragraph 39 of Freeman teaches that the human body A fitting 524 includes fitting data, such as “bone” positions and various configuration values, for attaching the human body A rig 520 to a model for a particular animated character.);
receiving a third input from the user (Paragraph 18 of Freeman teaches an I/O bridge 107, which may be, e.g., a Southbridge chip, receives user input from one or more user input devices 108), the third input being in the form of at least one base character model comprising a base character shape model and a base character texture model (Paragraph 43 of Freeman teaches that the creation of rigs for multiple individualized characters is facilitated without the need to create customized rigs for each animated character. For example, by using animated character rigging hierarchies, a new thin human character named Bob could be created by selecting a human base rig, a human thin male template rig, and a “Bob” face rig.);
receiving a fourth input from the user, the fourth input being in the form of at least one animation clip (Paragraph 18 of Freeman teaches an I/O bridge 107, which may be, e.g., a Southbridge chip, receives user input from one or more user input devices 108 (e.g., keyboard, mouse, joystick, digitizer tablets, touch pads, touch screens, still or video cameras, motion sensors, and/or microphones));
and generating, by at least one processor, the optimized data set (Paragraph 26 of Freeman teaches that the CPU 102 provides display processor 112 with data and/or instructions defining the desired output images, from which display processor 112 generates the pixel data of one or more output images, including characterizing and/or adjusting the offset between stereo image pairs and paragraph 30 of Freeman teaches that the animation rigging application 210 retrieves an animated character rigging hierarchy from the animation hierarchy database 242 corresponding to the selected root character. The animation rigging application 210 applies parameters and data corresponding to the selected character body type, character face type, and individual character, as specified by the animated character rigging hierarchy and generates one or more rigged characters 250.) comprising:
optionally, fitting the at least one attachable associated with the at least one template character to the at least one base character model (Paragraph 43 of Freeman teaches that with animated character rigging hierarchies, such as animated character rigging hierarchy 300 and animated character rigging hierarchy 400, rigging, rendering, and simulations are accomplished via inheritance of fitting, weights, and simulation data via the hierarchy. The creation of rigs for multiple individualized characters is facilitated without the need to create customized rigs for each animated character. For example, by using animated character rigging hierarchies, a new thin human character named Bob could be created by selecting a human base rig, a human thin male template rig, and a “Bob” face rig. Similarly, a new thin human character named Dallas could be created by selecting the same human base rig, the same, or an alternative, human thin male template rig, and a “Dallas” face rig). However, Freeman in view of Du fail to disclose retargeting the template animation rig to the at least one base character model.
Bhat discloses retargeting the template animation rig to the at least one base character model (Paragraph 111 teaches that to animate a customized static 3D model, a rigging process can be performed to generate a rig that changes the features of the 3D model. The combination of the customized static 3D model and the rig form an animation-ready 3D model that may be used to generate different poses for animation. Conceptual diagrams of processing pipelines for generating rigs for customized static 3D models in accordance with two embodiments of the invention are shown in FIGS. 5A and 5B. In the rigging processing pipeline shown in FIG. 5A, an single capture image is used to generate the customized rig for the customized 3D model, In FIG. 5A, the image is used to determine a 3D static geometry 501, and surface retargeting 502 is performed on the static geometry 501 to generate the customized rig 503.). Since Freeman in view of Du teach an optimization method that allows for receiving inputs from a user related to a template character model that includes bone animation skinning/rigging and Bhat teaches functions for being able to retarget the surfaces of the static geometry (template) data in order to create customizable animation rigs, it would have been obvious to a person having ordinary skill in the art to combine the two features together so that the animation rigging could then be customizable and allow for retargeting of the template animation unto other character models.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Freeman in view of Du to incorporate the teachings of Bhat, so that the combined features together would allow for additional animation rigging functionality that could be applied to additional character models then just a single basic template model.
Furthermore, Freeman in view of Du and Bhat disclose retargeting the template animation rig to the at least one attachable, in the case where the at least one attachable is received as the second input (Paragraph 67 of Bhat teaches that the 3D factorization of the face can be used to determine scene lighting factors 310 from the image and a customized 3D asset 315 that includes, but is not limited to, a texture and geometry of the face. In accordance with a number of embodiments, the customized 3D asset may also include other information useful for animation of a 3D model and/or for altering the look of the generated 3D model. The information provided may include, but is not limited to, hair identification, skin tone information and other identified facial features and/or accessories (e.g. facial hair, glasses) and paragraph 43 of Freeman teaches that with animated character rigging hierarchies, such as animated character rigging hierarchy 300 and animated character rigging hierarchy 400, rigging, rendering, and simulations are accomplished via inheritance of fitting, weights, and simulation data via the hierarchy. The creation of rigs for multiple individualized characters is facilitated without the need to create customized rigs for each animated character. For example, by using animated character rigging hierarchies, a new thin human character named Bob could be created by selecting a human base rig, a human thin male template rig, and a “Bob” face rig. Similarly, a new thin human character named Dallas could be created by selecting the same human base rig, the same, or an alternative, human thin male template rig, and a “Dallas” face rig). However, Freeman in view of Du and Bhat fail to disclose converting the at least one base character shape model and the at least one base character texture model to an optimized data set.
Dagani discloses converting the at least one base character shape model and the at least one base character texture model to an optimized data set (Col. 8, Lines 8-15 teach that the daemon process may improve textures and geometric models by converting the textures to native formats or applying native compression schemes, removing unused levels of detail that may reduce bandwidth requirements along with the corresponding descriptors that inform the application of the changes; the new assets may be used by the GPU hardware and GPU driver of the device and Col. 11, Lines 3-12 teach that in one embodiment when both conditions are met, the daemon process 110 determines at 222 whether there are any un-optimized shaders and/or data assets for applications that are resident on the device. If so, flow continues to 223 where the daemon process 110 (optionally) compiles and/or converts shaders and/or data assets to be improved and/or optimized for applications that are resident on the device 101. Improved and/or optimized shaders and/or data assets are stored in the database 111. Flow returns to 221.). Since Freeman in view of Du teach a method that allows for receiving inputs from a user to receive template data related to a character model (shape and body data) and Dagani teaches a method for providing three-dimensional character model data sets that provide character texture data for a three-dimensional character, it would have been obvious to a person having ordinary skill in the art to combine the two features together so that the template character model, in addition of comprising data related to its shape, could also include three-dimensional texture data related to the template character model as well.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Freeman in view of Du to incorporate the teachings of Dagani, so that the combined features together would provide additional character model data options for a user to select from, which would then provide more in depth and detailed templates for the user.
Furthermore, Freeman in view of Du, Bhat and Dagani disclose and generating runtime variations on the optimized data set (Col. 9, Lines 13-20 of Dagani teach that when the application 108 is initiated and the GPU driver 109 begins to compile shaders, textures and/or geometric models of the application 108, the GPU driver 109 communicates with the daemon process 110 to obtain shaders, textures and/or geometric models that may be improved and/or optimized in comparison to the shaders, textures and/or geometric models that the GPU driver 109 may compile at runtime and paragraph 30 of Freeman teaches that the animation rigging application 210 retrieves an animated character rigging hierarchy from the animation hierarchy database 242 corresponding to the selected root character. The animation rigging application 210 applies parameters and data corresponding to the selected character body type, character face type, and individual character, as specified by the animated character rigging hierarchy and generates one or more rigged characters 250.)
Regarding claim 12, Freeman in view of Du, Bhat and Dagani disclose everything claimed as applied above (see claim 11), in addition, Freeman in view of Du, Bhat and Dagani disclose wherein the runtime variations are generated by character blending at least two template character shape models with the at least one template character texture model (FIG. 6 and paragraph 79 of Du teach that according to the batch rendering method provided in the embodiment, from the perspective of different merging dimensions, the data information corresponding to the multiple to-be-merged models can be effectively merged in the different merging dimensions through S240 to S270 described below. In addition, paragraph 80 of Du teaches that in S240, multiple model data sets corresponding to the multiple to-be-merged models are acquired, where each of the model data sets includes model mesh data, a texture, and a basic material attribute and paragraph 85 of Du teaches that in S250, data merging is performed in a model mesh dimension according to model mesh data corresponding to each to-be-merged model so that corresponding merged mesh data are obtained.).
Regarding claim 13, Freeman in view of Du, Bhat and Dagani disclose everything claimed as applied above (see claim 11), in addition, Freeman in view of Du, Bhat and Dagani disclose wherein the runtime variations are generated by character blending at least two base character shape models with the at least one base character texture model (FIG. 6 and paragraph 79 of Du teach that according to the batch rendering method provided in the embodiment, from the perspective of different merging dimensions, the data information corresponding to the multiple to-be-merged models can be effectively merged in the different merging dimensions through S240 to S270 described below. In addition, paragraph 80 of Du teaches that in S240, multiple model data sets corresponding to the multiple to-be-merged models are acquired, where each of the model data sets includes model mesh data, a texture, and a basic material attribute and paragraph 120 of Du teaches that in S260, data merging is performed in a texture dimension according to a texture corresponding to each to-be-merged model so that corresponding merged texture data are obtained.).
Regarding claim 14, Freeman in view of Du, Bhat and Dagani disclose everything claimed as applied above (see claim 11), in addition, Freeman in view of Du, Bhat and Dagani disclose wherein the runtime variations are generated by character blending the at least one template character shape model with the at least one base character shape model and with one of the at least one base character texture model or the at least one template character texture model (FIG. 6 and paragraph 79 of Du teach that according to the batch rendering method provided in the embodiment, from the perspective of different merging dimensions, the data information corresponding to the multiple to-be-merged models can be effectively merged in the different merging dimensions through S240 to S270 described below. In addition, paragraph 156 of Du teaches that in S270, data merging is performed in a material attribute dimension according to a basic material attribute corresponding to each to-be-merged model so that corresponding merged material attribute data are obtained.).
Regarding claim 15, Freeman in view of Du, Bhat and Dagani disclose everything claimed as applied above (see claim 11), in addition, Freeman in view of Du, Bhat and Dagani disclose wherein the runtime variations are generated by stylizing at least two template character shape models with the at least one template character texture model (Paragraph 83 of Du teaches that for example, for one model, the corresponding model mesh data may include vertex-related data (for example, vertex attribute data and vertex index offsets), skinned mesh data for representing bone animation, and fusion morphology data for representing expression changes of the role. A model tends to be rendered in units of triangular facets. In other words, the rendering on the model is converted to the rendering on multiple triangular facets. Each triangular facet may be represented by three vertices. Therefore, the vertex-related data may be considered as basic data for model rendering.).
Regarding claim 16, Freeman in view of Du, Bhat and Dagani disclose everything claimed as applied above (see claim 11), in addition, Freeman in view of Du, Bhat and Dagani disclose wherein the runtime variations are generated by stylizing at least two base character shape models with the at least one base character texture model (Paragraph 84 of Du teaches that in the embodiment, the vertex-related data included in the model mesh data may include data such as vertex coordinates, normals, tangents, shades, and vertex indexes; the skinned mesh data may include data such as bone weights, bone indexes, binding postures, and a bone matrix; and the fusion morphology data may include data such as vertex increments, normal increments, and tangent increments. Texture data are image data required for model mapping and also equivalent to one material attribute of the model. Generally, one model may correspond to multiple textures. Basic material attribute data may include data such as color attributes and brightness attributes for a rendering presentation.).
Regarding claim 18, Freeman in view of Du, Bhat and Dagani disclose everything claimed as applied above (see claim 11), in addition, Freeman in view of Du, Bhat and Dagani disclose wherein the at least one attachable is associated with a 3D character other than the template character (Paragraph 43 of Freeman teaches that a heavy version of the character Bob could be created by selecting the human base rig, a human heavy male template rig, and the “Bob” face rig, and so on. If two new character rig are created from exactly the same component rigs, then the two characters would be the same as well. That is, if two new character rigs are created by selecting the human base rig, the human thin male template rig, and an “Adam” face rig, then the two characters would appear to be a thin male named Adam and Adam's identical twin. By using a rigging hierarchy, sufficiently populated with component template rigs and individual character rigs, a crowd of fifty or one hundred individual characters could be created in a fraction of the time needed to create fifty or one hundred custom individualized rigs from scratch.).
Regarding claim 19, Freeman in view of Du, Bhat and Dagani disclose everything claimed as applied above (see claim 11), in addition, Freeman in view of Du, Bhat and Dagani disclose wherein the step of generating the optimized data set further comprises, prior to the converting step: asset fitting the at least one attachable associated with the 3D character to the template character to yield a template-fitted attachable (Paragraph 40 of Freeman teaches that the human face Bob rig 530 is a level 2 template rig for a human with a face type of “Bob”. The human face Bob rig 530 defines a template for a prototypical face for animated characters based on the “Bob” face type. The human face Bob rig 530 includes human face Bob weights 532 and human face Bob fitting 534. The human face Bob weights 532 include weights for the human face Bob rig 530 template. The human face Bob weights 532 also include digital sculpting data that give specific shape to animated characters based on the “Bob” body type.);
and asset fitting the template-fitted attachable to the at least one base character (Paragraph 41 of Freeman teaches that in some embodiments, the human body A Bob rig 540 inherits weight data from the human weights 512 and the human high resolution weights 514 of the human rig 510. In some embodiments, the human body A Bob rig 540 also inherits human body A weights 522 and human body A fitting 524 from the human body A rig 520 and human face Bob weights 532 and human face Bob fitting 534 from the human face Bob B rig 530.).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Freeman in view of Du, Bhat and Dagani, as applied to claim 11 above, and further in view of Vesdapunt.
Regarding claim 17, Freeman in view of Du, Bhat and Dagani disclose everything claimed as applied above (see claim 11), however, Freeman in view of Du, Bhat and Dagani fail to disclose wherein the runtime variations are generated by at least one of: creating character groups, constraining base character models further comprising a base character shape model and a base texture model, constraining the usage of attachables, or constraining the colorization of 3D assets.
Vesdapunt discloses wherein the runtime variations are generated by at least one of: creating character groups, constraining base character models further comprising a base character shape model and a base texture model, constraining the usage of attachables, or constraining the colorization of 3D assets (Paragraph 73 teaches that the process 800 may also include an operation 820 of generating a three-dimensional (3D) model of the face of the human subject based on the 2D image by analyzing the 2D image of the face to produce a coarse 3D model of the face of the human subject, and refining the coarse 3D model through free form deformation to produce a fitted 3D model. The operation 820 may be implemented by the face fitting pipeline 500 illustrated in FIG. 5. Various techniques may be used to produce the coarse 3D model of the face of the human subject included in the 2D image. Some implementations may utilize 3DMM to produce a parametric base model (also referred to herein as a “coarse 3D model”) that provides coarse-scale geometry of the face of the subject. The coarse 3D model may be refined through free-form deformation to generate the fitted 3D model, and an as-rigid-as-possible (ARAP) deformation constraint to regularize the deformation and to prevent the coarse 3D model from deforming into nonsensible shapes.). Additionally, paragraph 40 teaches that the research into 3D face reconstruction may be divided into separate groups based on the input modality (e.g., RGB inputs which include 2D color information or RGB-D inputs which include depth information in addition to the color information), single view or multi-view, optimization-based or learning-based, the face models used, and different constraints being used. Deep learning-based 3D reconstruction approaches have also been developed that either target only for geometry or for both geometry and texture for monocular input. Most of these conventional approaches attempt to boost the reconstruction accuracy by through the addition of prior knowledge, such as by using a parametric face model, or by adding more constraints, such as sparse landmark loss, perception loss, or photometric loss. ReDA follows the latter approach by adding more constraints by adding more discriminating constraints to reduce ambiguities. ReDA utilizes discriminating constraints that go beyond the color constraint used by conventional approaches to 3D face reconstruction such as 3DMM to provide significant improvements in 3D face reconstruction. Implementations of ReDA may utilize depth constraints and a face parsing mask to provide significant improvements in the resulting 3D face model. Other constraints may be used in addition to and/or instead of one or more of these additional constraints to further improve the resulting 3D face model.) Since Freeman in view of Du, Bhat and Dagani teach the initial method steps for generating the runtime variations of optimized data sets for base character models, including their heads, and Vesdapunt teaches the functionality of applying color constraints and additional constraints to a base 3D head model, it would have been obvious to a person having ordinary skill in the art to combine the two features together so that additional constraints could then be applied to the base character head models to help improve the generation of the optimization data sets.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Freeman in view of Du, Bhat and Dagani to incorporate the teachings of Vesdapunt, so that the combined features together would help in improving the optimization of the data sets by incorporating different types of constraints to be implemented with colors and/or the shaping of the different base models.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hesse et al. (U.S. Patent: #11,127,163 B2) teaches a computer-implemented method for automatically obtaining 3D images of a base body model’s pose and shape parameters and contains body templates and data sets involving textures for the body.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to George Renze whose telephone number is (703)756-5811. The examiner can normally be reached Monday-Friday 9:00am - 6:00pm EST.
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, Xiao Wu can be reached at (571) 272-7761. 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.
/G.R./Examiner, Art Unit 2613
/XIAO M WU/Supervisory Patent Examiner, Art Unit 2613
Prosecution Insights