DETAILED ACTION
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
The amendment filed April 10, 2026 has been entered. Claims 1-13 remain pending in the application. Applicant’s amendments to the Claims have overcome each and every objection previously set forth in the Final Office Action mailed January 14, 2026.
Response to Arguments
Applicant’s arguments, see Page 7-9 of Remarks, filed April 10, 2026, with respect to the rejection of claims 1-13 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Bejarano (Assimp - 3D Game Development with LWJGL 3).
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 and 9-12 are rejected under 35 U.S.C. 103 as being unpatentable over Helfgott et al. (US 20230351680 A1) in view of Liu et al. (US 20180330480 A1) and Bejarano (Assimp - 3D Game Development with LWJGL 3), hereinafter Helfgott, Liu, and Bejarano respectively.
Regarding claim 1, Helfgott teaches a method of creating a 3D object performed by at least one processor (Paragraph 0029, 0043 – “providing a system and methods that generate a compressed 3D model that can be stored on a serverless system and provide real time dynamic rendering…The first computing device includes at least one processor configured for performing the steps in method 400”), the method comprising:
obtaining first type data including a file (Paragraph 0043 – “glTF, which includes the .gltf or .glb file extensions, may be used as the file format for the high polygon three-dimensional base model. A glTF (GL Transmission Format) is a standard file format for three-dimensional scenes and models that supports static models, animation, and moving scenes. However, it is understood that other file formats may be used and are withing the spirit and scope of the disclosed invention”; Note: the glTF file is equivalent to the first data type),
and second type data including textures, normal maps, metallic information, and roughness information (Paragraph 0048, 0069 – “Materials are the layers on top of the three low polygon three-dimensional base model. A material controls how a 3D object appears on the screen. This means that most materials will take a texture as a parameter. Materials control the color of the object and how reflective or dull the surface appears. Materials are a set of properties and parameters that define the appearance of a 3D object's surface, such as color, texture, reflectivity, transparency, and roughness. Applying the plurality of materials to the base objects may include accessing a database or materials library. Material libraries typically contain pre-made materials that can be applied to base objects with a single click. These materials may include textures, colors, reflectivity, and other properties that define the appearance of the object…The statistics of the texture data may include values for effects such as albedo, normal, specular/metallic, gloss/roughness, occlusion, emissive, and opacity”; Note: material is equivalent to the second data type) based on an input asset (Paragraph 0068 – “the second computing device combines the plurality of tokens associated with the digital assets acquired by the user. In step 625, if the predetermined threshold number of the plurality of tokens is met, the first computing device modifies the compressed three-dimensional base model based on the plurality of characteristics of the plurality of digital assets acquired by the user. In the present embodiment, the plurality of characteristics may be body style, materials, textures, and other characteristics configured to modify the appearance of the compressed three-dimensional model”; Note: the material is based on the input digital assets);
generating a procedural mesh using a first model based on the first type data (Paragraph 0043 – “the first computing device generates a plurality of base objects. The first computing device then generates a high polygon three-dimensional base model including the plurality of base objects defining a body assembly… glTF, which includes the .gltf or .glb file extensions, may be used as the file format for the high polygon three-dimensional base model…the first computing device decimates the high polygon three-dimensional base model into a low polygon three-dimensional base model”; Note: the low polygon 3D base model is equivalent to the procedural mesh, and the high polygon 3D base model is equivalent to the first model. The high polygon 3D base model is based on the glTF file format, which is the first type data);
and generating a 3D object as an output using a second model based on the procedural mesh generated using the first model (Paragraph 0048, 0060 – “the first computing device applies a plurality of materials to each of the plurality of base objects…the first computing device compresses the low polygon three-dimensional base model into a compressed three-dimensional base model…Referring now to FIGS. 7A and 7B, diagrams illustrating a high polygon three dimensional model 700 and a low polygon three dimensional model 701”; Note: the compressed 3D base model is equivalent to the 3D object and second model. It is created based on the low polygon 3D model, which is the procedural mesh, and the materials, which is the second type data. Screenshot of Fig. 7A and 7B below shows that the outputted 3D model is a 3D object) and based on the asset obtained from the second type data (Paragraph 0068 – “the second computing device combines the plurality of tokens associated with the digital assets acquired by the user. In step 625, if the predetermined threshold number of the plurality of tokens is met, the first computing device modifies the compressed three-dimensional base model based on the plurality of characteristics of the plurality of digital assets acquired by the user. In the present embodiment, the plurality of characteristics may be body style, materials, textures, and other characteristics configured to modify the appearance of the compressed three-dimensional model”; Note: the compressed 3D model is generated based on characteristics/material of input digital assets).
PNG
media_image1.png
587
955
media_image1.png
Greyscale
Screenshot of Fig. 7A and Fig. 7B (taken from Helfgott)
Helfgott does not teach a “filmbox (FBX) file” in the limitation: “obtaining first type data including a filmbox (FBX) file”, nor that the input asset is 3D from the limitation: “second type data including textures, normal maps, metallic information, and roughness information, based on an input 3D asset”. However, Liu teaches obtaining first type data including a filmbox (FBX) file (Paragraph 0096 – “the method may include extracting and storing Building Information Modeling (BIM) information from a Revit file, layer information from an AutoCAD file, selection set and instance data from Filmbox (FBX) file”), and an input 3D asset (Paragraph 0091, 0093, 0096, 0103 – “The method may include receiving an asset through a variety of input options. Input options may include a web dashboard or a downloadable uploader, and may also include a custom interface or program…it is to be understood that receiving a 3D model may include receiving asset data which may be transformed into a 3D model…the method may include extracting and storing Building Information Modeling (BIM) information from a Revit file, layer information from an AutoCAD file, selection set and instance data from Filmbox (FBX) file, textures information, lighting information, or materials information 1050… extracting further useful data 1063 is also partially performed during the scan. For example, the scan may include rendering engines to read out lighting information or may be applied to determine the material of the 3D model”; Note: the 3D asset is received as an input). A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the glTF file of Helfgott could have been substituted for the FBX file of Liu because both the glTF and FBX files serve the purpose of storing 3D modeling data. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution. Finally, the substitution achieves the predictable result of being used to generate a 3D object. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the glTF file of Helfgott for the FBX file of Liu according to known methods to yield the predictable result of generating a 3D object using data from the file. Furthermore, 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 Helfgott to incorporate the teachings of Liu to have the input asset be 3D because the asset represents a physical object that can be modeled in 3D (Helfgott: Paragraph 0066 – “The physical three dimensional model is generated by combining a predetermined number of the plurality of digital assets”), so logically, the digital asset should also be 3D to best represent the object.
Moreover, Helfgott modified by Liu still does not teach that the procedural mesh is generated using the first model by extracting a node hierarchy of the 3D object. However, Bejarano teaches that the procedural mesh is generated using the first model by extracting a node hierarchy of the 3D object (Paragraph 2 on Page 1, Paragraph 2-3 on Page 7, Paragraph 2 on Page 8, Paragraph 1 on Page 10 – “the Assimp library already can be used to parse many common 3D formats…we will use assimp library. This will allow us to load many more formats besides MD5, such as COLLADA, FBX, etc…A joint / bone is are just elements that affect vertices, and that have a parent forming a hierarchy. MD5 format uses the term joint, but assimp uses the term bone…Assimp scene object defines a Node’s hierarchy. Each Node is defined by a name a list of children node. Animations use these nodes to define the transformations that should be applied to. This hierarchy is defined indeed the bones’ hierarchy. Every bone is a node, and has a parent, except the root node, and possible a set of children…The method that actually loads the model just loads the different meshes but it first calculates the node hierarchy and then calls to the processAnimations at the end to build an AnimGameItem instance”; Note: a node hierarchy is calculated/extracted in order to generate a mesh. It is implied that the node hierarchy is of a 3D object since the loaded format is 3D and there is a scene object that defines the node hierarchy. The 3D object is from an FBX file loaded by Assimp, which is the first model in this case). 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 Helfgott to incorporate the teachings of Bejarano to extract a node hierarchy to generate the mesh because not every file format stores the mesh directly, and as a result, obtaining the mesh would require loading and parsing a representation of the mesh, which may be a node hierarchy. A node hierarchy is beneficial for loading efficiency and ease of editing the mesh. Additionally, being able to properly load the model has advantages for a variety of purposes, such as for creating a game, like expressed in Bejarano, “The capability of loading complex 3d models in different formats is crucial in order to write a game” (Bejarano: Paragraph 1 on Page 1).
Regarding claim 9, Helfgott in view of Liu and Bejarano teaches the method of claim 1. Helfgott further teaches delivering the 3D object to a terminal including a program related to a 3D project (Paragraph 0060, 0072 – “the first computing device compresses the low polygon three-dimensional base model into a compressed three-dimensional base model. Because the system allows the user to make changes to the three-dimensional model, the system displays the compressed three-dimensional model on the third computing device. The compressed three-dimensional base model and compressed top down model will allow the user to see the changes in-real time because the system will be able to render the compressed three-dimensional model… Referring now to FIG. 9, a diagram illustrating a graphical user interface configured to display on a third computing device to generate and utilize the three-dimensional model is shown, according to an example embodiment. The graphical user interface may include a variety of user interface/user experience elements configured to allow the user to interact with the graphical user interface”; Note: the 3D object is delivered to the third computing device, which is the terminal. The third computing device has a graphical user interface to show the 3D object, which is equivalent to a program related to the 3D project).
Regarding claim 10, Helfgott in view of Liu and Bejarano teaches the method of claim 9. Helfgott further teaches wherein the program related to the 3D project includes an operation of manipulating the 3D object in the runtime environment (Paragraph 0074 – “Referring now to FIG. 11, a diagram illustrating a graphical user interface configured to display on the third computing device is shown, according to an example embodiment. The graphical user interface allows the user to input selection data by displaying the options for each of the plurality of tokens to choose from…The graphical user interface also displays the updated three-dimensional rendering 1125 of the three-dimensional base model as the user chooses different options… When users are satisfied with their selections and want to finalize their modified three-dimensional base model, those selections are applied”) and an operation of interacting with the 3D object in the runtime environment (Paragraph 0072 – “Referring now to FIG. 9, a diagram illustrating a graphical user interface configured to display on a third computing device to generate and utilize the three-dimensional model is shown, according to an example embodiment. The graphical user interface may include a variety of user interface/user experience elements configured to allow the user to interact with the graphical user interface…The graphical user interface may include interactable elements that may display other graphical user interfaces. The other graphical user interfaces may be configured to allow the user to acquire 905 NFTs, assemble 910 NFTs to generate another NFT, and race 915 their assembled NFTs. Racing 915 is specific to the application such that the three dimensional model and/or token can be utilized in a game or experience”; Note: the user can race with their 3D object in a game).
Regarding claim 11, Helfgott teaches a server (Paragraph 0035 – “server 102”) comprising:
at least one processor (Paragraph 0036 – “Server 102 includes a software engine that delivers applications, data, program code and other information to networked computing devices 110 and 118. The software engine of server 102 may perform other processes such as audio and/or video streaming or other standards for transferring multimedia data in a stream of packets that are interpreted and rendered by a software application as the packets arrive”; Note: it is implied that a processor exists in the server because the software engine would require a processor to run);
and a memory (Paragraph 0037 – “Server 102 also includes program logic comprising computer source code, scripting language code or interpreted language code that is compiled to produce executable file or computer instructions that perform various functions of the present invention”; Note: it is implied that a memory exists in the server because the server could not include program logic without having a memory to store it), wherein the at least one processor is configured to:
obtain first type data including a file (Paragraph 0043 – “glTF, which includes the .gltf or .glb file extensions, may be used as the file format for the high polygon three-dimensional base model. A glTF (GL Transmission Format) is a standard file format for three-dimensional scenes and models that supports static models, animation, and moving scenes. However, it is understood that other file formats may be used and are withing the spirit and scope of the disclosed invention”; Note: the glTF file is equivalent to the first data type),
and second type data including textures, normal maps, metallic information, and roughness information (Paragraph 0048, 0069 – “Materials are the layers on top of the three low polygon three-dimensional base model. A material controls how a 3D object appears on the screen. This means that most materials will take a texture as a parameter. Materials control the color of the object and how reflective or dull the surface appears. Materials are a set of properties and parameters that define the appearance of a 3D object's surface, such as color, texture, reflectivity, transparency, and roughness. Applying the plurality of materials to the base objects may include accessing a database or materials library. Material libraries typically contain pre-made materials that can be applied to base objects with a single click. These materials may include textures, colors, reflectivity, and other properties that define the appearance of the object…The statistics of the texture data may include values for effects such as albedo, normal, specular/metallic, gloss/roughness, occlusion, emissive, and opacity”; Note: material is equivalent to the second data type) based on an input asset (Paragraph 0068 – “the second computing device combines the plurality of tokens associated with the digital assets acquired by the user. In step 625, if the predetermined threshold number of the plurality of tokens is met, the first computing device modifies the compressed three-dimensional base model based on the plurality of characteristics of the plurality of digital assets acquired by the user. In the present embodiment, the plurality of characteristics may be body style, materials, textures, and other characteristics configured to modify the appearance of the compressed three-dimensional model”; Note: the material is based on the input digital assets);
generate a procedural mesh using a first model based on the first type data (Paragraph 0043 – “the first computing device generates a plurality of base objects. The first computing device then generates a high polygon three-dimensional base model including the plurality of base objects defining a body assembly… glTF, which includes the .gltf or .glb file extensions, may be used as the file format for the high polygon three-dimensional base model…the first computing device decimates the high polygon three-dimensional base model into a low polygon three-dimensional base model”; Note: the low polygon 3D base model is equivalent to the procedural mesh, and the high polygon 3D base model is equivalent to the first model. The high polygon 3D base model is based on the glTF file format, which is the first type data);
and generate a 3D object as an output using a second model based on the procedural mesh generated using the first model (Paragraph 0048, 0060 – “the first computing device applies a plurality of materials to each of the plurality of base objects…the first computing device compresses the low polygon three-dimensional base model into a compressed three-dimensional base model…Referring now to FIGS. 7A and 7B, diagrams illustrating a high polygon three dimensional model 700 and a low polygon three dimensional model 701”; Note: the compressed 3D base model is equivalent to the 3D object and second model. It is created based on the low polygon 3D model, which is the procedural mesh, and the materials, which is the second type data. Screenshot of Fig. 7A and 7B above shows that the outputted 3D model is a 3D object) and based on the asset obtained from the second type data (Paragraph 0068 – “the second computing device combines the plurality of tokens associated with the digital assets acquired by the user. In step 625, if the predetermined threshold number of the plurality of tokens is met, the first computing device modifies the compressed three-dimensional base model based on the plurality of characteristics of the plurality of digital assets acquired by the user. In the present embodiment, the plurality of characteristics may be body style, materials, textures, and other characteristics configured to modify the appearance of the compressed three-dimensional model”; Note: the compressed 3D model is generated based on characteristics/material of input digital assets).
While Helfgott states that the operations are performed by the first computing device, Helfgott also clarifies in paragraph 0037 that “Server 102 also includes program logic comprising computer source code, scripting language code or interpreted language code that is compiled to produce executable file or computer instructions that perform various functions of the present invention”, meaning that the server can also perform the operations and then send the resulting data over to the computing devices (Paragraph 0036 – “Server 102 includes a software engine that delivers applications, data, program code and other information to networked computing devices 110 and 118”).
Helfgott does not teach a “filmbox (FBX) file” in the limitation: “obtaining first type data including a filmbox (FBX) file”, nor that the input asset is 3D from the limitation: “second type data including textures, normal maps, metallic information, and roughness information, based on an input 3D asset”. However, Liu teaches obtaining first type data including a filmbox (FBX) file (Paragraph 0096 – “the method may include extracting and storing Building Information Modeling (BIM) information from a Revit file, layer information from an AutoCAD file, selection set and instance data from Filmbox (FBX) file”), and an input 3D asset (Paragraph 0091, 0093, 0096, 0103 – “The method may include receiving an asset through a variety of input options. Input options may include a web dashboard or a downloadable uploader, and may also include a custom interface or program…it is to be understood that receiving a 3D model may include receiving asset data which may be transformed into a 3D model…the method may include extracting and storing Building Information Modeling (BIM) information from a Revit file, layer information from an AutoCAD file, selection set and instance data from Filmbox (FBX) file, textures information, lighting information, or materials information 1050… extracting further useful data 1063 is also partially performed during the scan. For example, the scan may include rendering engines to read out lighting information or may be applied to determine the material of the 3D model”; Note: the 3D asset is received as an input). A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the glTF file of Helfgott could have been substituted for the FBX file of Liu because both the glTF and FBX files serve the purpose of storing 3D modeling data. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution. Finally, the substitution achieves the predictable result of being used to generate a 3D object. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the glTF file of Helfgott for the FBX file of Liu according to known methods to yield the predictable result of generating a 3D object using data from the file. Furthermore, 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 Helfgott to incorporate the teachings of Liu to have the input asset be 3D because the asset represents a physical object that can be modeled in 3D (Helfgott: Paragraph 0066 – “The physical three dimensional model is generated by combining a predetermined number of the plurality of digital assets”), so logically, the digital asset should also be 3D to best represent the object.
Moreover, Helfgott modified by Liu still does not teach that the procedural mesh is generated using the first model by extracting a node hierarchy of the 3D object. However, Bejarano teaches that the procedural mesh is generated using the first model by extracting a node hierarchy of the 3D object (Paragraph 2 on Page 1, Paragraph 2-3 on Page 7, Paragraph 2 on Page 8, Paragraph 1 on Page 10 – “the Assimp library already can be used to parse many common 3D formats…we will use assimp library. This will allow us to load many more formats besides MD5, such as COLLADA, FBX, etc…A joint / bone is are just elements that affect vertices, and that have a parent forming a hierarchy. MD5 format uses the term joint, but assimp uses the term bone…Assimp scene object defines a Node’s hierarchy. Each Node is defined by a name a list of children node. Animations use these nodes to define the transformations that should be applied to. This hierarchy is defined indeed the bones’ hierarchy. Every bone is a node, and has a parent, except the root node, and possible a set of children…The method that actually loads the model just loads the different meshes but it first calculates the node hierarchy and then calls to the processAnimations at the end to build an AnimGameItem instance”; Note: a node hierarchy is calculated/extracted in order to generate a mesh. It is implied that the node hierarchy is of a 3D object since the loaded format is 3D and there is a scene object that defines the node hierarchy. The 3D object is from an FBX file loaded by Assimp, which is the first model in this case). 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 Helfgott to incorporate the teachings of Bejarano to extract a node hierarchy to generate the mesh because not every file format stores the mesh directly, and as a result, obtaining the mesh would require loading and parsing a representation of the mesh, which may be a node hierarchy. A node hierarchy is beneficial for loading efficiency and ease of editing the mesh. Additionally, being able to properly load the model has advantages for a variety of purposes, such as for creating a game, like expressed in Bejarano, “The capability of loading complex 3d models in different formats is crucial in order to write a game” (Bejarano: Paragraph 1 on Page 1).
Regarding claim 12, Helfgott teaches a non-transitory computer-readable storage medium storing a computer program configured to be executed by at least one processor (Paragraph 0078, 0080 – “System memory 1204, removable storage 1209, and non-removable storage 1210 are all computer storage media examples (i.e., memory storage.) Computer storage media may include, but is not limited to, RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store information and which can be accessed by computing device 1200…a number of program modules and data files may be stored in system memory 1204, including operating system 1205. While executing on processing unit 1202, programming modules 1206 (e.g., program module 1207) may perform processes”; Note: DVD is a type of non-transitory computer-readable storage medium) and cause the at least one processor to perform operations to generate a 3D object (Paragraph 0043, 0080 – “a method 400 of creating and sending a compressed three-dimensional base model…While executing on processing unit 1202, programming modules 1206 (e.g., program module 1207) may perform processes including, for example, one or more of the stages of the methods 400, 500, 600 as described above”), the operations comprising:
obtaining first type data including a file (Paragraph 0043 – “glTF, which includes the .gltf or .glb file extensions, may be used as the file format for the high polygon three-dimensional base model. A glTF (GL Transmission Format) is a standard file format for three-dimensional scenes and models that supports static models, animation, and moving scenes. However, it is understood that other file formats may be used and are withing the spirit and scope of the disclosed invention”; Note: the glTF file is equivalent to the first data type),
and second type data including textures, normal maps, metallic information, and roughness information (Paragraph 0048, 0069 – “Materials are the layers on top of the three low polygon three-dimensional base model. A material controls how a 3D object appears on the screen. This means that most materials will take a texture as a parameter. Materials control the color of the object and how reflective or dull the surface appears. Materials are a set of properties and parameters that define the appearance of a 3D object's surface, such as color, texture, reflectivity, transparency, and roughness. Applying the plurality of materials to the base objects may include accessing a database or materials library. Material libraries typically contain pre-made materials that can be applied to base objects with a single click. These materials may include textures, colors, reflectivity, and other properties that define the appearance of the object…The statistics of the texture data may include values for effects such as albedo, normal, specular/metallic, gloss/roughness, occlusion, emissive, and opacity”; Note: material is equivalent to the second data type) based on an input asset (Paragraph 0068 – “the second computing device combines the plurality of tokens associated with the digital assets acquired by the user. In step 625, if the predetermined threshold number of the plurality of tokens is met, the first computing device modifies the compressed three-dimensional base model based on the plurality of characteristics of the plurality of digital assets acquired by the user. In the present embodiment, the plurality of characteristics may be body style, materials, textures, and other characteristics configured to modify the appearance of the compressed three-dimensional model”; Note: the material is based on the input digital assets);
generating a procedural mesh using a first model based on the first type data (Paragraph 0043 – “the first computing device generates a plurality of base objects. The first computing device then generates a high polygon three-dimensional base model including the plurality of base objects defining a body assembly… glTF, which includes the .gltf or .glb file extensions, may be used as the file format for the high polygon three-dimensional base model…the first computing device decimates the high polygon three-dimensional base model into a low polygon three-dimensional base model”; Note: the low polygon 3D base model is equivalent to the procedural mesh, and the high polygon 3D base model is equivalent to the first model. The high polygon 3D base model is based on the glTF file format, which is the first type data);
and generating a 3D object as an output using a second model based on the procedural mesh generated using the first model (Paragraph 0048, 0060 – “the first computing device applies a plurality of materials to each of the plurality of base objects…the first computing device compresses the low polygon three-dimensional base model into a compressed three-dimensional base model…Referring now to FIGS. 7A and 7B, diagrams illustrating a high polygon three dimensional model 700 and a low polygon three dimensional model 701”; Note: the compressed 3D base model is equivalent to the 3D object and second model. It is created based on the low polygon 3D model, which is the procedural mesh, and the materials, which is the second type data. Screenshot of Fig. 7A and 7B above shows that the outputted 3D model is a 3D object) and based on the asset obtained from the second type data (Paragraph 0068 – “the second computing device combines the plurality of tokens associated with the digital assets acquired by the user. In step 625, if the predetermined threshold number of the plurality of tokens is met, the first computing device modifies the compressed three-dimensional base model based on the plurality of characteristics of the plurality of digital assets acquired by the user. In the present embodiment, the plurality of characteristics may be body style, materials, textures, and other characteristics configured to modify the appearance of the compressed three-dimensional model”; Note: the compressed 3D model is generated based on characteristics/material of input digital assets).
Helfgott does not teach a “filmbox (FBX) file” in the limitation: “obtaining first type data including a filmbox (FBX) file”, nor that the input asset is 3D from the limitation: “second type data including textures, normal maps, metallic information, and roughness information, based on an input 3D asset”. However, Liu teaches obtaining first type data including a filmbox (FBX) file (Paragraph 0096 – “the method may include extracting and storing Building Information Modeling (BIM) information from a Revit file, layer information from an AutoCAD file, selection set and instance data from Filmbox (FBX) file”), and an input 3D asset (Paragraph 0091, 0093, 0096, 0103 – “The method may include receiving an asset through a variety of input options. Input options may include a web dashboard or a downloadable uploader, and may also include a custom interface or program…it is to be understood that receiving a 3D model may include receiving asset data which may be transformed into a 3D model…the method may include extracting and storing Building Information Modeling (BIM) information from a Revit file, layer information from an AutoCAD file, selection set and instance data from Filmbox (FBX) file, textures information, lighting information, or materials information 1050… extracting further useful data 1063 is also partially performed during the scan. For example, the scan may include rendering engines to read out lighting information or may be applied to determine the material of the 3D model”; Note: the 3D asset is received as an input). A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the glTF file of Helfgott could have been substituted for the FBX file of Liu because both the glTF and FBX files serve the purpose of storing 3D modeling data. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution. Finally, the substitution achieves the predictable result of being used to generate a 3D object. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the glTF file of Helfgott for the FBX file of Liu according to known methods to yield the predictable result of generating a 3D object using data from the file. Furthermore, 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 Helfgott to incorporate the teachings of Liu to have the input asset be 3D because the asset represents a physical object that can be modeled in 3D (Helfgott: Paragraph 0066 – “The physical three dimensional model is generated by combining a predetermined number of the plurality of digital assets”), so logically, the digital asset should also be 3D to best represent the object.
Moreover, Helfgott modified by Liu still does not teach generating a 3D object by extracting a node hierarchy of the 3D object. However, Bejarano teaches generating a 3D object by extracting a node hierarchy of the 3D object (Paragraph 2 on Page 1, Paragraph 2-3 on Page 7, Paragraph 2 on Page 8, Paragraph 1 on Page 10 – “the Assimp library already can be used to parse many common 3D formats…we will use assimp library. This will allow us to load many more formats besides MD5, such as COLLADA, FBX, etc…A joint / bone is are just elements that affect vertices, and that have a parent forming a hierarchy. MD5 format uses the term joint, but assimp uses the term bone…Assimp scene object defines a Node’s hierarchy. Each Node is defined by a name a list of children node. Animations use these nodes to define the transformations that should be applied to. This hierarchy is defined indeed the bones’ hierarchy. Every bone is a node, and has a parent, except the root node, and possible a set of children…The method that actually loads the model just loads the different meshes but it first calculates the node hierarchy and then calls to the processAnimations at the end to build an AnimGameItem instance”; Note: a node hierarchy is calculated/extracted in order to generate a mesh of the object. It is implied that the node hierarchy is of a 3D object since the loaded format is 3D and there is a scene object that defines the node hierarchy). 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 Helfgott to incorporate the teachings of Bejarano to extract a node hierarchy to generate the 3D object mesh because not every file format stores the object directly, and as a result, obtaining the object would require loading and parsing a representation of the mesh, which may be a node hierarchy. A node hierarchy is beneficial for loading efficiency and ease of editing the mesh. Additionally, being able to properly load the model has advantages for a variety of purposes, such as for creating a game, like expressed in Bejarano, “The capability of loading complex 3d models in different formats is crucial in order to write a game” (Bejarano: Paragraph 1 on Page 1).
Claims 2-4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Helfgott in view of Liu, Bejarano, and Li et al. (CN 116468860 A), hereinafter Li.
Regarding claim 2, Helfgott in view of Liu and Bejarano teaches the method of claim 1. Helfgott does not teach wherein the input 3D asset includes a 3D asset that has been decrypted from an encrypted 3D asset, and wherein the decrypted 3D asset is generated based on an operation of obtaining the encrypted 3D asset from a marketplace and an operation of decrypting the encrypted 3D asset by a client using a secret key. However, Li teaches wherein the input 3D asset includes a 3D asset that has been decrypted from an encrypted 3D asset (Paragraph n0044, 0092-0093 – “after obtaining the 3D model file, the method further includes step S6: trading the 3D model file, specifically including: S61: The seller submits the target 3D model file, transaction content, and the private key that encrypted the target 3D model file, and the buyer submits the transaction currency and his own public key; S62: Decrypt the target 3D model file using the private key of the target 3D model file provided by the seller”; Note: the 3d model file is the 3D asset), and wherein the decrypted 3D asset is generated based on an operation of obtaining the encrypted 3D asset from a marketplace and an operation of decrypting the encrypted 3D asset by a client using a secret key (Paragraph n0044, 0092-0093 – “after obtaining the 3D model file, the method further includes step S6: trading the 3D model file, specifically including: S61: The seller submits the target 3D model file, transaction content, and the private key that encrypted the target 3D model file, and the buyer submits the transaction currency and his own public key; S62: Decrypt the target 3D model file using the private key of the target 3D model file provided by the seller”; Note: the 3d model file is the 3D asset. Since trading occurs, it is implied that there is a marketplace to sell, buy, or trade the 3D asset. The private key is equivalent to the secret key). 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 Helfgott to incorporate the teachings of Li to have a decrypted 3D asset that was previously encrypted because encryption assists in securing the item so that it cannot be directly accessed, and decryption allows for those with designated ownership to access the data, which is useful for security and privacy purposes. It also would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Helfgott to incorporate the teachings of Li to obtain the encrypted 3D asset from a marketplace and decrypt it with a secret key for the benefit of having a secure way to buy and sell 3D assets and having a way to verify ownership of the item.
Regarding claim 3, Helfgott in view of Liu, Bejarano, and Li teaches the method of claim 2. Helfgott does not teach wherein the marketplace includes the encrypted 3D asset, and wherein the encrypted 3D asset includes: the operation of obtaining the input 3D asset from a 3D modeler; and the operation of generating the encrypted 3D asset using a public key based on the input 3D asset. However, Li teaches wherein the marketplace includes the encrypted 3D asset (Paragraph n0044, 0092 – “after obtaining the 3D model file, the method further includes step S6: trading the 3D model file, specifically including: S61: The seller submits the target 3D model file, transaction content, and the private key that encrypted the target 3D model file”; Note: considering that the seller submits the 3D model file, it is implied that the marketplace includes the encrypted 3D asset), and wherein the encrypted 3D asset includes: the operation of obtaining the input 3D asset from a 3D modeler (Paragraph n0042, 0084 – “a method for generating a three-dimensional model file includes the following steps: S1: Obtain the equity information, asset information, and annotation information of the target 3D model”; Note: Li does not explicitly state that the 3D asset comes from a 3D modeler, but because the 3D asset consists of a 3D model, it would be obvious to a person of ordinary skill in the art that a 3D model would come from a 3D modeler); and the operation of generating the encrypted 3D asset using a public key based on the input 3D asset (Paragraph n0042, 0085 – “a method for generating a three-dimensional model file includes the following steps: …Encrypt the asset information and annotation information using an encryption public key”). 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 Helfgott to incorporate the teachings of Li to have the marketplace include the encrypted 3D asset for the benefit of selling or trading the item on the marketplace. Additionally, having it be encrypted makes the transaction more secure. It also would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Helfgott to incorporate the teachings of Li to obtain the 3D asset from a 3D modeler because if the 3D asset is a 3D model or a 3D model file, most of its data would likely come from the 3D modeling software that it was created with, so logically, the 3D asset should come from a 3D modeler. Lastly, 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 Helfgott to incorporate the teachings of Li to encrypt the 3D asset because encryption assists in securing the item so that it cannot be directly accessed, which is useful for security and privacy purposes.
Regarding claim 4, Helfgott in view of Liu, Bejarano, and Li teaches the method of claim 3. Helfgott does not teach wherein the operation of generating the encrypted 3D asset using a public key based on the input 3D asset includes generating a 3D asset encrypted with an RSA encryption algorithm using a public key based on the input 3D asset, and wherein the operation of decrypting the encrypted 3D asset by the client using the secret key includes generating a 3D asset decrypted with an RSA decryption algorithm using a secret key based on the encrypted 3D asset. However, Li teaches generating a 3D asset encrypted with an RSA encryption algorithm using a public key based on the input 3D asset (Paragraph 0085, n0050 – “Encrypt the asset information and annotation information using an encryption public key… Use the RSA algorithm to encrypt the model's asset information and annotation information, and store the RSA public key in the first part of the information”), and generating a 3D asset decrypted with an RSA decryption algorithm (Paragraph 0017, n0011 – “Generate an RSA key pair:…Decrypt data: Use the parameter d in the private key to decrypt the ciphertext c to obtain the plaintext m. The formula is: m = c^d mod n.”) using a secret key based on the encrypted 3D asset (Paragraph 0093 – “Decrypt the target 3D model file using the private key of the target 3D model file provided by the seller”; Note: the private key is equivalent to the secret key). 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 Helfgott to incorporate the teachings of Li to use RSA to encrypt and decrypt the 3D asset for the benefit of having a secure way to buy and sell 3D assets and having a way to verify ownership of the item. RSA is a quick and commonly used algorithm, making it easy to use on most systems.
Regarding claim 13, Helfgott in view of Liu and Bejarano teaches the computer program of claim 12. Helfgott does not teach wherein the input 3D asset includes a 3D asset that has been decrypted from an encrypted 3D asset, and wherein the decrypted 3D asset is generated based on an operation of obtaining the encrypted 3D asset from a marketplace and an operation of decrypting the encrypted 3D asset by a client using a secret key. However, Li teaches wherein the input 3D asset includes a 3D asset that has been decrypted from an encrypted 3D asset (Paragraph n0044, 0092-0093 – “after obtaining the 3D model file, the method further includes step S6: trading the 3D model file, specifically including: S61: The seller submits the target 3D model file, transaction content, and the private key that encrypted the target 3D model file, and the buyer submits the transaction currency and his own public key; S62: Decrypt the target 3D model file using the private key of the target 3D model file provided by the seller”; Note: the 3d model file is the 3D asset), and wherein the decrypted 3D asset is generated based on an operation of obtaining the encrypted 3D asset from a marketplace and an operation of decrypting the encrypted 3D asset by a client using a secret key (Paragraph n0044, 0092-0093 – “after obtaining the 3D model file, the method further includes step S6: trading the 3D model file, specifically including: S61: The seller submits the target 3D model file, transaction content, and the private key that encrypted the target 3D model file, and the buyer submits the transaction currency and his own public key; S62: Decrypt the target 3D model file using the private key of the target 3D model file provided by the seller”; Note: the 3d model file is the 3D asset. Since trading occurs, it is implied that there is a marketplace to sell, buy, or trade the 3D asset. The private key is equivalent to the secret key). 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 Helfgott to incorporate the teachings of Li to have a decrypted 3D asset that was previously encrypted because encryption assists in securing the item so that it cannot be directly accessed, and decryption allows for those with designated ownership to access the data, which is useful for security and privacy purposes. It also would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Helfgott to incorporate the teachings of Li to obtain the encrypted 3D asset from a marketplace and decrypt it with a secret key for the benefit of having a secure way to buy and sell 3D assets and having a way to verify ownership of the item.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Helfgott in view of Liu, Bejarano, and Smith et al. (US 10198860 B1), hereinafter Smith.
Regarding claim 5, Helfgott in view of Liu and Bejarano teaches the method of claim 1. Helfgott further teaches obtaining a procedural texture (Paragraph 0051 – “the first computing device generates a plurality of textures”). Helfgott does not teach wherein the generating of the procedural mesh using the first model based on the first type data comprises: extracting a node hierarchy of the 3D object from the FBX file using the first model; obtaining a transformation matrix based on the node hierarchy; obtaining, based on the transformation matrix, a procedural coordinate system; and generating, based on the procedural coordinate system and the procedural texture, the procedural mesh. However, Bejarano teaches extracting a node hierarchy of the object from the FBX file (Paragraph 2 on Page 1, Paragraph 2-3 on Page 7, Paragraph 2 on Page 8, Paragraph 1 on Page 10 – “the Assimp library already can be used to parse many common 3D formats…we will use assimp library. This will allow us to load many more formats besides MD5, such as COLLADA, FBX, etc…A joint / bone is are just elements that affect vertices, and that have a parent forming a hierarchy. MD5 format uses the term joint, but assimp uses the term bone…Assimp scene object defines a Node’s hierarchy. Each Node is defined by a name a list of children node. Animations use these nodes to define the transformations that should be applied to. This hierarchy is defined indeed the bones’ hierarchy. Every bone is a node, and has a parent, except the root node, and possible a set of children…The method that actually loads the model just loads the different meshes but it first calculates the node hierarchy and then calls to the processAnimations at the end to build an AnimGameItem instance”; Note: a node hierarchy is calculated/extracted in order to generate a mesh. It is implied that the node hierarchy is of a 3D object since the loaded format is 3D and there is a scene object that defines the node hierarchy. The 3D object is from an FBX file loaded by Assimp, which is the first model in this case); obtaining a transformation matrix based on the node hierarchy (Paragraph 1 on Page 9 – “Construct the transformation matrices for all the frames. The transformation m matrix is the composition of the translation. rotation and scale matrix…Construct the final transformations to be applied for each bone in the Mesh. This is achieved by multiplying the transformation matrix of the bone (of the associated node) by the transformation matrices of all the parent nodes up to the root node”); obtaining, based on the transformation matrix, a procedural coordinate system (Paragraph 4-5 on Page 6, Paragraph 1 and 3-4 on Page 7 – “the VAO associated to a mesh contains the vertices positions, the texture coordinates, the indices and a list of weights that should be applied to joint positions to modulate final vertex position… Each vertex position has associated a list of four weights that change the final position, referring the bones indices that will be combined to determine its final position. Each frame a list of transformation matrices are loaded, as uniforms, for each joint. With that information the final position is calculated…A joint / bone is are just elements that affect vertices, and that have a parent forming a hierarchy. MD5 format uses the term joint, but assimp uses the term bone… For each Mesh, we can access the vertices positions, texture coordinates and indices. Meshes store also a list of bones”; Note: the transformation matrix is used to obtain final vertex positions. The calculations of the vertex positions would make it obvious to one of ordinary skill in the art that a procedural coordinate system is obtained because the vertex positions are generated using an algorithm and are represented by coordinates). 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 Helfgott to incorporate the teachings of Bejarano to extract a node hierarchy, transformation matrix, and coordinate system for the benefit of determining the structure and position information of the object, which is necessary for building a model that accurately reflects the information. Additionally, because the object comes from a file, directly loading the model of it may not be possible in some cases and may require extracting and organizing the data first. Having that data and being able to properly load the model is beneficial for a variety of purposes, such as for creating a game, like expressed in Bejarano, “The capability of loading complex 3d models in different formats is crucial in order to write a game” (Bejarano: Paragraph 1 on Page 1). Furthermore, Helfgott modified by Bejarano still does not teach generating, based on the procedural coordinate system and the procedural texture, the procedural mesh. However, Smith teaches generating, based on the procedural coordinate system and the procedural texture, the procedural mesh (Col. 14 lines 58-67, Col. 15 lines 1-3, 10-15, 23-25 – “Using the barycentric coordinates of each of meshes 212A and 214, computing device can determine a transformation matrix TM2 to scale, translate and/or rotate texture island UVI associated with the as-built mesh 214 to most closely match corresponding island CI associated with the as-designed mesh 212A, where TM2 is selected to transform locations of correspondence points specified using barycentric coordinates associated with as-built mesh 214 to locations of correspondence points specified using barycentric coordinates associated with as-designed mesh 212A…computing device 200 can fit projected texture island 536 onto ABM Faces 822 using transformation matrix TM2 generated for correspondence points #1, #3, #5, and #7, as specified in terms of barycentric coordinates. Then, a set of textured ABM Faces 940 is generated by projecting and fitting texture island 536 onto ABM Faces 822,…At block 450 of method 400 illustrated in FIG. 4, computing device 200 generates one or more outputs related to as-built mesh 214”; Note: the coordinate system from the transformation matrix and the texture are used to generate a mesh). 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 Helfgott to incorporate the teachings of Smith to generate a procedural mesh based on a procedural coordinate system and texture because textures make the appearance of the model more realistic, and coordinate systems help properly place the texture onto the mesh. So, using the coordinate system and texture would help create a final mesh that is accurate, visually appealing, and not distorted.
Claims 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over Helfgott in view of Liu, Bejarano, Smith, and Autodesk (Autodesk 1: FBX Nodes, Autodesk 2: FBX Help for SDX), hereinafter Autodesk.
Regarding claim 6, Helfgott in view of Liu, Bejarano, and Smith teaches the method of claim 5. Helfgott does not teach wherein the FBX file includes header data, take data, animation curve data, FBX meshes, and FBX textures. However, Autodesk teaches wherein the FBX file includes header data (Autodesk 2: Page 1 – See modified screenshot 1 below, showing that FBX files come with header data), take data (Autodesk 2: Paragraph 3 on Page 3 – “You can interact with the scene by changing a camera’s position, hiding or displaying grid marks, switching between multiple cameras, switching between multiple takes of animation, etc.”; Note: it is implied that the FBX file contains data on takes of animation because in order to view or interact with them, it must exist on the file), animation curve data (Autodesk 2: Page 4 – “The FBX SDK lets you access, create, or modify the following elements of a scene:…Animation curves” ; Note: it is implied that the FBX file contains data on animation curves because in order to view or interact with them, it must exist on the file), FBX meshes (Autodesk 2: Paragraph 1 on Page 2 – “FBX files store data about cameras, lights, meshes, NURBS, and the other elements of a 3D scene”), and FBX textures (Autodesk 2: Page 4 – “The FBX SDK lets you access, create, or modify the following elements of a scene:… Texture mapping over a geometry” ; Note: it is implied that the FBX file contains data on textures because in order to view or interact with them, it must exist on the file).
PNG
media_image2.png
287
667
media_image2.png
Greyscale
Modified screenshot (taken from Autodesk 2)
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 Helfgott to incorporate the teachings of Autodesk to have the FBX file include header data, take data, animation curve data, meshes, and textures because FBX files are meant to store 3D modeling and animation data. A 3D model or animation would not be able to be generated without the necessary data, which includes take data, animation curve data, meshes, and textures. Concerning the header data, most files contain header data, so it would be expected that the FBX file also has header data.
Regarding claim 7, Helfgott in view of Liu, Bejarano, Smith, and Autodesk teaches the method of claim 6. Helfgott further teaches wherein the generating a 3D object using a second model based on the procedural mesh and the second type data comprises: generating a 3D object using the second model based on the procedural mesh and the second type data (Paragraph 0048, 0060 – “the first computing device applies a plurality of materials to each of the plurality of base objects…the first computing device compresses the low polygon three-dimensional base model into a compressed three-dimensional base model…Referring now to FIGS. 7A and 7B, diagrams illustrating a high polygon three dimensional model 700 and a low polygon three dimensional model 701”; Note: the compressed 3D base model is equivalent to the 3D object and second model. It is created based on the low polygon 3D model, which is the procedural mesh, and the materials, which is the second type data. Fig. 7A and 7B above shows that the 3D model is a 3D object); and adjusting shadows and light sources of the 3D object (Paragraph 0050 – “the first computing device also applies a plurality of shaders to at least one of the plurality of materials. Shaders modify how the low polygon three-dimensional base model is displayed. Shaders are small programs or scripts that run on the GPU (Graphics Processing Unit), such as the GPU (1203 in FIG. 12) in the exemplary embodiment of a computing device, to perform various calculations and operations related to rendering a 3D object. They determine how an object's surface reacts to lighting, shadows, reflections, refractions, and other visual properties”; Note: shaders are used to adjust shadows and light of the 3D object).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Helfgott in view of Liu, Bejarano, and Jiang et al. (Pavilion: Bridging Photo-Realism and Robotics), hereinafter Jiang.
Regarding claim 8, Helfgott in view of Liu and Bejarano teaches the method of claim 1. Helfgott does not teach wherein the first model includes Assimp, and wherein the second model includes Unreal Engine. However, Jiang teaches wherein the first model includes Assimp (Fig. 4, Paragraph 6 in 2nd Col. of Page 4 – “we used the open-source library Open Asset Import Library (assimp) to directly read in the model information (vertices, edges, texture coordinates and textures) at runtime”; Note: see screenshot of Fig. 4 below to see how Assimp and Unreal are used to create a 3D object), and wherein the second model includes Unreal Engine (Fig. 4, Paragraph 6 in 2nd Col. of Page 4, Paragraph 1 in 1st Col. of Page 5 – “we used the open-source library Open Asset Import Library (assimp) to directly read in the model information (vertices, edges, texture coordinates and textures) at runtime, and render them using Unreal’s procedural mesh component”; Note: see screenshot of Fig. 4 below to see how Assimp and Unreal are used to create a 3D object).
PNG
media_image3.png
376
630
media_image3.png
Greyscale
Screenshot of Fig. 4 (taken from Jiang)
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 Helfgott to incorporate the teachings of Jiang to have the first model be Assimp because Assimp is a useful tool that allows 3D modeling files to be imported into programming code, where 3D models can be processed and modified as needed. Additionally, it can support a wide variety of file types, including FBX and glTF. It also would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Helfgott to incorporate the teachings of Jiang to have the second model be Unreal Engine because a game engine would allow the user to interact with the 3D object in a game, and Unreal specifically is beneficial for ensuring that rendering the 3D object will produce high quality results for the user.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. De Vries (Assimp - LearnOpenGL) teaches how Assimp loads models into data structures. Jiang et al. (US 20260087739 A1) teaches a method of reconstructing a mesh from a node tree graph generated based on 3D scan data. Platt et al. (US 20230128878 A1) teaches a method of generating a mesh comprising a mesh file and texture file based on a captured 3D scan file.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHELLE HAU MA whose telephone number is (571)272-2187. The examiner can normally be reached M-Th 7-5:30.
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, King Poon can be reached at (571) 270-0728. 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.
/MICHELLE HAU MA/Examiner, Art Unit 2617 /KING Y POON/Supervisory Patent Examiner, Art Unit 2617
Prosecution Insights