DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . The Amendment filed 11 May 2026 (hereinafter “the Amendment”) has been entered and considered. Claims 1, 5-6, 8, 11-12, 17-19, and 21 have been amended. Claims 15-16 have been canceled. Claims 1-14 and 17-21 are all the claims pending in the application. Claims 1-14 and 21 are rejected. Claims 17-20 are objected to. All new grounds of rejection set forth in the present action were necessitated by Applicant’s claim amendments; accordingly, this action is made final.
Response to Amendment
Claim Rejections - 35 USC § 112
In view of the amendments to claims 5-6, 11, 17, and 21, the rejections under 35 USC 112 are withdrawn.
Prior Art Rejections
Independent claims 1 and 21 have been amended to incorporate features from dependent claim 8 and now-canceled dependent claims 15 and 16. On page 13 of the Amendment, Applicant asserts that the independent claims now recite the allowable subject matter of previously-objected-to claim 16, thus alleging that the independent claims are allowable. The Examiner notes, however, that claim 16 was dependent on all of claims 1, 8, and 10-15. That is, Applicant has failed to include all of the subject matter of previous claim 16; rather, Applicant has selected particular features from some of the intervening claims to incorporate into the independent claims. As such, the scope of the independent claims are not commensurate with the scope of the claim that the Examiner indicated as allowable in the previous action. Therefore, the claims are rejected, as set forth below.
On pages 11-13 of the Amendment, Applicant argues that Zargahi does not teach or suggest “generating parameterized calls based on input parameters”, “sending parameterized calls to the one image processing tool” and “generating the customized imagery based on the input parameters”. In support, Applicant asserts that the “identified parameters” are not included in the calls but are instead generated from them and that that the “asset-variation parameters” are outputs within the synthetic data assets generated from the requests, rather than inputs to the request. The Examiner respectfully submits that Applicant has mischaracterized the reference and maintains that the limitations in question are indeed taught by Zargahi.
For example, how can the training datasets be generated with the identified parameters if those parameters are not communicated in the call in the first place? The only way for the tool to generate the training datasets with the identified parameters is for the parameters to be included in the call that requests the training datasets. Otherwise, the tool would not be able to create training datasets that comply with the identified parameters. This is supported throughout Zargahi:
[0045] (emphasis added) “As such, in some embodiments, suggested variation parameters for a particular scenario can be presented to facilitate generating a frameset package. Relevant variation parameters can be designated by a seeding taxonomy that associates machine learning scenarios with a relevant subset of variation parameters. Generally, a user interface can be provided that facilitates scene generation and/or frameset generation. Upon identification of a particular machine learning scenario, the subset of variation parameters associated with the scenario in the seeding taxonomy can be accessed and presented as suggested variation parameters. The seeding taxonomy can be predetermined and/or adaptable. An adaptable seeding taxonomy may be implemented using a feedback loop that tracks selected variation parameters and updates the seeding taxonomy based on a determination that selected variation parameters for a frameset generation request differ from the suggested variation parameters in the seeding taxonomy. As such, the presentation of suggested variation parameters assists users to identify and select relevant variation parameters faster and more efficiently. In some cases, the presentation of suggested variation parameters prevents the selection of ineffective variation parameters and the concomitant expenditure of unnecessary computing resources.”
[0047] (emphasis added) “The user interface that facilitates scene generation and/or frameset generation can facilitate an identification of a desired machine learning scenario (e.g., based on a user input indicating a desired scenario). A list or other indication of the subset of variation parameters associated with the identified scenario in the seeding taxonomy can be accessed and presented as suggested variation parameters via the user interface. For example, the user interface may include a form that accepts an input indicting one or more machine learning scenarios. The input can be via a text box, drop down menu, radio button, checkbox, interactive list, or other suitable input. The input indicting a machine learning scenario can trigger a lookup and presentation of relevant variation parameters maintained in the seeding taxonomy. The relevant variation parameters can be presented as a list or other indication of suggested variation parameters for a selected machine learning scenario. The user interface can accept an input indicating a selection of one or more of the suggested variation parameters and/or one or more additional variation parameters. As with the input indicating a machine learning scenario, the input indicating selected variation parameters can be via a text box, drop down menu, radio button, checkbox, interactive list, or other suitable input. The input indicting selected variation parameters can cause a frameset package to be generated using the selected variation parameters, and the frameset package can be made available, for example, by download or otherwise.”
[0082] (emphasis added) “Returning to FIG. 1A, in some embodiments, suggested variation parameters for a particular machine learning scenario can be presented to facilitate generating a frameset package. Relevant variation parameters can be designated by seeding taxonomy 140, which associates machine learning scenarios with corresponding relevant subsets of variation parameters. Upon identification of a particular machine learning scenario via a user interface that facilitates scene generation and/or frameset generation (e.g., interface 128B or 128C), a subset of variation parameters associated with the identified scenario in seeding taxonomy 140 can be accessed and presented as suggested variation parameters. One or more of the suggested variation parameters and/or one or more additional variation parameters can be selected, frameset assembly engine 114 can generate framesets (e.g., images) by varying the selected variation parameters (e.g., asset and/or scene-variation parameters), and frameset package generator 116 can generate a frameset package with the generated framesets.”
[0083] (emphasis added) “Generally, a user (e.g., a customer, data scientist, etc.) may seek to generate a frameset package (i.e., a synthetic dataset) for training a particular machine learning model. At a high level, a user interface may be provided (e.g., interface 128B or 128C) that facilitates scene generation and/or frameset generation. For example, the user interface may allow the user to design or otherwise specify a 3D scene (e.g., using 3D modeling software). The user interface may allow the user to specify one or more variation parameters to be varied in generating different framesets (e.g., images based on the 3D scene) for a frameset package. The number of potential variation parameters is theoretically unlimited. However, not all parameters can be varied to produce a frameset package that will improve the accuracy of a machine learning model for a given scenario.”
[0086] (emphasis added) “In some embodiments, the user interface that facilitates scene generation and/or frameset generation (e.g., interface 128B or 128C) can facilitate an identification of a desired machine learning scenario (e.g., based on a user input indicating a desired scenario). A list or other indication of the subset of variation parameters associated with the identified scenario in seeding taxonomy 140 can be accessed and presented as suggested variation parameters via the user interface. For example, the user interface may include a form that accepts an input indicting one or more machine learning scenarios. The input can be via a text box, drop down menu, radio button, checkbox, interactive list, or other suitable input. The input indicting a machine learning scenario can trigger a lookup and presentation of relevant variation parameters maintained in seeding taxonomy 140. The relevant variation parameters can be presented as a list or other indication of suggested variation parameters for a selected machine learning scenario. The user interface can accept an input indicating a selection of one or more of the suggested variation parameters and/or one or more additional variation parameters. As with the input indicating a machine learning scenario, the input indicating selected variation parameters can be via a text box, drop down menu, radio button, checkbox, interactive list, or other suitable input. The input indicting selected variation parameters can be used by frameset assembly engine 114 to generate framesets (e.g., images) by varying the selected variation parameters, and frameset package generator 116 can generate a frameset package with the generated framesets. The frameset package can be made available, for example, by download or otherwise.”
[0101] (emphasis added) “In some embodiments, command component 774 may communicate with a command interface associated with client device 705. A user can input a command using the command interface, and the command can be transmitted to command component 774 for execution. Command component 774 can accept and execute various commands, including commands to assign a resource to process a synthetic data request, batch the creation of synthetic assets or the processing of some other synthetic data request, change or automatically target a particular outcome (e.g., processing time, cost, output quality, etc.), and the like. Command component 774 may support execution of commands even after beginning to process a request (mid-request).”
[0102] (emphasis added) “For example, command component 774 can accept and execute a command to assign resources to process a synthetic data request. By way of nonlimiting example, processing a request to create a large number of synthetic data assets can take on the order of hours. While, feedback component 772 can provide information about the processing of the request (progress, allocated resources, resource consumption, etc.), command component 774 can allow a user to impact the manner in which the request is processed. For example, assume a request to generate 50 k assets has begun processing, and 10 k assets have been generated using CPUs 740. A user may prefer to speed up processing. In this situation, the user can issue a command via command component 774 to generate the remaining synthetic data assets using GPUs 750. Command component 774 can execute such a command in various ways. For example, command component 774 can identify corresponding synthetic data tasks that have not yet been routed or assigned to CPUs 740 (e.g., by identifying the synthetic data tasks queued in CPU queue 720 and/or hybrid queue 724), and can reclassify the synthetic data tasks for processing on GPUs 750 (e.g., by moving the synthetic data tasks to GPU queue 722). As such, scheduler 730 can pick up the synthetic data tasks from GPU queue 722 and route or otherwise assign them for processing on GPUs 750. In this manner, a user can manually change a resource allocation (e.g., a task classification) on the fly by issuing a command via progress portal 770.”
Clearly, the “identified parameters” have been selected by a user and must be communicated in the call requesting the “training datasets having the identified parameters”. That is, contrary to Applicant’s assertions, the identified parameters are not only outputs; they are clearly part of the input request. Thus, Zargahi does indeed disclose “generating parameterized calls based on input parameters”, “sending parameterized calls to the one image processing tool” and “generating the customized imagery based on the input parameters” since the input parameters are part of the calls requesting the training datasets, and the training datasets returned to the user are generated by the tool to comply with the identified parameters. As such, the prior art rejections based on Zargahi are maintained.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 5-10 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2020/0090001 to Zargahi et al. (hereinafter “Zargahi”) in view of U.S. Patent Application Publication No. 2021/0227276 to Mayol Cuevas et al. (hereinafter “Mayol Cuevas”) and further in view of U.S. Patent Application Publication No. 2022/0237336 to Zhao et al. (hereinafter “Zhao”).
As to independent claim 1, Zargahi discloses a method for generating customized imagery, the method comprising: storing, in memory of a computing device, program code for generating an application programming interface (API) that communicates with plural disparate image processing tools; executing, by a computing device, the program code for generating the API; the API causing the computing device to perform operations (Abstract, [0036, 0053, 0094-0098, 0143] disclose that Zargahi is directed to “implementing a distributed computing system that provides synthetic data as a services (‘SDaaS’)”, wherein SDaaS is a “cloud” computing system “that allows customers to configure, generate, access, manage, and process synthetic data training datasets for machine learning” and “can include an API library” which “may support the interaction between hardware architecture of the device and the software framework” of the SDaaS; Figs. 6-7 show an example environment 600/700 in which requests from a client 705 are received and managed by a scheduler 630/730 of the SDaaS which “can select tasks from the queue for routing or assignment for processing on CPUs 640 and GPUs 650”, wherein the disparate CPUs 640/740 and GPUs 650/750 “render images” and perform “image processing”) that include: establishing communication with each image processing tool ([0092] discloses that a management layer of the SDaaS “orchestrates a resource allocation between CPUs 640 and GPUs 650 to process synthetic data tasks” which presupposes communication has been established); receiving input parameters that define operations including synthetic image generation to be performed by one of the plural disparate image processing tools in generating a customized image and that define attributes of the customized imagery to be generated ([0006, 0058, 0083] discloses that “a client may submit a synthetic data request to create 50 k synthetic data assets (e.g., images) from a selected source asset (e.g., a 3D model)”, wherein “training datasets are generated by altering intrinsic parameters and extrinsic parameters of synthetic data assets (e.g., 3D models) or scenes (e.g., 3D scenes and videos)...based on intrinsic-parameter variation (e.g., asset shape, position and material properties) and extrinsic-parameter variation (e.g., variation of environmental and/or scene parameters such as lighting, perspective)”, wherein the parameters are input by a user); generating parameterized calls based on the input parameters, the parameterized calls providing instructions for the one image processing tool configured to generate the customized image; sending parameterized calls to the one image processing tool ([0061] discloses “real-time calls to APIs or services to generate relevant training datasets having [the] identified parameters”; in particular, [0082-0086, 0101-0102] discloses that “A user can input a command using the command interface, and the command can be transmitted to command component 774 for execution”, wherein “scheduler 730 can pick up the synthetic data tasks from GPU queue 722 and route or otherwise assign them for processing on GPUs 750” (image processing tools), wherein “user interface may allow the user to specify one or more variation parameters to be varied in generating different framesets (e.g., images based on the 3D scene) for a frameset package”); generating the customized imagery based on the input parameters by: executing the one image processing tool; and generating the synthetic video in the one image processing tool based on at least a scene identifier included in the input parameters ([0006, 0085-0097] of Zargahi discloses that a relevant set of variation parameters (e.g., asset-variation parameters, scene-variation parameters, etc.) is specified for each machine learning scenario in order to produce the frameset package and further that “training datasets are generated by altering intrinsic parameters and extrinsic parameters of synthetic data assets (e.g., 3D models) or scenes (e.g., 3D scenes and videos)...based on intrinsic-parameter variation (e.g., asset shape, position and material properties) and extrinsic-parameter variation (e.g., variation of environmental and/or scene parameters such as lighting, perspective)”, wherein the scene must be identified in order to be altered by the CPU or GPU (image processing tool)) by: recording the scene based on camera movements determined by the input parameters, and creating detection labels for the objects ([Fig. 4 and [0039-0044] discloses that “a user may generate a synthetic data scene (e.g., a 3D scene) that includes an environment (e.g., a piece of land) and various 3D assets (e.g., a car, a person, and a tree), wherein “variation parameters such as human body shape, latitude, longitude, angle of the sun, time of day, camera perspective, and camera position may be relevant”; that is, the camera position and perspective (camera movements) in the generated (recorded) synthetic scene are varied according to the user-selected “variation parameters”; the “assets” are objects in the generated scene, as shown in Fig. 4, wherein these objects are labeled, as taught in [0039]); receiving the customized imagery from the one image processing tool ([0091-0105] discloses that the client requests to generate synthetic training datasets are managed by a scheduler 630/730 of the SDaaS which “can select tasks from the queue for routing or assignment for processing on CPUs 640 and GPUs 650” which generate and return synthetic data assets according to “the asset-variation parameters”); and storing the received customized imagery in a database as training data for an artificial intelligence model ([0071-0072, 0104-0109, 0120-0121] discloses that the generated synthetic assets and framesets are stored in SDaaS store 126 for “machine learning training”).
Zargahi does not expressly disclose that the synthetic images are generated based on a scene type in the input parameters or calculating locations of objects in the recorded scene upon which the labels are based.
Mayol Cuevas, like Zargahi, is directed to a “video enhancement service” which manages user requests for the video enhancement using an “application programming interface (API) call” (Abstract and [0013-0014, 0018]). Mayol Cuevas discloses that the enhancement is made based on start and end time stamps that identify video frames/image, and “scene type” ([0057-0071] and Figs. 6-7).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zargahi to further perform the video alteration based on scene type, as taught by Mayol Cuevas, to arrive at the claimed invention discussed above. Such a modification is the result of combining prior art elements according to known methods to yield predictable results. It is predictable that the proposed modification would have allowed for enhancements particular to various scene types, thus providing more variety to a user making the request for video/image enhancement.
Zhao, like Zargahi, is directed to “generating training data to train a neural network” by “obtain[ing] 3D models of objects, and simulat[ing] 3D environments comprising the objects” (Abstract). Zhao discloses that a simulator may obtain the 3D models of objects, and generate training images comprising images of objects of the one or more objects in different orientations, locations, positions, environments, and/or lighting conditions and “labels comprising labels of classifications and locations of the objects” ([0117]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the proposed combination of Zargahi and Mayol Cuevas to calculate the locations of the objects in the generated scene and to create detection labels from those calculated locations, as taught by Zhao, to arrive at the claimed invention discussed above. Such a modification is the result of combining prior art elements according to known methods to yield predictable results. It is predictable that the proposed modification would have created extremely accurate labels by removing humans—and thus human error—from the labeling process.
As to claim 2, Zargahi as modified above further teaches that the operations involve an image transformation and the input parameters further identify an original video and a type of transformation to be performed ([0006, 0085] discloses that the machine learning scenario can include “video surveillance” and that a relevant set of variation parameters (e.g., asset-variation parameters, scene-variation parameters, etc.) is specified for each machine learning scenario in order to produce the frameset package) and further that “training datasets are generated by altering intrinsic parameters and extrinsic parameters of synthetic data assets (e.g., 3D models) or scenes (e.g., 3D scenes and videos)...based on intrinsic-parameter variation (e.g., asset shape, position and material properties) and extrinsic-parameter variation (e.g., variation of environmental and/or scene parameters such as lighting, perspective)”).
As to claim 3, Zargahi as modified above further teaches that the input parameters further identify one or more attributes of the original video that are to be modified to generate the customized imagery ([0006, 0085] discloses that the machine learning scenario can include “video surveillance” and that a relevant set of variation parameters (e.g., asset-variation parameters, scene-variation parameters, etc.) is specified for each machine learning scenario in order to produce the frameset package) and further that “training datasets are generated by altering intrinsic parameters and extrinsic parameters of synthetic data assets (e.g., 3D models) or scenes (e.g., 3D scenes and videos)...based on intrinsic-parameter variation (e.g., asset shape, position and material properties) and extrinsic-parameter variation (e.g., variation of environmental and/or scene parameters such as lighting, perspective)”).
As to claim 5, Zargahi does not expressly disclose that the step of sending parameterized calls further comprises: generating an instruction message having: an identifier that includes a name of the original video and a timestamp; and a body that includes the name of original video, and the identifier of the original video, and the one or more attributes of the original video to be transformed.
Mayol Cuevas, like Zargahi, is directed to a “video enhancement service” which manages user requests for the video enhancement using an “application programming interface (API) call” (Abstract and [0013-0014, 0018]). Mayol Cuevas discloses example API calls 601, 611, 701, and 711 in Figs. 6-7 which show that a call may include the video stream name, start and end time stamps, fragment IDs of the video, and the type, speed, and quality of the enhancement ([0062-0071]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zargahi to include in the API call are request message including the name of the video and timestamps, the name and identifier of the video, and attributes to be transformed, as taught by Mayol Cuevas, to arrive at the claimed invention discussed above. Such a modification is the result of combining prior art elements according to known methods to yield predictable results. It is predictable that the proposed modification would have clearly communicated the parameters of the requested video enhancement, thus improving the likelihood of satisfying the user’s desired enhancement.
As to claim 6, Zargahi further discloses that the computing device performs further operations including: loading the instruction message into a job queue of the one image processing tool; and delete the instruction message from the job queue ([0095] and Figs. 6-7 show an example environment 600/700 in which requests from a client 705 are received and managed by a scheduler 630/730 of the SDaaS which “can select tasks from the queue for routing or assignment for processing on CPUs 640 and GPUs 650”, wherein the queues include CPU queue, GPU queue, and hybrid queue, and wherein the request in the queue must be loaded in order to be performed and must be deleted in order to move on to the next request in the queue).
Zargahi does not expressly disclose extracting at least the name of the original video and the one or more attributes to be transformed; downloading the original video from memory; executing the one image processing tool to customize the original video using the one or more attributes; and uploading the customized video to memory.
Mayol Cuevas, like Zargahi, is directed to a “video enhancement service” which manages user requests for the video enhancement using an “application programming interface (API) call” (Abstract and [0013-0014, 0018]). Mayol Cuevas discloses a process flow in which a video requesting device 131 issues an API like the one discussed above in conjunction with claim 5 and shown in Figs. 6-7 which includes the name of the video and attributes to be transformed, a provider network 100 receives the request and retrieves the video from memory and performs the enhancement identified in the call using the appropriate ML enhancement model, and finally the enhanced video is uploaded to the video requesting device 131 (Figs. 1 and 4 and [0023-0027, 0041-0052]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zargahi to retrieve the video to be enhanced based on the name and identifying information in the API call, select an appropriate model/tool for performing the enhancement, and upload the enhanced video back to the requesting user device, as taught by Mayol Cuevas, to arrive at the claimed invention discussed above. Such a modification is the result of combining prior art elements according to known methods to yield predictable results. It is predictable that the proposed modification would have “allow[ed] for an API for a video to also request that the lower quality video be enhanced” ([0014] of Mayol Cuevas).
As to claim 7, Zargahi as modified above further teaches that customizing the original video includes: dividing the original video into plural frames; transforming each frame according to the one or more attributes; and compiling the plural transformed frames into the video format ([0077] of Zargahi discloses that the set of images of a scene are altered on a frame by frame basis which requires first dividing the video scene into frames and recompiling them into “the synthetic data scene frameset” after altering them according to “the scene-variation parameters”).
As to claim 8, Zargahi further discloses that the input parameters include the scene identifier, and an object identifier ([0006, 0085] discloses that a relevant set of variation parameters (e.g., asset-variation parameters, scene-variation parameters, etc.) is specified for each machine learning scenario in order to produce the frameset package and further that “training datasets are generated by altering intrinsic parameters and extrinsic parameters of synthetic data assets (e.g., 3D models) or scenes (e.g., 3D scenes and videos)...based on intrinsic-parameter variation (e.g., asset shape, position and material properties) and extrinsic-parameter variation (e.g., variation of environmental and/or scene parameters such as lighting, perspective)”, wherein the scene and the asset (object) must be identified in order to be altered). Zargahi does not expressly disclose that the input parameters include an image identifier, an image number, and the scene type.
Mayol Cuevas, like Zargahi, is directed to a “video enhancement service” which manages user requests for the video enhancement using an “application programming interface (API) call” (Abstract and [0013-0014, 0018]). Mayol Cuevas discloses that the enhancement is made based on start and end time stamps that identify video frames/image, and “scene type” ([0057-0071]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zargahi to further perform the video alteration based on identified frames and scene type, as taught by Mayol Cuevas, to arrive at the claimed invention discussed above. Such a modification is the result of combining prior art elements according to known methods to yield predictable results. It is predictable that the proposed modification would have allowed for enhancements particular to various scene types, thus providing more variety to a user making the request for video/image enhancement.
As to claim 9, Zargahi as modified above further teaches that the attributes include at least one of: camera angle, altitude, weather parameters, lighting parameters, an object type, and a number of images to capture ([0006, 0036] discloses that the extrinsic parameter variation may include lighting and perspective).
As to claim 10, Zargahi as modified above further teaches that the step of sending parameterized calls further comprises: generating a request message that includes at least the input parameters ([0062-0071] of Mayol Cuevas discloses example API calls 601, 611, 701, and 711 in Figs. 6-7 which show that a call may include the input parameters; the reasons for combining the references are the same as those discussed above in conjunction with claim 8).
Independent claim 21 recites a system for generating customized imagery, the system comprising: memory storing program code for generating an application programming interface (API) that communicates with plural disparate image processing tools (Abstract, [0036, 0053, 0094-0098, 0143] disclose that Zargahi is directed to “implementing a distributed computing system that provides synthetic data as a services (‘SDaaS’)”, wherein SDaaS is a “cloud” computing system “that allows customers to configure, generate, access, manage, and process synthetic data training datasets for machine learning” and “can include an API library” which “may support the interaction between hardware architecture of the device and the software framework” of the SDaaS; Figs. 6-7 show an example environment 600/700 in which requests from a client 705 are received and managed by a scheduler 630/730 of the SDaaS which “can select tasks from the queue for routing or assignment for processing on CPUs 640 and GPUs 650”, wherein the disparate CPUs 640/740 and GPUs 650/750 “render images” and perform “image processing”) and further recites steps recited in independent claim 1. Accordingly, claim 21 is rejected for reasons analogous to those discussed above in conjunction with claim 1.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Zargahi in view of Mayol Cuevas and Zhao and further in view of U.S. Patent Application Publication No. 2021/0004608 to Jaipuria et al. (hereinafter “Jaipuria”).
As to claim 4, Zargahi as modified above does not expressly disclose that the attributes include one or more style transfers to be performed on the original video.
Jaipuria, like Zargahi, is directed to generating synthetic videos used to train a deep neural network (Abstract and [0028-0031]). Jaipuria discloses that the generator may input a real video image from a first domain, such as sunny, and output video images from a user-selected other domain, such as winter, rain, night, etc. ([0029-0037]). Notably, the specification of the subject application provides examples of “a style transfer” as a “change in scenery based on weather, season, time of day, etc.” ([0036]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zargahi to generate the synthetic video as a style transfer specified by a user and performed on an original video, as taught by Jaipuria, to arrive at the claimed invention discussed above. Such a modification is the result of combining prior art elements according to known methods to yield predictable results. It is predictable that the proposed modification would have “improve[d] training the DNN” by virtue of training the model to be robust to “different environmental conditions”, as taught by Jaipuria ([0010]).
Claims 11-14 are rejected under 35 U.S.C. 103 as being unpatentable over Zargahi in view of Mayol Cuevas and Zhao and further in view of U.S. Patent Application Publication No. 2023/0107397 to Umakandan et al. (hereinafter “Umakandan”).
As to claim 11, Zargahi as modified above does not expressly disclose verifying that the one or more input parameters in the request message include at least the image identifier, the image number, the scene identifier, and the scene type. However, Umakandan discloses the “verifying of input parameters included in the API call” ([0042, 0048]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the proposed combination of Zargahi, Mayol Cuevas, and Zhao to verify that the API includes particular input parameters (such as the claimed input parameters taught by Zargahi and Mayol Cuevas, as discussed above in conjunction with claim 8), as taught by Umakandan, to arrive at the claimed invention discussed above. Such a modification is the result of combining prior art elements according to known methods to yield predictable results. It is predictable that the proposed modification would have ensured compliance of the API call, as an API call with missing parameters may “return an error” ([0043] of Umakandan).
As to claim 12, Zargahi as modified above further teaches that when the one or more input parameters are verified, the method comprises: generating an instruction message in the job queue of the one image processing tool that generates the synthetic images ([0042-0043] of Umakandan discloses that the API call returns an error if the input parameters are missing, but proceeds with the request otherwise; [0095] of Zargahi discloses that a scheduler 630/730 of the SDaaS which “can select tasks from the queue for routing or assignment for processing on CPUs 640 and GPUs 650”, wherein the queues include CPU queue, GPU queue, and hybrid queue; the reasons for combining the references are the same as those discussed above in conjunction with claim 11).
As to claim 13, Zargahi as modified above further teaches that the instruction message includes: an identifier that contains the scene identifier, the image identifier, and a timestamp; and a body that contains the scene identifier and the scene type ([0057-0071] and Figs. 6-7 of Mayol Cuevas discloses that the API call includes a fragment (scene) ID, start and end timestamps (each of which identify a video frame), and scene type; the reasons for combining the references are the same as those discussed above in conjunction with claim 8).
As to claim 14, Zargahi as modified above further teaches extracting the scene identifier and the scene type from the instruction message ([0026-0027] of Mayol Cuevas discloses that the video enhancement service enhances the video per the request according to the parameters in the API call which presupposes extracting the parameters; the reasons for combining the references are the same as those discussed above in conjunction with claim 8).
Allowable Subject Matter
Claims 17-20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims and if the above rejections under 35 USC 112 are overcome.
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Barbosa (U.S. Patent No. 11,341,367) discloses generating synthetic training data along with automatically generated labels that identify where in the generated images an object has been placed, together with a class identifier of each object. This results in accurate labels by removing human error from the labeling process. These teachings are relevant to the newly added features of the independent claims.
Conclusion
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 SEAN M CONNER whose telephone number is (571)272-1486. The examiner can normally be reached 10 AM - 6 PM Monday through Friday, and some Saturday afternoons.
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, Greg Morse can be reached at (571) 272-3838. 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.
/SEAN M CONNER/Primary Examiner, Art Unit 2663
Prosecution Insights