DETAILED ACTION
Response to Arguments
Applicant's arguments filed 07/07/2026 regarding the 35 USC 103 rejections with respect to amended limitations of independent claims 1, 9 and 16 have been fully considered but they are not persuasive.
Applicant argues in page 10 RE the amended limitations of independent claim 1 “using the information, convert at least one scene in the video to a three-dimensional (3D) representation of space comprising at least a first volumetric representation of at least a first object in the video, wherein the at least one scene in the video is converted to the 3D representation of space by extracting out scene geometry from a shader pipeline associated with the computer game and then down- sampling a number of mesh vertexes into a point cloud;” against the references individually that “Ricard's point clouds are directed towards correcting geometry and topology by merging duplicate vertices, extracting vertices from reconstructed mesh patches to create a reconstructed point cloud, and executing a color transfer process to color points for attribute video frames within a static data compression and decompression architecture. See Ricard, at para. [0005], [0276], and [0315]. However, Ricard's point clouds are not used to convert at least one scene in the video to a 3D representation of space by extracting out scene geometry from a shader pipeline associated with the computer game and then down-sampling a number of mesh vertexes into a point cloud, as now recited by Claim 1. Ricard is completely silent regarding any active, runtime intercept driver capable of tapping a graphics engine's executing shader pipeline.”. In response, the examiner contests that one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Here Ricard is merely cited to clarify typical GPU functionality that converts images/depthmaps mesh geometry in rasterization process typical in the GPU shader pipeline [0178], wherein Swann readily teaches a game engine that receives information from a computer game, the information comprising video and game metadata (Figs 1, 5, [0081]-[0083]); and using the information, convert at least one scene in the video to a three-dimensional (3D) representation of space comprising at least a first volumetric representation of at least a first object in the video, wherein the at least one scene in the video is converted to the 3D representation of space by extracting out scene geometry from a shader pipeline associated with the computer game and then down-sampling a number of mesh vertexes into a point cloud (Fig 14S1540-1544, abstract, [0168]-[0169], [0234]-[0235] “obtaining a corresponding sequence of in-game virtual camera positions at which the video images were created, obtaining a corresponding sequence of depth buffer values for a depth buffer used by the videogame whilst creating the video images, and for each of a plurality of video images and corresponding depth buffer values of the obtained sequences, obtain mapping points corresponding to a sampling distribution of points over the area of a respective video image and their associated depth values; wherein respective mapping points are obtained by projecting co-ordinated derived from the sample points from the video image and associated depth values back into a 3D game world co-ordinate system of the videogame title; thereby obtaining a point cloud dataset of mapping points corresponding to the first sequence of video images. In this case, a sampling distribution of positions over the area of the video image corresponds to the predetermined set of positions within a respective video image. The sampling may be 1:1 (i.e. all pixels of the video image) or a sub-sampling, such as 1:2 (i.e. a chequerboard) or 1:4 (e.g. one pixel per 2×2 block of pixels).” Wherein the first derived points are the mesh vertices that are downsampled with the subsampled to obtain the point cloud with a coarser density in the GPU pipeline, identical to the functionality of shader pipeline disclosed in applicants own disclosure in Fig 6, [0073]-[0074] “a computer game video with metadata accessible from the game engine is received. Moving to state 602, the z-buffer is extracted from game engine shader pipeline to generate a depth map for each frame… a point cloud is created for at least the first frame. One technique for generating the point cloud is to do so uniformly over each 3D space occupied by an object based on the depth maps generated by multiple camera views of a frame. Another technique to generate the point cloud is to do so by extracting out the scene geometry (meshes) from the shader pipeline, and then down-sampling the number of mesh vertexes into a point cloud representation. Note that to generate point clouds from multiple camera views, in addition to the depth map, camera parameters should be received.” performing the same functionality.);
Ricard is merely cited an example of a typical GPU shader functionality (pipeline) where images/depthmaps are converted to mesh geometry in the GPU shader pipeline [0178], generate point cloud from extracted geometry (mesh/depth map) using the rasterization in typical shader pipeline followed by down-sampling the mesh vertexes [0005], [0096], [0180]-[0181], [0315] etc reducing the pointcloud complexity. This is readily available in Swann to effectively generate the 3D pointcloud.
that In response to applicant's argument in page 10 that Ricard is nonanalogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, as set forth above, Ricard is merely cited an example of a typical GPU shader functionality (pipeline) where images/depthmaps are converted to mesh geometry in the GPU shader pipeline [0178], generate point cloud from extracted geometry (mesh/depth map) using the rasterization in typical shader pipeline followed by down-sampling the mesh vertexes [0005], [0096], [0180]-[0181], [0315] etc reducing the pointcloud complexity. This is readily available in Swann to effectively generate the 3D pointcloud. In addition this can be equally applied in any system and method to generate point cloud from video image/frames.
In response to applicant’s argument in page 11 there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, as set forth above, Ricard is merely cited an example of a typical GPU shader functionality (pipeline) where images/depthmaps are converted to mesh geometry in the GPU shader pipeline [0178], generate point cloud from extracted geometry (mesh/depth map) using the rasterization in typical shader pipeline followed by down-sampling the mesh vertexes [0005], [0096], [0180]-[0181], [0315] etc reducing the pointcloud complexity. This is readily available in Swann to effectively generate the 3D pointcloud. In addition this can be equally applied in any system and method to effectively generate/reconstruct point cloud from video image/frames.
Applicant further argues in pages 11-12 RE the amended limitation of independent claims 9 and 16 “generating, from a video from a computer game, a three-dimensional (3D) representation of space comprising Gaussians representing objects in the video, wherein the 3D representation [[being]]is generated using metadata from the computer game, wherein the metadata comprises a z-buffer, and wherein the 3D representation is generated by generating a depth map for each frame of the video using the z-buffer and creating a point cloud for each frame based on the depth map; ” that “Swann's depth buffer values and point cloud datasets are not used to generate a 3D representation of space generating a depth map for each frame of the video using the z-buffer and creating a point cloud for each frame based on the depth map, as now recited by Claim 9. Swann accumulates geographical positioning data asynchronously over a long-term sequence of video captures to construct a permanent, cumulative environment trace map. Swann, however, fails to disclose or suggest an architecture that parses a live, executing metadata stream frame-by-frame at runtime to generate a transient, instantaneous depth map and corresponding point cloud scaffold.”. In response the examiner contests that this appears to be Applicant’s own conclusion rather than evidence. In contrast Swann clearly teaches generating, from a video from a computer game, a three-dimensional (3D) representation of space comprising Gaussians representing objects in the video, wherein the 3D representation is generated using metadata from the computer game (Fig 14, abstract, [0168]-[0169], [0234]-[0235] “obtaining a corresponding sequence of depth buffer values for a depth buffer used by the videogame whilst creating the video images, and for each of a plurality of video images and corresponding depth buffer values of the obtained sequences, obtain mapping points corresponding to a sampling distribution of points over the area of a respective video image and their associated depth values; wherein respective mapping points are obtained by projecting co-ordinated derived from the sample points from the video image and associated depth values back into a 3D game world co-ordinate system of the videogame title; thereby obtaining a point cloud dataset of mapping points corresponding to the first sequence of video images. …a sampling distribution of positions over the area of the video image corresponds to the predetermined set of positions within a respective video image…. a Gaussian sample distribution centred on the image centre.”, [0249]-[0253] etc. Swann further teaches wherein the metadata comprises a z-buffer, and wherein the 3D representation is generated by generating a depth map for each frame of the video using the z-buffer (Figs 3-4, abstract, [0040]-[0041], [0045]); and creating a point cloud for each frame based on the depth map (abstract, Figs 12-14, abstract, [0168]-[0169], [0234] etc, wherein depth values are projected to obtain the 3D coordinates of the sampled points resulting in the 3D point cloud with a gaussian representaion. This is identical to applicants own disclosure in Fig 6, [0073]-[0075] “a computer game video with metadata accessible from the game engine is received. Moving to state 602, the z-buffer is extracted from game engine shader pipeline to generate a depth map for each frame… a point cloud is created for at least the first frame. .. Once the point cloud is created, state 606 indicates that an initial set of Gaussians is created for each point in the cloud.” In addition “encompass both pre-recorded video (e.g. uploaded to a web-based host or streaming server) and also live video (again for example uploaded to a streaming server)… a streaming game service such as PS NOW® could output both colour video and depth encoding video, which could be used for rendering virtual objects within the live game.” in Swann [0134]- [0135] and [0163] ”the image data, depth data, virtual camera position, orientation, and field-of-view, data may be obtained directly from the game whilst being run… a map dataset can be obtained by calculating map points whilst playing the game, or during playback of video ..” clearly indicated all the processing performed live/streaming, although the claims do not require this feature.
Therefore as clearly set forth above, the applied references not only satisfies the claimed requirement, also identical to Applicant’s own disclosure. Hence rejection of the claims 1, 9 and 16 are maintained.
Dependent claims 6-8, 10, 14, 17-19 stand rejected for depending on the rejected base claims. In addition the applied references teaches the limitations of new claims 22-23, 25-29 as set forth in this office action.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 7-8, 22-23 are rejected under 35 U.S.C. 103 as being unpatentable over Swann et al (US 20210178266 A1), in view of Ricard et al (US 20250211784 A1), and further in view of Frazzini et al (US 20160094866 A1).
RE claim 1, Swann teaches An apparatus comprising: at least one processor system (Fig 1 #20, [0027]) configured to:
receive information from a computer game, the information comprising video and game metadata (Fig 5, [0081]-[0083]);
and using the information, convert at least one scene in the video to a three-dimensional (3D) representation of space comprising at least a first volumetric representation of at least a first object in the video, wherein the at least one scene in the video is converted to the 3D representation of space by extracting out scene geometry from a shader pipeline associated with the computer game and then down-sampling a number of mesh vertexes into a point cloud (Fig 14S1540-1544, abstract, [0093] [0168]-[0169], [0234]-[0235] “obtaining a corresponding sequence of in-game virtual camera positions at which the video images were created, obtaining a corresponding sequence of depth buffer values for a depth buffer used by the videogame whilst creating the video images, and for each of a plurality of video images and corresponding depth buffer values of the obtained sequences, obtain mapping points corresponding to a sampling distribution of points over the area of a respective video image and their associated depth values; wherein respective mapping points are obtained by projecting co-ordinated derived from the sample points from the video image and associated depth values back into a 3D game world co-ordinate system of the videogame title; thereby obtaining a point cloud dataset of mapping points corresponding to the first sequence of video images. In this case, a sampling distribution of positions over the area of the video image corresponds to the predetermined set of positions within a respective video image. The sampling may be 1:1 (i.e. all pixels of the video image) or a sub-sampling, such as 1:2 (i.e. a chequerboard) or 1:4 (e.g. one pixel per 2×2 block of pixels).” Wherein the first derived points are the mesh vertices that are downsampled with the subsampled to obtain the point cloud with a coarser density in the GPU pipeline, identical to the functionality of shader pipeline disclosed in applicants own disclosure in Fig 6, [0073]-[0074] “a computer game video with metadata accessible from the game engine is received. Moving to state 602, the z-buffer is extracted from game engine shader pipeline to generate a depth map for each frame… a point cloud is created for at least the first frame. One technique for generating the point cloud is to do so uniformly over each 3D space occupied by an object based on the depth maps generated by multiple camera views of a frame. Another technique to generate the point cloud is to do so by extracting out the scene geometry (meshes) from the shader pipeline, and then down-sampling the number of mesh vertexes into a point cloud representation. Note that to generate point clouds from multiple camera views, in addition to the depth map, camera parameters should be received.” performing the same functionality, wherein shader pipline is well known in prior art. For example, Ricard teaches identical typical GPU shader functionality (pipeline) where images/depthmaps are converted to mesh geometry in the GPU shader pipeline [0178], generate point cloud from extracted geometry (mesh/depth map) using the rasterization in typical shader pipeline followed by down-sampling the mesh vertexes [0005], [0096], [0180]-[0181], [0315] etc reducing the pointcloud complexity. This is readily available in Swann to effectively generate the 3D pointcloud applying GPU game engine (Fig 1, [0027]).)
Swann as modified by Ricard is silent RE: set opacity to zero for all objects in the 3D representation of space except for portions of the user-input content to establish a mask; and combine the mask with the video. However Frazzini teaches in [0080]-[0081], [0140], [0151] wherein the alpha mask set opacity to zero for all objects except for the particular object.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include in Swann as modified by Ricard a system and method to set opacity to zero for all objects in the 3D representation of space except for portions of the user-input content to establish a mask; and combine the mask with the video, as suggested by Frazzini, in order to effectively insert the user content and thereby ensuring system effectiveness and user experience.
RE claim 7, Swann teaches wherein the user-input content comprises a drawing of a path through a game world ([0128], [0131]).
RE claim 8, Swann teaches wherein the processor system is configured to: responsive to identifying at least a first portion of the user-input content as being occluded by the first volumetric representation, not render the first portion of the user-input content ([0093]).
RE claim 22, Swann as modified by Ricard and Frazzini teaches wherein the user-input content comprises a drawing of a path through a game world, and the at least one processor system is configured to dynamically alter the drawing of the path to automatically route around an intervening obstacle responsive to game metadata indicating that the obstacle has dropped into the path (Swann [0064], [0086], [0088], [0095]-[0096]).
RE claim 23, Swann as modified by Ricard and Frazzini teaches wherein the at least one processor system is further configured to: extract shared group settings from a game network and visually highlight a specific portion of the user-input content in response to the shared group settings indicating a threshold density of historical player interest in a corresponding game space area (Swann [0093], [0097], [0110], [0121], [0124]. In addition Frazzini [0080]-[0081], [0140], [0151]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Swann as modified by Ricard and Frazzini, and further in view of Fei et al (Fei B, Xu J, Zhang R, Zhou Q, Yang W, He Y. 3d gaussian splatting as new era: A survey. IEEE Transactions on Visualization and Computer Graphics. 2024 May 7.).
RE claim 6, Swann teaches wherein the processor system is configured to: create an initial set of Gaussians for each point in the point cloud ([0234]-[0235]); and read camera poses from the metadata ([0158]-[0160], [0158], [0044]-[0045]).
Swann as modified by Ricard and Frazzini is silent RE scale the Gaussians based on vertex normals associated with the point cloud; and use the Gaussians and camera poses to execute Gaussian splatting to generate the 3D representation of space.
However Fei teaches in abstract, page 4430 col 1, page 4432 col 2-page 4433 to provide efficient and accurate representation of geometry and appearance properties utilizing the Gaussian splatting.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include in Swann as modified by Ricard and Frazzini a system and method to scale the Gaussians based on vertex normals associated with the point cloud; and use the Gaussians and camera poses to execute Gaussian splatting to generate the 3D representation of space, as suggested by Fei, in order to generate efficient and accurate representation of geometry and appearance properties and thereby increasing system effectiveness and user experience.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Swann as modified by Ricard and Frazzini, and further in view of Gruber et al (US 20150379663 A1).
RE claim 21, Swann as modified by Ricard and Frazzini teaches wherein combining the mask with the video comprises rendering the user-input content via a tile-based rasterizer executed through a graphics processing unit (GPU) parallelization architecture where each parallel unit of block and thread corresponds to a rectangular image area and accumulations of color and transparency are processed according to an object list (Swann Figs 1,6-10, [0033], [0047] [0135], Ricard [005] and [0178], and Frazzini [0080]-[0081], [0140], [0151]).
Swann as modified by Ricard and Frazzini is silent RE a depth-sorted object list. However Gruber teaches in [0049] in order to determine order of objects for rendering.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include in Swann as modified by Ricard and Frazzini a depth-sorted object list, as suggested by Gruber in order to effectively render the objects in order and thereby increasing system effectiveness and user experience.
Claim 24 is rejected under 35 U.S.C. 103 as being unpatentable over Swann as modified by Ricard and Frazzini, and further in view of O’Neil et al (US 20250078389 A1).
RE claim 24, Swann as modified by Ricard and Frazzini teaches wherein the at least one processor system is configured to dynamically shade the user-input content based on volumetric parameters extracted from the video or game metadata (Swann [0096]).
Swann as modified by Ricard and Frazzini is silent RE lighting parameters. However O’Neil; teaches in abstract, [0025] for providing realistic lighting.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include in Swann as modified by Ricard and Frazzini lighting parameters, as suggested by O’Neil for providing realistic lighting and thereby increasing system effectiveness and user experience.
Claims 9-10, 16-19, 25-29 are rejected under 35 U.S.C. 103 as being unpatentable over Swann et al, in view of Frazzini et al.
RE claim 9, Swann teaches A method (abstract) comprising:
generating, from a video from a computer game, a three-dimensional (3D) representation of space comprising Gaussians representing objects in the video, wherein the 3D representation is generated using metadata from the computer game(Fig 14, [0168]-[0169] [0234]-[0235], [0249]-[0253]), wherein the metadata comprises a z-buffer, and wherein the 3D representation is generated by generating a depth map for each frame of the video using the z-buffer (Figs 3-4, abstract, [0040]-[0041], [0045]); and creating a point cloud for each frame based on the depth map (abstract, Figs 12-14, [0168]-[0169]). and
inserting into the 3D representation of space a user-input content (Fig 8, [0128]-[0129]).
Swann is silent RE: setting opacity of the Gaussians in the 3D representation of space to zero such that Gaussians representing objects in the video are transparent and only one or more portions of the user-input content are not transparent; and combining the 3D representation of space with the video. However Frazzini teaches in [0080]-[0081], [0140], [0151] wherein the alpha mask set opacity to zero for all objects as transparent except for the particular object set as not transparent.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include in Swann a system and method of setting opacity of the Gaussians in the 3D representation of space to zero such that Gaussians representing objects in the video are transparent and only one or more portions of the user-input content are not transparent; and combining the 3D representation of space with the video, as suggested by Frazzini, in order to effectively insert the user content and thereby ensuring system effectiveness and user experience.
RE claim 10, Swann teaches wherein the user-input content comprises a drawing of a path through a game world ([0128], [0131]).
Claims 16-17, 19 recite limitations similar in scope with limitations in claims 9-10, and therefore rejected under same rationale. In addition Swann teaches A device, comprising: computer memory not a transitory signal (Fig 1, [0027]).
RE claim 18, Swann as modified by Frazzini teaches wherein the instructions are executable to: align the user-input content with at least one of the volumetric representations; and responsive to a portion of the user-input content being blocked from a camera view by one of the volumetric representations, set an opacity of the portion to zero (Swan [0040], [0093], Frazzini [0080]-[0081], [0140], [0151]).
RE claim 25, Swann as modified by Frazzini teaches further comprising: executing a density control strategy on the three-dimensional (3D) representation of space by pruning away a subset of the Gaussians whose opacity falls below a predetermined threshold to output a compact dynamic Gaussian representation requiring less storage space (Swann [0093], [0097], Frazzini [0080]-[0081], [0140], [0151]).
RE claim 26, Swann as modified by Frazzini teaches further comprising: physically altering the appearance of the user-input content by animating the user-input content to melt, freeze, or dissolve based on environmental scene context parameters extracted from the computer game metadata (Swann [0088], Frazzini [0001], wherein the claimed animation effects are obvious design choice, are known in gaming applications).
RE claim 27, Swann as modified by Frazzini teaches wherein the user-input content is configured to inherit structural properties of an existing object within a game scene such that the user-input content hovers over the existing object and dynamically moves along a kinetic trajectory specified by that existing object (Swann [0064], [0086], [0088], [0095]-[0097]).
RE claim 28, Swann as modified by Frazzini teaches wherein combining the 3D representation of space with the video comprises mapping device coordinates to texture coordinates using an inverse process of forward rendering, interpolating depths to recover a depth value for each pixel, and rendering the user-input content via a parallelized GPU execution unit (Swann Figs 1,6-10, [0033], [0047], [0091]-[0092], [0135]).
RE claim 29, Swann as modified by Frazzini teaches wherein the user-input content comprises a game path, and the instructions are executable by the at least one processor system to dynamically alter coordinates of the game path to automatically morph around a newly introduced object in response to game metadata indicating a structural change in a runtime scene context (Swann [0064], [0086], [0088], [0095]-[0097]).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Swann as modified by Frazzini, and further in view of Fei et al.
RE claim 14, Swann teaches further comprising: create an initial set of Gaussians for each point in the point cloud ([0234]-[0235]); and read camera poses from the metadata ([0158]-[0160], [0158], [0044]-[0045]).
Swann as modified by Frazzini is silent RE scale the Gaussians based on vertex normals associated with the point cloud; and use the Gaussians and camera poses to execute Gaussian splatting to generate the 3D representation of space.
However Fei teaches in abstract, page 4430 col 1, page 4432 col 2-page 4433 to provide efficient and accurate representation of geometry and appearance properties utilizing the Gaussian splatting.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include in Swann as modified by Frazzini a system and method to scale the Gaussians based on vertex normals associated with the point cloud; and use the Gaussians and camera poses to execute Gaussian splatting to generate the 3D representation of space, as suggested by Fei, in order to generate efficient and accurate representation of geometry and appearance properties and thereby increasing system effectiveness and user experience.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 6-10, 14, 16-17 and 19 provisionally are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 3, 6-8, 10, 12, 16-17 and 19 of Copending US Application#18781870.
Table 1 illustrates the conflicting claim pairs:
Present Application
1
6-7
9-10
14
16-17
19
US application#18781870
7
8, 3
6/10, 12
8
6/16,17
19
Table 2 illustrates the conflicting claim pair with mapping, with the differences shown in bold form.
Claim 1 of present App.
Claim 7 of US Application#18781870
An apparatus comprising: at least one processor system configured to:
An apparatus comprising: at least one processor system configured to:
receive information from a computer game, the information comprising video and game metadata;
receive information from a computer game, the information comprising video and game metadata;
using the information, convert at least one scene in the video to a three-dimensional (3D) representation of space comprising at least a first volumetric representation of at least a first object in the video, wherein the at least one scene in the video is converted to the 3D representation of space by extracting out scene geometry from a shader pipeline associated with the computer game and then down-sampling a number of mesh vertexes into a point cloud;
using the information, convert at least one scene in the video to a three-dimensional (3D) representation of space comprising at least a first volumetric representation of at least a first object in the video; wherein processor system is configured to create a point cloud by extracting out scene geometry from a shader pipeline associated with the computer game, and then down-sample a number of mesh vertexes into the point cloud.
receive user-input content;
receive user-input content;
insert the user-input content into the 3D representation of space;
insert the user-input content into the 3D representation of space;
set opacity to zero for all objects in the 3D representation of space except for portions of the user-input content to establish a mask;
set opacity to zero for all objects in the 3D representation of space except for portions of the user-input content to establish a mask;
and combine the mask with the video from the computer game such that the user-input content appears in the computer game.
combine the mask with the video from the computer game such that the user-input content appears in the computer game; and animate the user-input content according to the game metadata.
As seen from the table all elements of claim 1 of application are anticipated by Claim 7 of US application#18781870 with some additional elements absent from the current application.
In addition elements of claims 6-7 of the application are anticipated by Claims 8, 3 of US application#18781870 as shown in table 1.
Claims 9-10 and 14 recite limitations similar in scope with limitations in claims 6-7 and therefore rejected under same rationale. Additionally claim 10 of application#18781870 teaches A corresponding method. In addition claim 6 of application#18781870 teaches wherein the metadata comprises a z-buffer, and wherein the 3D representation is generated by generating a depth map for each frame of the video using the z-buffer and creating a point cloud for each frame based on the depth map;
In addition elements of claims 16-17 and 19 of the application are anticipated by Claims 16-17 and 19 of US application#18781870 as shown in table 1. In addition claim 6 of application#18781870 teaches wherein the metadata comprises a z-buffer, and wherein the 3D representation is generated by generating a depth map for each frame of the video using the z-buffer and creating a point cloud for each frame based on the depth map.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims 1, 9 and 16 provisionally are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 6-7, 10 and 16 of Copending US Application#18/781,823.
Table 1 illustrates the conflicting claim pairs:
Present Application
1
9
16
US application#18/781,823
7
6/10
6/16
Table 2 illustrates the conflicting claim pair with mapping, with the differences shown in bold form.
Claim 1 of present App.
Claim 7 of US Application#18/781,823
An apparatus comprising: at least one processor system configured to:
An apparatus comprising: at least one processor system configured to:
receive information from a computer game, the information comprising video and game metadata;
receive information from a computer game, the information comprising video and game metadata;
using the information, convert at least one scene in the video to a three-dimensional (3D) representation of space comprising at least a first volumetric representation of at least a first object in the video, wherein the at least one scene in the video is converted to the 3D representation of space by extracting out scene geometry from a shader pipeline associated with the computer game and then down-sampling a number of mesh vertexes into a point cloud;
using the information, convert at least one scene in the video to a three-dimensional (3D) representation of space comprising at least a first volumetric representation of at least a first object in the video; wherein processor system is configured to create a point cloud by extracting out scene geometry from a shader pipeline associated with the computer game, and then down-sample a number of mesh vertexes into the point cloud.
receive user-input content;
receive user-input content;
insert the user-input content into the 3D representation of space;
insert the user-input content into the 3D representation of space;
set opacity to zero for all objects in the 3D representation of space except for portions of the user-input content to establish a mask;
set opacity to zero for all objects in the 3D representation of space except for portions of the user-input content to establish a mask;
and combine the mask with the video from the computer game such that the user-input content appears in the computer game.
and combine the mask with the video from the computer game such that the user-input content appears in the computer game wherein the user-input content comprises a mesh, and the processor system is configured to alter a texture of the mesh and/or topology of the mesh according to the game metadata.
As seen from the table all elements of claim 1 of application are anticipated by Claim 1 of US application#18/781,823 with some additional elements absent from the current application.
Claim 9 recites limitations similar in scope with limitations in claim 1 and therefore rejected under same rationale. Additionally claim 10 of Patent #11276246 teaches A corresponding method. In addition claim 6 of application#18781823 teaches wherein the metadata comprises a z-buffer, and wherein the 3D representation is generated by generating a depth map for each frame of the video using the z-buffer and creating a point cloud for each frame based on the depth map;
In addition elements of claim 16 of the application are anticipated by Claim 16 of US application#18/781,823 as shown in table 1. In addition claim 6 of application#18781823 teaches wherein the metadata comprises a z-buffer, and wherein the 3D representation is generated by generating a depth map for each frame of the video using the z-buffer and creating a point cloud for each frame based on the depth map;
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (See attached 892).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SULTANA MARCIA ZALALEE whose telephone number is (571)270-1411. The examiner can normally be reached Monday- Friday 8:00am-4:30pm.
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, Kent Chang can be reached on (571)272-7667. 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.
/Sultana M Zalalee/ Primary Examiner, Art Unit 2614
Prosecution Insights