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 .
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.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/06/2025, 02/26/2025, and 03/04/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claim 21 is objected to because of the following informalities:
Claim 21 line recites “two or more intermediate files”, which should be “two or more text-based intermediate files.”
.Appropriate correction is required.
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.
Claim 30 is 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.
The term “frequently” in claim 30 is a relative term which renders the claim indefinite. The term “frequently” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. The word ‘frequently’ has plan meaning of “something happens often, repeatedly, or at short, regular intervals. It indicates a consistent pattern, habit, or routine” as defined by dictionary. However, the claim is indefinite since one of ordinary skill in the art cannot translate the definition into a meaningful precise claim scope to interpret the metes and bounds of the term ‘frequently’.
Claim 30 will be interpreted and rejected as best understood by the examiner.
Claim Rejections - 35 USC § 103
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 14, 16, 17-19, 20-23, 25-26, and 31-33 are rejected under 35 U.S.C. 103 as being unpatentable over Richebourg et al. (US 20140184606 A1; IDS REF) (herein after Richebourg) in view of A. Quint ("Scalable vector graphics," in IEEE MultiMedia, vol. 10, no. 3, pp. 99-102, July-Sept. 2003, doi: 10.1109/MMUL.2003.1218261.; IDS REF) (hereinafter Quint).
Regarding claim 14, Richebourg discloses a system for rendering images for display, the system comprising: one or more processors; and
one or more storage devices storing instructions that, when executed by the one or more processors, cause the one or more processors to: (para. [0004], "A set of tools, in the form of a software developers kit (SDK) for a graphics rendering system, is provided to improve overall graphics operations. In general, the tools are directed to analyzing a scene tree and optimizing its presentation to one or more graphics processing units (GPUs) so as to improve rendering operations. This overall goal is provided through a number of different capabilities, each of which is presented to software developers through a new applications programming interface (API)."; para. [0020], "A typical GPU is typically a Single Instruction Multiple Data (SIMD) device in which each instruction may operate on multiple pieces of data in parallel. Just as CPUs have developed from single processing units to multiple core processor that can execute instructions separately in each core, more recent GPUs provide “lanes” of vector computation, each of which can be interpreted as a separate thread. A single hardware sequencer typically operates on a group of such threads in parallel. If all execute the same instruction, they are said to be coherent."; para. [0087], "As shown in FIG. 12, the computer system 1200, which is a form of a data processing system, includes a bus 1222 which is coupled to a microprocessor(s) 1216, which may be CPUs and/or GPUs, a memory 1212, which may include one or both of a volatile read/write random access memory (RAM) and a read-only memory (ROM), and a non-volatile storage device 1214. The microprocessor(s) 1216 may retrieve instructions from the memory 1212 and the storage device 1214 and execute the instructions using cache 1218 to perform operations described above. The bus 1222 interconnects these various components together and also interconnects these components 1216, 1218, 1212, and 1214 to a display controller 1206 and display device 1220 and to peripheral devices such as input/output (I/O) devices 1204 which may be mice, keyboards, modems, network interfaces, printers and other devices which are well known in the art. Typically, the input/output devices 1204 are coupled to the system through input/output controllers 1202. Where volatile RAM is included in memory 1212, the RAM is typically implemented as dynamic RAM (DRAM) which requires power continually in order to refresh or maintain the data in the memory. The display controller 1206 and display device 1220 may optionally include one or more GPUs to process display data. Optionally, a GPU memory 1208 may be provided to support GPUs included in the display controller 1206 or display device 1220."; FIG. 12)
identify content to be rendered in an image for display; (para. [0002], “A sprite is a two-dimensional (2D) image or animation that is integrated into a larger scene. Sprites can be mapped into three-dimensional (3D) scenes. Sprites may be created from any source, including pre-rendered imagery, dynamic 3D graphics, vector art, and even text. As graphics processor units (GPUs) have become available, libraries of sprites and graphic processing routines have been developed to provide a rendering system that allows use of the power of GPUs for faster rendering of graphics instead of depending entirely on the processing power of common central processing units (CPUs). Generally both CPUs and GPUs are involved in graphics processing operations provided by these libraries, with much of the graphics processing handled by the GPUs.”; para. [0034], " A compute memory object may include a collection of data elements that can be operated on by a compute program executable. A compute memory object may represent an image, a texture, a frame-buffer, an array of a scalar data type, an array of a user-defined structure, or a variable, etc"; para. [0019], "A Graphics Processing Unit (GPU) may be a dedicated graphics processor implementing highly efficient graphics operations, such as 2D, 3D graphics operations and/or digital video related functions. A GPU may include special (programmable) hardware to perform graphics operations, e.g., blitter operations, texture mapping, polygon rendering, pixel shading, and vertex shading. GPUs are known to fetch data from a frame buffer and blend pixels together to render an image back into the frame buffer for display. GPUs may also control the frame buffer and allow the frame buffer to be used to refresh a display, such as a CRT or LCD display. Conventionally, GPUs may take graphics processing tasks from one or more central processing units (CPUs) coupled with the GPUs to output raster graphics images to display devices through display controllers."; para. [0083], "The rendering system combines the rendering objects and physics objects together. To the end user, there is a single object that represents both on-screen rendering sprite and the physics rigid body. The physics rigid body information allows applying gravity, mass, acceleration, and velocity to individual sprites."
obtain, based on the identified content, one or more text-based intermediate files (a texture atlas) (para. [0083], "The rendering system combines the rendering objects and physics objects together. To the end user, there is a single object that represents both on-screen rendering sprite and the physics rigid body. The physics rigid body information allows applying gravity, mass, acceleration, and velocity to individual sprites."; para. [0002], "A sprite is a two-dimensional (2D) image or animation that is integrated into a larger scene. Sprites can be mapped into three-dimensional (3D) scenes. Sprites may be created from any source, including pre-rendered imagery, dynamic 3D graphics, vector art, and even text. As graphics processor units (GPUs) have become available, libraries of sprites and graphic processing routines have been developed to provide a rendering system that allows use of the power of GPUs for faster rendering of graphics instead of depending entirely on the processing power of common central processing units (CPUs). Generally both CPUs and GPUs are involved in graphics processing operations provided by these libraries, with much of the graphics processing handled by the GPUs."; para. [0060], "Tools exist to allow developers to refer to textures by name, creating a texture atlas that maps names to textures. However, those tools are not automatic, and do not provide memory management capabilities as described above. In one embodiment, an automatic texture atlas capability transparently creates a texture atlas."; para. [0061], "Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture.” Examiner’s note: any desired format corresponds to text-based format. It is well-known that text-based file format is widely accepted file format.”)
obtain texture content from one or more stored texture files based on one or more parameters in the one or more text-based intermediate files, the one or more parameters indicating the one or more stored texture files from which to obtain the texture content and one or more modifications to be made to the obtained texture content; and (para. [0061], "Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture."; para. [0062], "The developer may then request the image by name which is received in block 840. The graphics system locates the atlas file, loads it into the GPU, looks up the texture in the atlas in block 850, then provides an object representing the sub-rectangle of the atlas which contains the original image data in block 860."; para. [0027], "The sprites handled by the various embodiments may be rotated, sized, translated, scaled, moved, faded, and colored. Where sound is involved in the sprite, the sprite's sound may be played. Certain actions may be defined as waiting on an event before the action begins."; para. [0055], "The cached texture may also be stored to a file on a disc drive. If the cached texture is removed from the cache, but is used later, the rendering system can automatically reload the resource from disc, completely transparent to the user." para. [0064], "Animations include actions like scaling, movement, fading, timed wait, rotation, etc. In addition, each of these building blocks can be placed into either a “Group” animation (parallel) or a “Sequence” animation (sequential). The groups and sequences themselves can also be placed within other groups/sequence to create complex animations.”; para. [0065], “In one embodiment, using the Objective C syntax for defining arrays provides an intelligent way to interpret nested animations supplied by the user. When defining a sequence of actions, if one of the elements is itself another array of actions, that sub-array is then treated as a group (parallel) within the sequence. Similarly if one of the elements of a group of actions is itself another array of actions, that sub-array is then treated as a sequence within the group.”; para. [0066], “For example, if an animation is defined as an array of three actions:”))
render the image for display using the obtained texture content. (para. [0062], "The developer may then request the image by name which is received in block 840. The graphics system locates the atlas file, loads it into the GPU, looks up the texture in the atlas in block 850, then provides an object representing the sub-rectangle of the atlas which contains the original image data in block 860."; para. [0026], "Various embodiments described herein provide a variety of useful features for manipulating scene graphs. These embodiments may be provided as an API for a graphics rendering system, typically in the form of a software developer's kit (SDK), but may be packaged in any way desired. The rendering system in one embodiment is customized for the hardware (CPUs and GPUs) that will be used for processing the graphics, allowing more efficient use of that hardware."; para. [0037], "In one application, using a first GPU, the auto-batching may be able to consolidate the draw calls 310, 350, and 360 into a single draw call to render A, and draw calls 320, 330, and 340 into a single draw call to render B, resulting in only 2 actual draw calls to the GPU. In another application, where the GPU is capable of generating a single texture from a union of trees, the API may be able to reduce the number of GPU draw calls to a single draw call that is a union of A and B, resulting in a single texture of the union plus offsets. For example, draw call 310 renders A at a different location in the scene than draw call 350. Thus, offsets are calculated by the rendering system that allow displaying the rendered sprite A at both locations, without having to re-render sprite A. By auto-batching the draw calls, therefore, the same resulting scene may be displayed as a frame, but with reduced GPU activity, potentially allowing increased frame rates.")
Richebourg further discloses obtain, based on the identified content, one or more text-based intermediate files (see above) but does not explicitly disclose that
However, Quint more explicitly teaches (page. 99, “The main idea motivating SVG was simple: to create a generic document-oriented solution for graphics that can be adapted to modern media.”; “SVG, an XML grammar, grew out of an effort of the World Wide Web Consortium”
“Examiner’s note: An SVG file is text file that is written in XML-based text code.”)
Quint further teaches (page. 99, “In SVG, you specify transformations on objects either as an additive instruction (scale, translate, rotate, or skew) or as a global transformation matrix.”)
As both Richebourg and Quint are from the same field of endeavor, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Richebourg to include one or more text-based intermediate files in a scalable vector graphic (SVG) format and one or more modifications to be made to the obtained texture content, in the context of rendering images, according to the teaching of Quint, in order to create a generic document-oriented solution for graphics that can be adapted to modern media (page. 99 of Quint).
Regarding claim 16, the combination of Richebourg and Quint discloses the system of claim 14, wherein obtaining the one or more text-based intermediate files is based on an identifier associated with the identified content. (Richebourg para. [0061], "Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture."; para. [0002], “A sprite is a two-dimensional (2D) image or animation that is integrated into a larger scene. Sprites can be mapped into three-dimensional (3D) scenes. Sprites may be created from any source, including pre-rendered imagery, dynamic 3D graphics, vector art, and even text. As graphics processor units (GPUs) have become available, libraries of sprites and graphic processing routines have been developed to provide a rendering system that allows use of the power of GPUs for faster rendering of graphics instead of depending entirely on the processing power of common central processing units (CPUs). Generally both CPUs and GPUs are involved in graphics processing operations provided by these libraries, with much of the graphics processing handled by the GPUs.”; para. [0034], " A computer memory object may include a collection of data elements that can be operated on by a computer program executable. A computer memory object may represent an image, a texture, a frame-buffer, an array of a scalar data type, an array of a user-defined structure, or a variable, etc"; para. [0083], "The rendering system combines the rendering objects and physics objects together. To the end user, there is a single object that represents both on-screen rendering sprite and the physics rigid body. The physics rigid body information allows applying gravity, mass, acceleration, and velocity to individual sprites.")
Regarding claim 17, the combination of Richebourg and Quint disclose the system of claim 14, wherein the one or more text-based intermediate files are associated with the identified content as metadata. (Ricehbourg, “para. [0061], "Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture.”; para. [0062], "The developer may then request the image by name which is received in block 840. The graphics system locates the atlas file, loads it into the GPU, looks up the texture in the atlas in block 850, then provides an object representing the sub-rectangle of the atlas which contains the original image data in block 860."; para. [0002], “A sprite is a two-dimensional (2D) image or animation that is integrated into a larger scene. Sprites can be mapped into three-dimensional (3D) scenes. Sprites may be created from any source, including pre-rendered imagery, dynamic 3D graphics, vector art, and even text. As graphics processor units (GPUs) have become available, libraries of sprites and graphic processing routines have been developed to provide a rendering system that allows use of the power of GPUs for faster rendering of graphics instead of depending entirely on the processing power of common central processing units (CPUs). Generally both CPUs and GPUs are involved in graphics processing operations provided by these libraries, with much of the graphics processing handled by the GPUs.”; para. [0034], " A compute memory object may include a collection of data elements that can be operated on by a compute program executable. A compute memory object may represent an image, a texture, a frame-buffer, an array of a scalar data type, an array of a user-defined structure, or a variable, etc"; para. [0083], "The rendering system combines the rendering objects and physics objects together. To the end user, there is a single object that represents both on-screen rendering sprite and the physics rigid body. The physics rigid body information allows applying gravity, mass, acceleration, and velocity to individual sprites."; Quint, page. 99, “The main idea motivating SVG was simple: to create a generic document-oriented solution for graphics that can be adapted to modern media.”; “SVG, an XML grammar, grew out of an effort of the World Wide Web Consortium“ Examiner’s note: An SVG file is text file that is written in XML-based text code.” para. [0027], "The sprites handled by the various embodiments may be rotated, sized, translated, scaled, moved, faded, and colored. Where sound is involved in the sprite, the sprite's sound may be played. Certain actions may be defined as waiting on an event before the action begins."; para. [0055], "The cached texture may also be stored to a file on a disc drive. If the cached texture is removed from the cache, but is used later, the rendering system can automatically reload the resource from disc, completely transparent to the user." Examiner’s note: It is well-known that metadata acts as the embedded recipe and context for image. Finding the desire texture corresponds to as metadata.)
Regarding claim 18, Richebourg discloses the system of claim 14, wherein at least one of the one or more text-based intermediate files (para. [0061],"Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture.")
Richebourg fails to explicitly disclose the system of claim 14, wherein at least one of the one or more text-based intermediate files defines multiple texture files from which to obtain texture content.
However, Quint more explicitly teaches the system of claim 14, wherein at least one of the one or more text-based intermediate files defines multiple texture files from which to obtain texture content. (page. 100, "Despite its name, SVG isn’t just a vector drawing format. It also supports raster images and text. The specification requires compliant implementations to support at least the patent free JPEG and PNG formats, and it defines a generic way to include raster graphics in a document either as external or inline files."; page. 99, “The main idea motivating SVG was simple: to create a generic document-oriented solution for graphics that can be adapted to modern media.”; “SVG, an XML grammar, grew out of an effort of the World Wide Web Consortium“ Examiner’s note: An SVG file is text file that is written in XML-based text code.)
As both Richebourg and Qunit are from the same field of endeavor, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Richebourg to include one or more text-based intermediate files and defines multiple texture files, in the context of rendering images, according to the teaching of Quint, in order to create a generic document-oriented solution for graphics that can be adapted to modern media (page. 99 of Quint).
Regarding claim 19, the combination of Richebourg and Quint discloses the system of claim 14, wherein at least one of the one or more text-based intermediate files defines multiple locations within a single texture file from which to obtain texture content. (Richebourg para. [0061, “Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture.”; para. [0062], “The developer may then request the image by name which is received in block 840. The graphics system locates the atlas file, loads it into the GPU, looks up the texture in the atlas in block 850, then provides an object representing the sub-rectangle of the atlas which contains the original image data in block 860.”
Regarding claim 20, Richebourg discloses The system of claim 14, wherein at least one of the one or more text-based intermediate files defines (para. [0061, “Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture.”; para. [0062], “The developer may then request the image by name which is received in block 840. The graphics system locates the atlas file, loads it into the GPU, looks up the texture in the atlas in block 850, then provides an object representing the sub-rectangle of the atlas which contains the original image data in block 860.”)
Richebourg does not explicitly disclose a second intermediate file configured to be used to obtain the texture content.
Quint more explicitly teaches a second intermediate file configured to be used to obtain the texture content. (page. 99, “The main idea motivating SVG was simple: to create a generic document-oriented solution for graphics that can be adapted to modern media.”; “SVG, an XML grammar, grew out of an effort of the World Wide Web Consortium“ Examiner’s note: An SVG file is text file that is written in XML-based text code.; page. 100, "Despite its name, SVG isn’t just a vector drawing format. It also supports raster images and text. The specification requires compliant implementations to support at least the patent free JPEG and PNG formats, and it defines a generic way to include raster graphics in a document either as external or inline files.")
As both Richebourg and Qunit are from the same field of endeavor, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Richebourg to wherein at least one of the one or more text-based intermediate files defines a second intermediate file configured to be used to obtain the texture content, in the context of rendering images, according to the teaching of Quint, in order to create a generic document-oriented solution for graphics that can be adapted to modern media (page. 99 of Quint).
Regarding claim 21, Richebourg discloses the system of claim 14, wherein (para. [0061],"Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture."; para. [0002], “A sprite is a two-dimensional (2D) image or animation that is integrated into a larger scene. Sprites can be mapped into three-dimensional (3D) scenes. Sprites may be created from any source, including pre-rendered imagery, dynamic 3D graphics, vector art, and even text. Examiner’s note: the desired texture corresponds to a single part of the identified content.)
Richebourg fails to disclose the system of claim 14, wherei
However, Quint more explicitly teaches the system of claim 14, wherein two or more intermediate files are identified for a single part of the identified content. (page. 99, “On top of these basic shapes, SVG also supports paths, including cubic and quadratic Bezier curves and elliptical arcs. These graphical objects each have
different characteristics but they all share trans formations and styling features. In SVG, you specify transformations on objects either as an additive instruction (scale, translate, rotate, or skew) or as a global transformation matrix. And you can do styling in SVG through the use of Cascading Style Sheets (CSS).” page. 100, “Despite its name, SVG isn’t just a vector drawing format. It also supports raster images and text. The specification requires compliant implementations to support at least the patent free JPEG and PNG formats, and it defines a generic way to include raster graphics in a document either as external or inline files." Examiner’s note: The combination of texture atlas file and external files or inline files corresponds to two or more intermediate files.)
As both Richebourg and Quint are from the same field of endeavor, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Richebourg to include wherein two or more intermediate files, in the context of rendering images, according to the teaching of Quint, in order to create a generic document-oriented solution for graphics that can be adapted to modern media (page. 99 of Quint).
Regarding claim 22, the combination of Richebourg and Quint discloses the system of claim 14, wherein the instructions, when executed, further cause the one or more processors to apply the one or more modifications to the obtained texture content in accordance with the modifications defined by the parameters in the one or more text- based intermediate files. (Richebourg para. [0020], “"A typical GPU is typically a Single Instruction Multiple Data (SIMD) device in which each instruction may operate on multiple pieces of data in parallel. Just as CPUs have developed from single processing units to multiple core processor that can execute instructions separately in each core, more recent GPUs provide “lanes” of vector computation, each of which can be interpreted as a separate thread. A single hardware sequencer typically operates on a group of such threads in parallel."; para. [0061], "Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture."; para. [0062], "The developer may then request the image by name which is received in block 840. The graphics system locates the atlas file, loads it into the GPU, looks up the texture in the atlas in block 850, then provides an object representing the sub-rectangle of the atlas which contains the original image data in block 860."; para. [0027], "The sprites handled by the various embodiments may be rotated, sized, translated, scaled, moved, faded, and colored. Where sound is involved in the sprite, the sprite's sound may be played. Certain actions may be defined as waiting on an event before the action begins."; para. [0064], "Animations include actions like scaling, movement, fading, timed wait, rotation, etc. In addition, each of these building blocks can be placed into either a “Group” animation (parallel) or a “Sequence” animation (sequential). The groups and sequences themselves can also be placed within other groups/sequence to create complex animations.”; para. [0065], “In one embodiment, using the Objective C syntax for defining arrays provides an intelligent way to interpret nested animations supplied by the user. When defining a sequence of actions, if one of the elements is itself another array of actions, that sub-array is then treated as a group (parallel) within the sequence. Similarly if one of the elements of a group of actions is itself another array of actions, that sub-array is then treated as a sequence within the group.”; para. [0066], “For example, if an animation is defined as an array of three actions:”)
Regarding claim 23, Richebourg disclose the system of claim 22, wherein the one or more modifications include at least one of a re-colouring, an opacity change, a translation, a rotation, a masking, a reflection, an overlay, a shape addition, or an enlargement applied to at least a respective portion of the obtained texture content. (Richebourg, para. [0027], “The sprites handled by the various embodiments may be rotated, sized, translated, scaled, moved, faded, and colored. Where sound is involved in the sprite, the sprite's sound may be played. Certain actions may be defined as waiting on an event before the action begins."; para. [0002], "A sprite is a two-dimensional (2D) image or animation that is integrated into a larger scene. Sprites can be mapped into three-dimensional (3D) scenes. Sprites may be created from any source, including pre-rendered imagery, dynamic 3D graphics, vector art, and even text. As graphics processor units (GPUs) have become available, libraries of sprites and graphic processing routines have been developed to provide a rendering system that allows use of the power of GPUs for faster rendering of graphics instead of depending entirely on the processing power of common central processing units (CPUs). Generally both CPUs and GPUs are involved in graphics processing operations provided by these libraries, with much of the graphics processing handled by the GPUs."; para. [0064], "Animations include actions like scaling, movement, fading, timed wait, rotation, etc. In addition, each of these building blocks can be placed into either a “Group” animation (parallel) or a “Sequence” animation (sequential). The groups and sequences themselves can also be placed within other groups/sequence to create complex animations."; para. [0061], "Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture.”
Quint further teaches wherein the one or more modifications include at least one of a re-colouring, an opacity change, a translation, a rotation, a masking, a reflection, an overlay, a shape addition, or an enlargement applied to at least a respective portion of the obtained texture content. (page. 99, “In SVG, you specify transformations on objects either as an additive instruction (scale, translate, rotate, or
skew) or as a global transformation matrix. And you can do styling in SVG through the use of Cascading Style Sheets (CSS).”
Regarding claim 25, claim 25 is the method claim of claim 14 and is accordingly rejected under same rationale.
Regarding claim 26, Richebourg discloses the method of claim 25, wherein at least one of the one or more text-based intermediate files (para. [0061], "Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture.”
Richebourg does not explicitly disclose w
Quint more explicitly teaches wherein at least one of the one or more text-based intermediate files defines a second intermediate file configured to be used to obtain the texture content, thereby forming a hierarchical set of intermediate files. (page. 99, "You can also group all graphical objects together in SVG and organize them hierarchically. As with XML, SVG lets you organize according to a tree structure. Through inheritance, the grouping and structuring capability offers great flexibility for both transformations and styling. For example, you could scale a group of three distinct graphical objects with one single transformation instruction. Similarly, you could fill all objects with a particular color by using a single styling instruction at the group level. You can also give all SVG elements individual XML IDs so you can reference them easily in other parts of the document. That way, by using one simple reference, you can define symbols and reusable components that can be drawn in as many situations as needed in the rest of the document."; page. 100, “"Despite its name, SVG isn’t just a vector drawing format. It also supports raster images and text. The specification requires compliant implementations to support at least the patent free JPEG and PNG formats, and it defines a generic way to include raster graphics in a document either as external or inline files." Examiner’s note: when SVG has external or inline files and organize them hierarchically, it corresponds to forming a hierarchical set of intermediate files.)
As both Richebourg and Quint are from the same field of endeavor, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Richebourg to include defining a second intermediate file, thereby forming a hierarchical set of intermediate files, in the context of rendering images, according to the teaching of Quint, in order to create a generic document-oriented solution for graphics that can be adapted to modern media (page. 99 of Quint).
Regarding claim 31, the combination of Richebourg and Quint discloses the method of claim 25, further comprising modifying a mesh to which the texture content is to be applied based on instructions encoded in the one or more text-based intermediate files. (Richebourg para. [0042],"Each vertex is a structure with (x, y, z, color, texture_position). The vertices are stored in GPU memory "; para. [0061], "Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture."; para. [0037], "In one application, using a first GPU, the auto-batching may be able to consolidate the draw calls 310, 350, and 360 into a single draw call to render A, and draw calls 320, 330, and 340 into a single draw call to render B, resulting in only 2 actual draw calls to the GPU. In another application, where the GPU is capable of generating a single texture from a union of trees, the API may be able to reduce the number of GPU draw calls to a single draw call that is a union of A and B, resulting in a single texture of the union plus offsets. For example, draw call 310 renders A at a different location in the scene than draw call 350. Thus, offsets are calculated by the rendering system that allow displaying the rendered sprite A at both locations, without having to re-render sprite A. By auto-batching the draw calls, therefore, the same resulting scene may be displayed as a frame, but with reduced GPU activity, potentially allowing increased frame rates." Examiner’s note: In 3D graphics, a mesh is the mathematical frameworks (vertices, edges, and faces) that defines the shape of a 3D object. Vertices are the fundamental building blocks of 3D mesh. Therefore, rendering texture corresponds to modifying a mesh.)
Regarding claim 32, the combination of Richebourg and Quint discloses the method of claim 25, further comprising applying the one or more modifications to the obtained texture content in accordance with the modifications defined by the parameters in the one or more text-based intermediate files. (Richebourg para. [0061],"Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture."; para. [0062],
"The developer may then request the image by name which is received in block 840. The graphics system locates the atlas file, loads it into the GPU, looks up the texture in the atlas in block 850, then provides an object representing the sub-rectangle of the atlas which contains the original image data in block 860."; para. [0027], "The sprites handled by the various embodiments may be rotated, sized, translated, scaled, moved, faded, and colored. Where sound is involved in the sprite, the sprite's sound may be played. Certain actions may be defined as waiting on an event before the action begins."; para. [0064], "Animations include actions like scaling, movement, fading, timed wait, rotation, etc. In addition, each of these building blocks can be placed into either a “Group” animation (parallel) or a “Sequence” animation (sequential). The groups and sequences themselves can also be placed within other groups/sequence to create complex animations."; para. [0064], "Animations include actions like scaling, movement, fading, timed wait, rotation, etc. In addition, each of these building blocks can be placed into either a “Group” animation (parallel) or a “Sequence” animation (sequential). The groups and sequences themselves can also be placed within other groups/sequence to create complex animations.”; para. [0065], “In one embodiment, using the Objective C syntax for defining arrays provides an intelligent way to interpret nested animations supplied by the user. When defining a sequence of actions, if one of the elements is itself another array of actions, that sub-array is then treated as a group (parallel) within the sequence. Similarly if one of the elements of a group of actions is itself another array of actions, that sub-array is then treated as a sequence within the group.”; para. [0066], “For example, if an animation is defined as an array of three actions:”)
Regarding claim 33, claim 33 is the non-transitory computer readable storage media claims (FIG. 12; para. [0018], "The processes depicted in the figures that follow are performed by processing logic that comprises hardware (e.g., circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer or a dedicated machine), or a combination of both. Although the processes are described below in terms of some sequential operations, some of the operations described may be performed in different order, and some operations may be performed in parallel rather than sequentially.") of claim 14 and is accordingly rejected under same rationale.
Claims 15 is rejected under 35 U.S.C. 103 as being unpatentable over Richebourg et al. (US 20140184606 A1; IDS REF) (herein after Richebourg) in view of A. Quint ("Scalable vector graphics," in IEEE MultiMedia, vol. 10, no. 3, pp. 99-102, July-Sept. 2003, doi: 10.1109/MMUL.2003.1218261.; IDS REF) (hereinafter Quint), and further in view of Ren et al. (US 20140267346 A1; IDS REF) (hereinafter Ren).
Regarding claim 15, the combination of Richebourg and Quint does not explicitly disclose, the system of claim 14, wherein the identified content comprises one or more virtual objects or virtual elements.
Ren more explicitly teaches the system of claim 14, wherein the identified content comprises one or more virtual objects or virtual elements. (para. [0010], “In one embodiment, a method for using a processor to apply repeated textures to a surface of an object in 3D virtual environment using a texture atlas has been developed.”
As Richebourg, Quint, and Ren are from the same field of endeavor, it would
have been obvious to one of the ordinary skill in the art before the effective filing date of
the claimed invention to modify the combination of Richebourg and Quint to include wherein the identified content comprises one or more virtual objects or virtual elements, in the context of rendering images, according to the teaching of Ren in to apply repeated textures to a surface of an object in 3D virtual environment (para. [0010] of Ren)
Claims 24 is rejected under 35 U.S.C. 103 as being unpatentable over Richebourg et al. (US 20140184606 A1; IDS REF) (herein after Richebourg) in view of A. Quint ("Scalable vector graphics," in IEEE MultiMedia, vol. 10, no. 3, pp. 99-102, July-Sept. 2003, doi: 10.1109/MMUL.2003.1218261.; IDS REF) (hereinafter Quint), and further in view of Fessler et al. (US 20210142547 A1) (hereinafter Fessler).
Regarding claim 24, the combination of Richebourg and Quint discloses the system of claim 14, wherein the one or more text-based intermediate files are defined(Ricehbourg, “para. [0061], "Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture.”; Quint, page. 99, “The main idea motivating SVG was simple: to create a generic document-oriented solution for graphics that can be adapted to modern media.”; “SVG, an XML grammar, grew out of an effort of the World Wide Web Consortium“ Examiner’s note: An SVG file is text file that is written in XML-based text code.)
The combination of Richebourg and Quint fails to disclose the system of claim 14, wherein the one or more text-based intermediate files are
Fessler more explicitly teaches the system of claim 14,wherein (para. [0035],"In some embodiments, a developer application 121 includes an editor 123 for creating a game, game-mod, or assets. Generally, a developer may utilize an editor 123 component to generate features of a game, like textures (or materials), objects, and other assets, configure environmental features, as well as gameplay. Particularly, the editor 123 may include a models module 125 within which game assets like smart materials, textures and objects may be defined, and game files defining the characteristics of objects or an element made up of multiple objects, like texturing properties which may be based on a smart material instance, for rendering an object or element may generated. Such game files may further define characteristics of objects or elements such as movement, rules governing movement, and the like. In some embodiments, the models module 125 may comprise a plurality of pre-populated objects (e.g., polygons and corresponding polygon meshes of a polyhedron correspond to an object, like a block, spherical polyhedron, and the like) and pre-populated textures, like a library of pre-populated objects and textures, which is not to suggest that user defined objects and textures (or materials) may not be defined and stored within the models module. A developer, such as via the editor 123, may select (e.g., via drag and drop, double click, or other interaction) different ones of the pre-populated objects to populate an environment with selected objects and construct elements from subsets of objects, such as by positioning, merging, or otherwise interacting with the objects via the editor. Similarly, a developer, such as via the editor 123, may select an object (or objects or element) and a texture to apply. The object (or objects) and any applied texture thereto may be rendered by the editor as it would appear in the environment (e.g., a castle may be constructed from objects positioned to form the castle in a given location, a texture applied to the objects forming the castle and manipulated, and the various objects rendered with the applied texture to visually display the castle on a screen of the developer device). In addition to utilizing pre-populated objects, a developer may construct new objects and textures, such as via the editor 123, whether manually or utilizing automated tools. In some embodiments, a developer may select a particular configuration of objects, textured or untextured, via the editor 123 to store a particular model (e.g., for replication)."; para. [0043], "As described above, a game server 160 may host a game instance 165. The game server 160 may be provisioned by a publisher 150 to host the game instance 165, such as on demand, when a device requests to play a game. For example, a game server 160 may be provisioned to execute a game 171 included in a repository 170. While the game instance 165 is active, other devices may optionally join the game instance 165. A game 171 may include various game files, like game code and model code. The model code of a game 171 may identify the various standard models (e.g., models utilizing standard textures and objects) 175 included in the game, which may be included in a game application 135 provided to client devices 130 and the developer application 121 provided to developer devices 120. Thus, for example, the game files necessary to join a particular game instance 165 may be relatively lightweight, such as various scrips and the like, with relatively small file sizes (e.g., compared to 3D models). In other words, the model code may describe how to construct models from standard objects and textures, which are already available to a game engine. However, developers may also generate other non-standard models, referred to herein as user models 173, such as by creating and utilizing a non-standard object or texture. In such cases, game files may also specify one or more user models 173 for a game that cannot be constructed from the standard models 175 alone. Accordingly, one or more objects or textures not included in the standard model 175, along with the model code to construct a model from the objects or textures, may be transferred to a client device. In some embodiments, a listing of game indicates whether the game is based on standard models 175 or includes user models 173, and may further indicate a file size associated with the user models 173 necessary to run the game.”; para. [0044], "Some or all of the information utilized to launch a game server 160 or game instance 165 may be stored within the repository 170. For example, when the publisher 150 receives a request to publish a game from a developer device 120, such as in response a to a user selection to publish the game via an interface of a developer application 121, the publisher 150 may obtain the game files and store a game 171. In some embodiments, a publisher application 155 may parse the game files to identify user models 173 which cannot be constructed from standard model 175 information. The publisher 150 may request from the developer device 120 information corresponding to the user models and stored the user models 173 within the repository 170. In some embodiments, the repository 170 may include information about developer accounts, such as that for an individual developer or constituent members of a team of developers. User models 173 and games 171 may be associated with a given developer account or accounts of respective team members such that developers can manage aspects of a published game.”; para. [0051], "The smart material interface 237 may include one or more panes by which users may select a texture 225 (or material) for utilization within the environment space and adjust properties of the texture. In some embodiments, the textures may include a set of pre-configured smart materials in addition to texture samples. The smart material interface 237 may include a pane by which a user may define an instance of a smart material within the environment. In some embodiments, a given texture or material (or pre-configured smart material) may be utilized to define multiple different instances of a smart material, such as if divergent scaling is desired for some areas of the environment compared to others. In some embodiment, the pane includes an image of a texture or material, like a texture tile. In some embodiments, a texture tile may be selected from the image, such as by selecting a region of the image to correspond to a texture tile. Tiling properties for programmatically configuring a smart material from a texture tile may also be specified, such as a direction in which an origin texture tile should be replicated (e.g., horizontally, vertically, or both in a plane). In some embodiments, a preview of the tiling is rendered, such as within the environment, and a user may adjust a slope, offset, or other aspects for the tiling direction. Further, the pane may include a scaling option, such as to adjust a relative size of a texture tile within the environment (e.g., a brick of a brick texture should look very large to an ant within in a human-world-like environment and the opposite to a giant; similarly, an ant may utilize tiny bricks to construct a home and a giant may use large bricks from the perspective of a human-world-like character). The pane may list defined smart materials (which may also include default smart materials based on a common scaling, which when altered are indicated as a defined smart material instance) from which a developer may select to apply to an object. In turn, when the smart material is applied to an object, model code corresponding to the object is analyzed by the engine 210, such as to translate surfaces of the object into smart material space (or vice versa). A surface of an object is mapped to a 2D material area of the applied smart material to obtain a mapping of pixels of material (e.g., from pixel locations within a texture tile) within the boundaries of the face based on the configuration of the smart material. The engine 210, in turn, renders the mapped pixels on the face of the object. Thus, for example, when the engine 210 reads model code generated for the object that specifies an applied smart material, the engine 210 obtains properties of the smart material instance (e.g., tiling properties, texture tile, etc.) and renders material aspects within polygons of the object from a based on properties of the smart material."; para. [0069], "In some embodiments, step 410 comprises identifying user models based on user generated objects or textures by parsing the game files to extract the user objects and textures not represented in a standard set of objects and textures; determining a size of the extracted user object and, which may be compared to a threshold, such as a platform dependent threshold; rendering the extracted objects and textures based on model code (e.g., a model code may include information for rendering an object, a selected smart material for the object, and a smart material instance by which material rendering on object surfaces can be determined) referencing at least one user object or texture, which may be subject to approval; and storing permissible user objects and textures (e.g., objects and textures not exceeding a threshold size).")
As Richebourg, Quint, and Fessler are from the same field of endeavor, it would
have been obvious to one of the ordinary skill in the art before the effective filing date of
the claimed invention to modify the combination of Richebourg and Quint to include wherein the one or more text-based intermediate files are defined on a per-user basis to enable personalization of the rendering, in the context of rendering images, according to the teaching of Fessler in order to provide and create desired environment by a user (para. [0073] of Fessler).
Claims 27 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Richebourg et al. (US 20140184606 A1; IDS REF) (herein after Richebourg) in view of A. Quint ("Scalable vector graphics," in IEEE MultiMedia, vol. 10, no. 3, pp. 99-102, July-Sept. 2003, doi: 10.1109/MMUL.2003.1218261.; IDS REF) (hereinafter Quint), and further in view of Sunkavalli et al. (US 11488342 B1) (hereinafter Sunkavalli).
Regarding claim 27, the combination of Richebourg and Quint discloses the method of claim 25, further comprising generating at least one of the one or more text-based intermediate files
(Ricehbourg, “para. [0061], "Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture.”; Quint, page. 99, “The main idea motivating SVG was simple: to create a generic document-oriented solution for graphics that can be adapted to modern media.”; “SVG, an XML grammar, grew out of an effort of the World Wide Web Consortium“ Examiner’s note: An SVG file is text file that is written in XML-based text code.)
the combination of Richebourg and Quint fails to disclose the method of claim 25, further comprising
Sunkavalli more explicitly teaches the method of claim 25, further comprising(Col 12 Lines 27-53, “When one or more material maps are determined to be missing, the hallucination component 150 to generate synthetic maps of the missing material maps. In the example shown, a metallic material map and a roughness material map are missing. The synthetic maps may be generated using a Generative Adversarial Network (GAN). The GAN comprises two components—generator and discriminator. The generator aims at synthesizing realistic output that is hard for the discriminator to distinguish from actual outputs. The discriminator attempts to determine whether an input is real or synthesized from the generator. With adversarial training strategy to jointly train the generator and discriminator, the result is a generator that can synthesize very realistic material map outputs. Once trained, the generator can receive a base-color material mapping as input and generate a synthetic metallic, normal, and/or roughness map type. In one aspect, the generator takes a latent vector as input and produces the other maps. The goal of training is to find a latent vector that will produce a set of maps where the base color is similar to the known base color. The other maps may be generated from this latent vector. The generation of other map types is also possible. The generator works by attempting to minimize loss against the base-color material map when generating the other material maps in the material definition. When more than one material map for a material definition exits, the generator may attempt to minimize loss against all of the existing material maps.”)
As Richebourg, Quint, and Sunkavalli are from the same field of endeavor, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Richebourg and Quint to include generating at least one of the one or more text-based intermediate files using a trained machine learning model, in the context of rendering images, according to the teaching of Sunkavalli in order to generate very realistic material map (Col 12 Lines 37-40 of Sunkavalli).
Regarding claim 28, the combination of Richebourg and Quint fail to discloses the method of claim 27, wherein the trained machine learning model comprises a Generative Adversarial Network (GAN).
Sunkavalli more explicitly teaches the method of claim 27, wherein the trained machine learning model comprises a Generative Adversarial Network (GAN). (Col 8 Lines 44-53, “The neural network may include many more than three layers. Neural networks with more than one hidden layer may be called deep neural networks. Example neural networks that may be used with aspects of the technology described herein include, but are not limited to, convolutional neural networks (CNN), such as a U-net, recursive neural networks, recurrent neural networks. The training implementation described subsequently uses a convolutional neural network, but aspects of the technology are applicable to other types of machine learning.”; Col 12 Lines 27-53, “When one or more material maps are determined to be missing, the hallucination component 150 to generate synthetic maps of the missing material maps. In the example shown, a metallic material map and a roughness material map are missing. The synthetic maps may be generated using a Generative Adversarial Network (GAN). The GAN comprises two components—generator and discriminator. The generator aims at synthesizing realistic output that is hard for the discriminator to distinguish from actual outputs. The discriminator attempts to determine whether an input is real or synthesized from the generator. With adversarial training strategy to jointly train the generator and discriminator, the result is a generator that can synthesize very realistic material map outputs. Once trained, the generator can receive a base-color material mapping as input and generate a synthetic metallic, normal, and/or roughness map type. In one aspect, the generator takes a latent vector as input and produces the other maps. The goal of training is to find a latent vector that will produce a set of maps where the base color is similar to the known base color. The other maps may be generated from this latent vector. The generation of other map types is also possible. The generator works by attempting to minimize loss against the base-color material map when generating the other material maps in the material definition. When more than one material map for a material definition exits, the generator may attempt to minimize loss against all of the existing material maps.”)
As Richebourg, Quint, and Sunkavalli are from the same field of endeavor, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Richebourg and Quint to include wherein the trained machine learning model comprises a Generative Adversarial Network (GAN), in the context of rendering images, according to the teaching of Sunkavalli in order to generate very realistic material map (Col 12 Lines 37-40 of Sunkavalli).
Claims 29 is rejected under 35 U.S.C. 103 as being unpatentable over Richebourg et al. (US 20140184606 A1; IDS REF) (herein after Richebourg) in view of A. Quint ("Scalable vector graphics," in IEEE MultiMedia, vol. 10, no. 3, pp. 99-102, July-Sept. 2003, doi: 10.1109/MMUL.2003.1218261.; IDS REF) (hereinafter Quint), and further in view of Bialogonski (US 20210142547 A1) (hereinafter Bialogonski).
Regarding claim 29, the combination of Richebourg and Quint discloses the method of claim 25, further comprising identifying (Richebourg para. [0053],"In one embodiment, the rendering system manages textures in GPU memory. This may involve texture reuse. When the programmer indicates an image to use, the system manages it in GPU memory. The programmer can also indicate that a texture is no longer to be used, allowing the system to remove the texture from GPU memory. By managing textures in GPU memory, the system can guarantee that there is only a single copy of any image in GPU memory."; para. [0061], "Developers in one embodiment can run a single automation tool as illustrated in FIG. 8 by flowchart 800 that takes a directory of texture files (PNG, JPG, TIFF etc.) in block 810, parses each individual texture in block 820, and generates a texture atlas in block 830 (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas. Later, when the rendering system receives the name of the texture as specified by the developer in block 840, in block 850 a lookup occurs to find the desired texture, and finally in block 860 to provide the sub-rectangle of the atlas with the desired texture.”)
The combination of Richebourg and Quint does not explicitly disclose removing one or more portions of a texture file that are not referenced by any of the one or more text-based intermediate files.
Bialogonski more explicitly teaches removing one or more portions of a texture file that are not referenced by any of the one or more text-based intermediate files. (para. [0065], “In operations S501 and S502, a texture 600 is obtained and divided into a plurality of parts 601. Operations S501 and S502 are equivalent to operations S101 and S102 in FIG. 1, and a detailed explanation will not be repeated herein. In the present embodiment the texture 600 is divided into parts of the same size as the plurality of parts 201 of the texture 200 in FIG. 2. By using a standard sized part for all textures stored in the texture atlas 210, the process of adding and removing parts of different textures to/from the texture atlas 210 can be simplified, since a part of a texture that is no longer required can simply be replaced by a similarly-sized part of a new texture. However, in other embodiments the texture that is obtained in operation S501 could be divided into parts of a different size to the parts of one or more textures that are already stored in the texture atlas 210.”)
As Richebourg, Quint, and Bialogonski are from the same field of endeavor, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Richebourg and Quint to include identifying and removing one or more portions of a texture file that are not referenced by any of the one or more text-based intermediate files, in the context of rendering images, according to the teaching of Bialogonski in order to provide of improvements to texture atlases that could increase performance (para. [003] of Bialogonski).
Claim 30 is rejected under 35 U.S.C. 103 as being unpatentable over Richebourg et al. (US 20140184606 A1; IDS REF) (herein after Richebourg) in view of A. Quint ("Scalable vector graphics," in IEEE MultiMedia, vol. 10, no. 3, pp. 99-102, July-Sept. 2003, doi: 10.1109/MMUL.2003.1218261.; IDS REF) (hereinafter Quint), and further in view of Ren et al. (US 20140267346 A1; IDS REF) (hereinafter Ren) and Hannuksela US 20220078486 A1) (hereinafter Hannuksela)
Regarding claim 30, the combination of Richebourg and Quint fails to disclose the method of claim 25, further comprising rearranging the stored texture files by relocating frequently referenced texture portions to a top-left corner of a texture map to reduce a coordinate address length within the one or more text-based intermediate files.
Ren teaches the method of claim 25, further comprising rearranging the stored texture files by relocating frequently referenced texture portions (Ren, para. [0029], "The processor 108 groups together individual textures that have the same or similar border colors (block 204). For example, FIG. 6 depicts a set of textures 604 that are arranged into a completed texture map 608 using process 200. Each of the textures in the texture map 608 is formed from a rectangular arrangement of texels….In the set of textures 604, the textures 624 and 628 have same border colors. Another group of textures 632, 636, 640, and 644 also share same border colors. In some instances, an individual texture does not have a border color that matches or is similar to other border colors, and the texture remains ungrouped from other textures. For example, the texture 650 in FIG. 6 is not grouped with other textures."; para. [0030], "During process 200, the grouping of textures with similar colors enables arrangement of the textures together with protective rectangular border tiles around the borders of the texture group." Examiner’s note: Ren teaches relocating reference texture portions when rearranging the stored files when files are stored; the examiner is interpreting “frequently” as consistently relocating reference text portions.)
As Richebourg, Quint, and Ren are from the same field of endeavor, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the combination Richebourg and Quint, Ren to include rearranging the stored texture files by relocating frequently referenced texture portions, in the context of rendering images, according to the teaching of Ren in order to provide access to the frequently referenced texture portions quickly.
The combination of Richebourg, Quint, and Ren fails to disclose
Hannuksela teaches texture map to reduce a coordinate address length within the one or more text-based intermediate files. (para. [0133], “There may be different alternatives in specifying (de)coding order or bitstream order of image segments and coding units, or alike. For example, coding units, such as macroblocks of H.264/AVC, may be ordered in the bitstream in a raster scan order along a coding unit grid within a picture. In another example, tiles are ordered in tile raster scan order along a tile grid within a picture, and coding units (e.g. CTUs of HEVC) are ordered in raster scan order within a tile. In yet another example, tile groups are ordered in raster scan order (e.g. according to their top left corner) within a picture, tiles are ordered in raster scan order within a tile group, and coding units (e.g. CTUs) are ordered in raster scan order within a tile.”, para. [0219], “Rectangular region-wise packing metadata is described next: For each region, the metadata defines a rectangle in a projected picture, the respective rectangle in the packed picture, and an optional transformation of rotation by 90, 180, or 270 degrees and/or horizontal and/or vertical mirroring. Rectangles may for example be indicated by the locations of the top-left corner and the bottom-right corner. The mapping may comprise resampling. As the sizes of the respective rectangles can differ in the projected and packed pictures, the mechanism infers region-wise resampling.” Examiner’s note: the outcome of relocating frequently referenced texture portions to a top left corner of a texture map corresponds to reducing a coordinate address.)
As Richebourg, Quint, Ren, and Hannuksela are from the same field of endeavor, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the combination Richebourg, Quint, and Ren to include rearranging the stored texture files by relocating frequently referenced texture portions to a top-left corner of a texture map to reduce a coordinate address length within the one or more text-based intermediate files, in the context of rendering images, according to the teaching of Hannuksela in order to provide a reduced coordinated address when accessing to the referenced texture portions.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hyorim Park whose telephone number is (571)272-3859. The examiner can normally be reached Monday - Friday.
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, Alicia Harrington can be reached at (571) 272-2330. 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.
/Hyorim Park/Examiner, Art Unit 2615
/ALICIA M HARRINGTON/Supervisory Patent Examiner, Art Unit 2615
Prosecution Insights