DETAILED ACTION
This office action is in response to claims filed 13 May 2026.
Claims 1-5, 8-9, and 11-21 are pending.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 13 May 2026 has been entered.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-5, 8-9, and 11-21 have been considered but are moot because they do not specifically challenge the new reference (GEWICKEY, cited below) used in the current rejection to address the limitations at issue.
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, and 20-21 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 11,861,410 B2 (hereafter REFERENCE PATENT), in view of ACAR et al. Patent No.: US 11,038,986 B1 (hereafter ACAR), in view of CONSUL et al. Pub. No.: US 2015/0105148 A1 (hereafter CONSUL), in view of Behind the Scenes with UE4’s Next-Gen Virtual Production Tools | Project Spotlight | Unreal Engine, accessible at https://www.youtube.com/watch?v=Hjb-AqMD-a4, on 12 November 2019 (hereafter UNREAL), in view of FICARRA et al. Patent No.: US 11,487,738 B1 (hereafter FICARRA), in view of CHANG et al. Pub. No.: US 2021/0144515 A1 (hereafter CHANG), in view of GEWICKEY et al. Pub. No.: US 2016/0191893 A1 (hereafter GEWICKEY).
Regarding claim 1 of the instant application, the following table illustrates the differences between that claim and claim 1 of the REFERENCE APPLICATION.
Instant Application
REFERENCE APPLICATION
1. A digital studio cloud computing provisioning system comprising:
a plurality of sensors associated with at least one rendering device;
at least one non-transitory computer readable memory storing software instructions; and
at least one processor coupled with the plurality of sensors and with the non-transitory computer readable memory, the at least one processor configured to perform the following operations upon execution of the software instructions:
provisioning a first set of cloud computing resources associated with at least one rendering task on the at least one rendering device, wherein the first set of cloud computing resources is associated with a burst criteria;
rendering and displaying images using light emitting diodes (LEDs) of a wall display of the at least one rendering device, according to the at least one rendering task, wherein the at least one rendering task includes real-time processing of scheduled video production of a design studio in a virtual studio environment, wherein the at least one rendering task includes real-time processing of scheduled video production of a design studio in a virtual studio environment;
monitoring at least one leading indicator relating to the first set of cloud computing resources, the at least one leading indicator derived at least in part from data from the plurality of sensors;
determining a number of additional resources for the at least one rendering task based on the plurality of sensors; and
upon satisfaction of the burst criteria by the at least one leading indicator, provisioning a second set of cloud computing resources for at least the number of additional resources for the at least one rendering task for the at least one rendering device
wherein provisioning the second set of cloud computing resources includes triggering provisioning of the second set of cloud computing resources in response to data from the plurality of sensors indicating a communication network transmission latency of greater than a specified number of milliseconds from a remote location, and selecting the second set of cloud computing resources based at least in part on a proximity of the remote location of the second set of cloud computing resources to the at least one rendering device,
wherein the burst criteria indicates a simulation which incurs resources for rendering, and the second set of cloud computing resources are provisioned when a burst is predicted during the simulation.
1. A cloud computing burst management system comprising:
a first cloud computing resource including a first processor and a first memory, the first cloud computing resource configured to perform at least one cloud computing task;
a second cloud computing resource including a second processor and a second memory; and
one or more data networks connecting the first cloud computing resource and the second cloud computing resource, wherein:
the first cloud computing resource is configured to monitor one or more leading indicator parameters associated with operation of the first cloud computing resource while performing the at least one cloud computing task;
in response to the one or more leading indicator parameters satisfying a first burst criteria, the first cloud computing resource is configured to provision a task instance on the second cloud computing resource for performing at least one portion of the cloud computing task;
and a third cloud computing resource, wherein:
the first cloud computing resource is configured to transfer said at least one portion of the cloud computing task to the provisioned task instance on the second cloud computing resource in response to the one or more leading indicator parameters satisfying a second burst criteria;
the second cloud computing resource is configured to perform the at least one portion of the cloud computing task;
the first cloud computing resource is configured to provision another task instance on the third cloud computing resource for performing at least one other portion of the cloud computing task in response to the one or more leading indicator parameters satisfying the first burst criteria;
the first cloud computing resource is configured to transfer said at least one portion of the cloud computing task from the provisioned task instance on the second cloud computing resource to the other provisioned task instance on the third cloud computing resource, in response to one or more leading indicator parameters of the provisioned task instance of the second cloud computing resource satisfying the second burst criteria;
the third cloud computing resource is configured to perform the transferred at least one portion of the cloud computing task; and
the first cloud computing resource is configured to provision different portions of the cloud computing task to the second cloud computing resource and to the third cloud computing resource, according to defined performance capabilities of the second cloud computing resource and to the third cloud computing resource that correspond to a defined property of each portion of the cloud computing task.
While claim 1 of the REFERENCE PATENT teaches determination of leading parameters that are used to allocate resources during a burst condition while executing a computing task, claim 1 of the REFERENCE PATENT does not explicitly teach the leading parameters are determined based on sensors.
However, in analogous art, ACAR teaches:
a plurality of sensors associated with at least one [device] ([Column 5, Lines 28-38] As shown, the metrics repository server 110 includes a monitoring service 111, metrics 112, and policies 113. In one embodiment, the monitoring service 111 collects the metrics 112 from components of the VPN 120 (e.g., the load balancer 121, cluster 122, and management server 124) (i.e., “plurality of sensors” because they monitor, or “sense” performance metrics of various components of the system). Generally, the metrics 112 are statistics observed in the cluster 122 and formatted by the monitoring service 111 as an ordered set of time-series data. For instance, metrics 112 can include statistics relating to resource utilization of the application servers 123 in the cluster 112, such as CPU resource utilization, latency, request counts, and so on (i.e., each resource utilization is implicitly collected by a “sensor” specific to that resource));
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined ACAR’s metrics repository server and sensors with claim 1 of the REFERENCE PATENT to realize, with a reasonable expectation of success, a system that collects metrics related to leading parameters, as in the REFERENCE PATENT, based on sensors that collect metrics from various cloud computing resources, as in ACAR. A person having ordinary skill would have been motivated to make this combination to monitor data from multiple different sources to get a better picture of resource utilization in a cloud system.
While claim 1 of the REFERENCE PATENT and ACAR discuss execution of computing tasks, the combination does not explicitly teach these tasks are rendering tasks, and displaying images…according to the at least one rendering task.
However, in analogous art, CONSUL teaches:
A digital studio cloud computing provisioning system; at least one rendering device; at least one rendering task; displaying images…according to the at least one rendering task ([0015] In some embodiments, the graphics rendering system (i.e., “rendering device”) may interface with a cloud platform (i.e., “digital studio cloud computing provisioning system”) that provides servers host virtual machines that each have access to a commodity GPU via a virtual GPU; such servers are referred to as GPU servers. A server of the cloud platform may execute a server-side component of a computer program that generates graphics scenes, submits render tasks to generate images of those graphics scenes, and sends those rendered images to client-side components for display. For example, the computer program may be a game program, and the client-side component may execute on devices of game players. When the computer program is launched on a server, the graphics rendering system may allocate virtual machines hosted by different GPU servers for rendering the images of the computer program. The virtual machines execute code that may be part of the graphics rendering system and that receives render tasks, directs the virtual GPU to perform the render tasks, and provides the rendered image as the result of the render task);
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have simply substituted CONSUL’s digital studio cloud computing provisioning system having resources allocatable to a rendering device performing rendering tasks, into REFERENCE PATENT and ACAR’s cloud provisioning system having resources allocatable to a device performing tasks, because 1) ACAR contained a cloud provisioning system having resources allocatable to a device performing tasks, which differs from the claimed invention in that the cloud provisioning system was not a “digital studio cloud computing provisioning system”, the device was not a “rendering device” and the task was not a “rendering task”, 2) CONSUL teaches a digital studio cloud computing provisioning system having resources allocatable to a rendering device performing rendering tasks, and 3) A person having ordinary skill in the art could have easily substituted CONSUL’s digital studio cloud computing provisioning system having resources allocatable to a rendering device performing rendering tasks into ACAR’s cloud provisioning system having resources allocatable to a device performing tasks, predictably resulting in a cloud provisioning system acting as a digital studio that allocates resources to a device that performs tasks related to graphical output rendering.
While CONSUL discusses a rendering device rendering and displaying images, REFERENCE PATENT, ACAR and CONSUL do not explicitly teach:
rendering and displaying images using light emitting diodes (LEDs) of a wall display of the at least one rendering device, according to the at least one rendering task, wherein the at least one rendering task includes real-time processing of scheduled video production of a design studio in a virtual studio environment
However, in analogous art that similarly teaches execution of rendering tasks, UNREAL teaches:
rendering and displaying images using light emitting diodes (LEDs) of a wall display of the at least one rendering device, according to the at least one rendering task; wherein the at least one rendering task includes real-time processing of scheduled video production of a design studio in a virtual studio environment (Starting at approximately 1:50 in the video, rendering tasks involving changes to the virtual environment are processed and output to the wall display device of the virtual studio in real time. Further, starting at approximately 2:05 in the video, the wall display device of the virtual studio is shown. The following screenshot shows where, in the video, changes to the virtual environment are rendered in real time and displayed on an LED wall of the studio).
PNG
media_image1.png
798
1422
media_image1.png
Greyscale
(added red arrows illustrating real time rendering of objects that are displayed on an LED wall of a studio)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined UNREAL’s teaching of performing real time rendering of objects that are displayed on an LED wall display, with Reference Patent, ACAR and CONSUL’s teaching of performing rendering tasks using cloud resources, to realize, with a reasonable expectation of success, a system that uses cloud resources to perform rendering tasks, as in Reference Patent, ACAR and CONSUL, that renders video in real time to a LED wall display, as in UNREAL. A person having ordinary skill would have been motivated to make this combination to enable digital backgrounds to be used in combination with physical objects and actors to produce more realistic scenes.
While ACAR discusses bursting resources responsive to an auto-scaling condition being met, REFERENCE PATENT, ACAR, CONSUL, and UNREAL do not explicitly teach:
wherein provisioning the second set of cloud computing resources includes triggering provisioning of the second set of cloud computing resources in response to data from the plurality of sensors indicating a communication network transmission latency of greater than a specified number of milliseconds from a remote location.
However, in analogous art that similarly provisions different sets of resources, FICARRA. teaches:
wherein provisioning the second set of cloud computing resources includes triggering provisioning of the second set of cloud computing resources in response to data from the plurality of sensors indicating a communication network transmission latency of greater than a specified number of milliseconds from a remote location ([Column 11, Lines 45-57] At block 614, a metrics manager obtains the data for the transaction from the replica (e.g., by reading a row that stores the transaction data) and calculates a replica latency metric based on one or more timestamps obtained from the replica (e.g., the submit timestamp). At block 616, if the latency metric does not exceed a threshold value, then at block 618, the metric manager determines that the latency is acceptable. However, if the latency does exceed a threshold value, then at block 620, the metrics manager performs a responsive action. For example, the metrics manager may send a notification to a client and/or an administrator of the service or the metrics manager may replace and/or scale one or more resources).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined FICARRA’s teaching of provisioning increased resources in response to determining that a network transmission latency requirement has not been met, with the combination of REFERENCE PATENT, ACAR, CONSUL, and UNREAL’s teaching of provisioning increased resources in response to determining that an auto-scaling condition has been met, to realize, with a reasonable expectation of success, a system that determines that an amount of resources should be increased based on an auto-scaling condition being met, as in REFERENCE PATENT, ACAR, CONSUL and UNREAL, where the condition is a network latency time condition, as in FICARRA. A person having ordinary skill would have been motivated to make this combination to ensure that failure events do not cause adverse latency performance issues impacting performance of an application (FICARRA Column 1, Lines 18-31)
While REFERENCE PATENT, ACAR, CONSUL, UNREAL, and FICARRA discusses selecting cloud computing resources, does not explicitly teach:
selecting the second set of cloud computing resources based at least in part on a proximity of the remote location of the second set of cloud computing resources to the at least one rendering device.
However, in analogous art, that similarly teaches selection of cloud computing resources CHANG teaches:
selecting the second set of cloud computing resources based at least in part on a proximity of the remote location of the second set of cloud computing resources to the at least one rendering device ([0017] In some implementations, the MEC node selection platform 102 may use the geographical location of the user device 104 to identify a set of candidate MEC nodes (i.e., “cloud computing resources”) that may be available to provide access to the service. For example, the MEC node selection platform 102 may identify the set of candidate MEC nodes based on MEC nodes being within a threshold distance from the geographical location of the user device 104. In other examples, the MEC node selection platform 102 may identify the set of candidate MEC nodes based on a threshold quantity of geographically closest MEC nodes to the user device 104. [0031] User device 210 includes one or more devices capable of receiving, generating, storing, processing, and/or providing information associated with a service. For example, user device(s) 210 may include a communication and/or computing device, such as a mobile phone (e.g., a smart phone, a radiotelephone, and/or the like), a laptop computer, a tablet computer, a handheld computer, a desktop computer…a gaming device, a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, and/or the like (i.e., user devices comprise displays and therefore represent “rendering devices”)), or a similar type of device).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined CHANG’s teaching of selecting MEC cloud resources based on geographical proximity to a user rendering device, with the combination of REFERENCE PATENT, ACAR, CONSUL, UNREAL, and FICARRA’s teaching of selecting cloud resources to allocate resources to rendering devices, to realize, with a reasonable expectation of success, a system that selects cloud computing resources, as in REFERENCE PATENT, ACAR, CONSUL, UNREAL, and FICARRA, based on geographical proximity to user rendering devices. As in CHANG. A person having ordinary skill would have been motivated to make this combination to better satisfy performance requirements (CHANG [0007]).
While REFERENCE PATENT, ACAR, CONSUL, UNREAL, FICARRA and CHANG discuss bursting resources used to render a simulated studio environment, the do not explicitly teach:
wherein the burst criteria indicates a simulation which incurs resources for rendering, and the second set of cloud computing resources are provisioned when a burst is predicted during the simulation.
However, in analogous art that similarly teaches bursting resources used to render a simulation, GEWICKEY teaches:
wherein the burst criteria indicates a simulation which incurs resources for rendering, and the second set of cloud computing resources are provisioned when a burst is predicted during the simulation ([0082] Modifiable aspects of the immersive stereographic data enable the user to repeat playback again and again with different results each time. In this concept, the content storyline or framespace path can be “self-modifying” based on user feedback statistics collected from multiple inputs 902. A frame server module may provide draft modifications to a director module 906, which may allow for oversight and creative input to assure artistic boundaries are not crossed. The director module 906 may prepare one or more revised framespace paths 910 for storyline or viewpoint navigation, and provide to the frame server 904. In turn, the frame server 904 may serve frame streams to multiple clients 902 based on the revised framespace paths 910. [0083] Modified frame streams may include, for example, informing performance metrics of a framespace navigation application, increasing detail or resolution of the areas that have received more audience attention, allocating increased rendering performance (e.g. MIPS) for scene detail of interest as per the statistics gathered (i.e., in a virtual reality simulator, user feedback statistics, representing previous simulations are used to determine, or “predict” details of interest which represent criteria for increased allocation of rendering performance, or “bursting”)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined GEWICKEY’s teaching of bursting rendering performance for a simulation that is predicted to require increased resources, with the combination of REFERENCE PATENT, ACAR, CONSUL, UNREAL, FICARRA and CHANG’s teaching of bursting resources used to render simulations, to realize, with a reasonable expectation of success, a system that bursts resources used to render simulations, as in REFERENCE PATENT, ACAR, CONSUL, UNREAL, FICARRA and CHANG, based on a prediction that the simulation will require a burst of resources, as in GEWICKEY. A person having ordinary skill would have been motivated to make this combination to improve responsiveness to simulation rendering based on prior user feedback.
Regarding claims 20 and 21, they comprise similar limitations to those of claim 1, and are therefore rejected for similar rationale.
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 1-5, 11, and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over ACAR et al. Patent No.: US 11,038,986 B1 (hereafter ACAR), in view of CONSUL et al. Pub. No.: US 2015/0105148 A1 (hereafter CONSUL), in view of Behind the Scenes with UE4’s Next-Gen Virtual Production Tools | Project Spotlight | Unreal Engine, accessible at https://www.youtube.com/watch?v=Hjb-AqMD-a4, on 12 November 2019 (hereafter UNREAL), in view of FICARRA et al. Patent No.: US 11,487,738 B1 (hereafter FICARRA), in view of CHANG et al. Pub. No.: US 2021/0144515 A1 (hereafter CHANG), in view of GEWICKEY et al. Pub. No.: US 2016/0191893 A1 (hereafter GEWICKEY).
ACAR, CONSUL, FICARRA, and CHANG were cited previously.
Regarding claim 1, ACAR teaches the invention substantially as claimed, including:
A [cloud computing provisioning system] ([Column 1, Lines 5-10] Embodiments presented herein generally relate to resource management in a cloud computing environment. More specifically, embodiments presented herein provide techniques for configuring an application stack executing in the cloud computing environment in response to changes in resource demand) comprising:
a plurality of sensors associated with at least one [device] ([Column 5, Lines 28-38] As shown, the metrics repository server 110 includes a monitoring service 111, metrics 112, and policies 113. In one embodiment, the monitoring service 111 collects the metrics 112 from components of the VPN 120 (e.g., the load balancer 121, cluster 122, and management server 124) (i.e., “plurality of sensors” because they monitor, or “sense” performance metrics of various components of the system). Generally, the metrics 112 are statistics observed in the cluster 122 and formatted by the monitoring service 111 as an ordered set of time-series data. For instance, metrics 112 can include statistics relating to resource utilization of the application servers 123 in the cluster 112, such as CPU resource utilization, latency, request counts, and so on (i.e., each resource utilization is implicitly collected by a “sensor” specific to that resource));
at least one non-transitory computer readable memory storing software instructions and at least one processor coupled with the plurality of sensors and with the non-transitory computer readable memory, the at least one processor configured to perform the following operations upon execution of the software instructions ([ Column 17, Lines 50-51] A non-transitory computer-readable storage medium storing instructions executable (i.e., by a processor, such as CPU 805 of Fig. 8) to perform…):
provisioning a first set of cloud computing resources associated with at least one [task] on the at least one [device], wherein the first set of could computing resources is associated with a burst criteria ([Column 11, Line 66-Column 12, Line 8] As shown, the method 700 begins at step 705, where the deployment engine 117 determines that one of the metrics observed by the metrics repository server 110 triggers an auto-scaling condition (i.e., condition of the metrics that triggers auto-scaling is considered “burst criteria”). The metrics can include resource utilization metrics (e.g., CPU utilization, memory usage, etc.) or application-specific metrics specified in a policy 113 associated with the cluster 122. Using the VoIP application as an example, application-specific metrics may include a number of concurrent calls, number of active users, number of connected users, and the like.);
monitoring at least one leading indicator relating to the first set of cloud computing resources, the at least one leading indicator derived at least in part from data from the plurality of sensors ([Column 3, Lines 1-8] A metrics repository server that collect (i.e., “monitors”) metrics (i.e., “leading indicators”) for the cluster may indicate to the auto-scaling service that a specified condition has been triggered for adding a new instance to the cluster. Metrics can relate to resource utilization of the cluster, such as CPU utilization, disk reads, disk writes, etc. As further described below, the metrics repository server may also collect metrics specific to the application (i.e., monitored metrics relate to resource utilization or application load which also relates to resource utilization));
determining a number of additional resources for the at least one [task] based on the plurality of sensors ([Column 9, Lines 41-47] The scaling module 510 retrieves the scaling configuration 515 associated with the cluster 122. The scaling configuration 515 provides an auto-scaling policy for the cluster 122. For example, the scaling configuration 515 may specify a maximum amount of application servers 123 that can run in the cluster 122 at a time, how many instances to add to a cluster when scaling up, fault tolerance settings, and the like); and
upon satisfaction of the burst criteria by the at least one leading indicator, provisioning a second set of cloud computing resources for at least the number of additional resources for the at least one [task] for the at least one [device] ([Column 12, Lines 25-31] If the indication specifies to add application server instances to the cluster 122, then at step 715, the deployment engine 117 provisions additional application server instances according to the scaling configuration 515. In particular, the scaling module 510 may evaluate the scaling configuration 515 and determine an amount of server instances to add to the cluster).
While ACAR teaches a system that provisions cloud resources for tasks executed by a device, ACAR does not explicitly teach that the system is a digital studio system, the device is a rendering device, and the tasks are rendering tasks;
rendering and displaying images…according to the at least one rendering task.
However, in analogous art that similarly teaches allocating cloud resources to processing tasks, CONSUL teaches:
a digital studio cloud computing provisioning system; at least one rendering device; at least one rendering task; rendering and displaying images…according to the at least one rendering task ([0015] In some embodiments, the graphics rendering system (i.e., “rendering device”) may interface with a cloud platform (i.e., “digital studio cloud computing provisioning system”) that provides servers host virtual machines that each have access to a commodity GPU via a virtual GPU; such servers are referred to as GPU servers. A server of the cloud platform may execute a server-side component of a computer program that generates graphics scenes, submits render tasks to generate images of those graphics scenes, and sends those rendered images to client-side components for display. For example, the computer program may be a game program, and the client-side component may execute on devices of game players. When the computer program is launched on a server, the graphics rendering system may allocate virtual machines hosted by different GPU servers for rendering the images of the computer program. The virtual machines execute code that may be part of the graphics rendering system and that receives render tasks, directs the virtual GPU to perform the render tasks, and provides the rendered image as the result of the render task (i.e., tasks are rendered and displayed on client gaming devices));
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have simply substituted CONSUL’s digital studio cloud computing provisioning system having resources allocatable to a rendering device performing rendering tasks, into ACAR’s cloud provisioning system having resources allocatable to a device performing tasks, because 1) ACAR contained a cloud provisioning system having resources allocatable to a device performing tasks, which differs from the claimed invention in that the cloud provisioning system was not a “digital studio cloud computing provisioning system”, the device was not a “rendering device” and the task was not a “rendering task”, 2) CONSUL teaches a digital studio cloud computing provisioning system having resources allocatable to a rendering device performing rendering tasks, and 3) A person having ordinary skill in the art could have easily substituted CONSUL’s digital studio cloud computing provisioning system having resources allocatable to a rendering device performing rendering tasks into ACAR’s cloud provisioning system having resources allocatable to a device performing tasks, predictably resulting in a cloud provisioning system acting as a digital studio that allocates resources to a device that performs tasks related to graphical output rendering.
While ACAR and CONSUL discuss execution of rendering tasks using provisioned cloud resources, ACAR and CONSUL do not explicitly teach:
rendering and displaying images using light emitting diodes (LEDs) of a wall display of the at least one rendering device, according to the at least one rendering task;
wherein the at least one rendering task includes real-time processing of scheduled video production of a design studio in a virtual studio environment
However, in analogous art that similarly teaches execution of rendering tasks, UNREAL teaches:
rendering and displaying images using light emitting diodes (LEDs) of a wall display of the at least one rendering device, according to the at least one rendering task; wherein the at least one rendering task includes real-time processing of scheduled video production of a design studio in a virtual studio environment (Starting at approximately 1:50 in the video, rendering tasks involving changes to the virtual environment are processed and output to the wall display device of the virtual studio in real time. Further, starting at approximately 2:05 in the video, the wall display device of the virtual studio is shown. The following screenshot shows where, in the video, changes to the virtual environment are rendered in real time and displayed on an LED wall of the studio).
PNG
media_image1.png
798
1422
media_image1.png
Greyscale
(added red arrows illustrating real time rendering of objects that are displayed on an LED wall of a studio)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined UNREAL’s teaching of performing real time rendering of objects that are displayed on an LED wall display, with ACAR and CONSUL’s teaching of performing rendering tasks using cloud resources, to realize, with a reasonable expectation of success, a system that uses cloud resources to perform rendering tasks, as in ACAR and CONSUL, that renders video in real time to a LED wall display, as in UNREAL. A person having ordinary skill would have been motivated to make this combination to enable digital backgrounds to be used in combination with physical objects and actors to produce more realistic scenes.
While ACAR discusses bursting resources responsive to an auto-scaling condition being met, ACAR, CONSUL, and UNREAL do not explicitly teach:
wherein provisioning the second set of cloud computing resources includes triggering provisioning of the second set of cloud computing resources in response to data from the plurality of sensors indicating a communication network transmission latency of greater than a specified number of milliseconds from a remote location.
However, in analogous art that similarly provisions different sets of resources, FICARRA. teaches:
wherein provisioning the second set of cloud computing resources includes triggering provisioning of the second set of cloud computing resources in response to data from the plurality of sensors indicating a communication network transmission latency of greater than a specified number of milliseconds from a remote location ([Column 11, Lines 45-57] At block 614, a metrics manager obtains the data for the transaction from the replica (e.g., by reading a row that stores the transaction data) and calculates a replica latency metric based on one or more timestamps obtained from the replica (e.g., the submit timestamp). At block 616, if the latency metric does not exceed a threshold value, then at block 618, the metric manager determines that the latency is acceptable. However, if the latency does exceed a threshold value, then at block 620, the metrics manager performs a responsive action. For example, the metrics manager may send a notification to a client and/or an administrator of the service or the metrics manager may replace and/or scale one or more resources).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined FICARRA’s teaching of provisioning increased resources in response to determining that a network transmission latency requirement has not been met, with the combination of ACAR, CONSUL, and UNREAL’s teaching of provisioning increased resources in response to determining that an auto-scaling condition has been met, to realize, with a reasonable expectation of success, a system that determines that an amount of resources should be increased based on an auto-scaling condition being met, as in ACAR, CONSUL and UNREAL, where the condition is a network latency time condition, as in FICARRA. A person having ordinary skill would have been motivated to make this combination to ensure that failure events do not cause adverse latency performance issues impacting performance of an application (FICARRA Column 1, Lines 18-31)
While ACAR, CONSUL, UNREAL, and FICARRA discusses selecting cloud computing resources, does not explicitly teach:
selecting the second set of cloud computing resources based at least in part on a proximity of the remote location of the second set of cloud computing resources to the at least one rendering device.
However, in analogous art, that similarly teaches selection of cloud computing resources, CHANG teaches:
selecting the second set of cloud computing resources based at least in part on a proximity of the remote location of the second set of cloud computing resources to the at least one rendering device ([0017] In some implementations, the MEC node selection platform 102 may use the geographical location of the user device 104 to identify a set of candidate MEC nodes (i.e., “cloud computing resources”) that may be available to provide access to the service. For example, the MEC node selection platform 102 may identify the set of candidate MEC nodes based on MEC nodes being within a threshold distance from the geographical location of the user device 104. In other examples, the MEC node selection platform 102 may identify the set of candidate MEC nodes based on a threshold quantity of geographically closest MEC nodes to the user device 104. [0031] User device 210 includes one or more devices capable of receiving, generating, storing, processing, and/or providing information associated with a service. For example, user device(s) 210 may include a communication and/or computing device, such as a mobile phone (e.g., a smart phone, a radiotelephone, and/or the like), a laptop computer, a tablet computer, a handheld computer, a desktop computer…a gaming device, a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, and/or the like (i.e., user devices comprise displays and therefore represent “rendering devices”)), or a similar type of device).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined CHANG’s teaching of selecting MEC cloud resources based on geographical proximity to a user rendering device, with the combination of ACAR, CONSUL, UNREAL, and FICARRA’s teaching of selecting cloud resources to allocate resources to rendering devices, to realize, with a reasonable expectation of success, a system that selects cloud computing resources, as in ACAR, CONSUL, UNREAL, and FICARRA, based on geographical proximity to user rendering devices. As in CHANG. A person having ordinary skill would have been motivated to make this combination to better satisfy performance requirements (CHANG [0007]).
While ACAR, CONSUL, UNREAL, FICARRA and CHANG discuss bursting resources used to render a simulated studio environment, the do not explicitly teach:
wherein the burst criteria indicates a simulation which incurs resources for rendering, and the second set of cloud computing resources are provisioned when a burst is predicted during the simulation.
However, in analogous art that similarly teaches bursting resources used to render a simulation, GEWICKEY teaches:
wherein the burst criteria indicates a simulation which incurs resources for rendering, and the second set of cloud computing resources are provisioned when a burst is predicted during the simulation ([0082] Modifiable aspects of the immersive stereographic data enable the user to repeat playback again and again with different results each time. In this concept, the content storyline or framespace path can be “self-modifying” based on user feedback statistics collected from multiple inputs 902. A frame server module may provide draft modifications to a director module 906, which may allow for oversight and creative input to assure artistic boundaries are not crossed. The director module 906 may prepare one or more revised framespace paths 910 for storyline or viewpoint navigation, and provide to the frame server 904. In turn, the frame server 904 may serve frame streams to multiple clients 902 based on the revised framespace paths 910. [0083] Modified frame streams may include, for example, informing performance metrics of a framespace navigation application, increasing detail or resolution of the areas that have received more audience attention, allocating increased rendering performance (e.g. MIPS) for scene detail of interest as per the statistics gathered (i.e., in a virtual reality simulator, user feedback statistics, representing previous simulations are used to determine, or “predict” details of interest which represent criteria for increased allocation of rendering performance, or “bursting”)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined GEWICKEY’s teaching of bursting rendering performance for a simulation that is predicted to require increased resources, with the combination of ACAR, CONSUL, UNREAL, FICARRA and CHANG’s teaching of bursting resources used to render simulations, to realize, with a reasonable expectation of success, a system that bursts resources used to render simulations, as in ACAR, CONSUL, UNREAL, FICARRA and CHANG, based on a prediction that the simulation will require a burst of resources, as in GEWICKEY. A person having ordinary skill would have been motivated to make this combination to improve responsiveness to simulation rendering based on prior user feedback.
Regarding claim 2, CONSUL further teaches:
the second set of could computing resources comprises a rendering image resource ([0015] In some embodiments, the graphics rendering system may interface with a cloud platform that provides servers host virtual machines that each have access to a commodity GPU via a virtual GPU; such servers are referred to as GPU servers (i.e., virtual GPUs used to perform rendering tasks are considered “rendering image resources”)).
Regarding claim 3, CONSUL further teaches:
the rendering image resource comprises at least one graphics processing unit (GPU) ([0015] In some embodiments, the graphics rendering system may interface with a cloud platform that provides servers host virtual machines that each have access to a commodity GPU via a virtual GPU; such servers are referred to as GPU servers (i.e., virtual GPUs used to perform rendering tasks are considered “rendering image resources”)).
Regarding claim 4, CONSUL further teaches:
the at least one leading indicator includes at least a graphics processing unit (GPU) processing metric ([0023] FIG. 3 is a flow diagram that illustrates the processing of a game launched component of the render task server in some embodiments. The game launched component 300 is invoked when a new game has been launched and allocates virtual machines to that instance of the game. The number of virtual machines allocated to a game may be based on various criteria such as expected workload of the game program, current workload of the cloud platform, target probability of an error, and so on (i.e., workload of a game represents current “utilization” of virtual machines hosted by GPUs, and therefore represents a “leading indicator”). [0018] If a render task could not be completed successfully using virtual machines hosted by a selected set of GPU servers, the graphics rendering system may direct virtual machines hosted by a different set of GPU servers to perform the render task. The graphics rendering system may initially select a small number (e.g., one or two) of virtual machines to perform a render task and, if they are unsuccessful, select a larger number of virtual machines (i.e., VM workload is an indicator of the processing metric of the hosting GPU servers, and is therefore a “GPU processing metric” and is used to determine when to provision additional resources for a rendering task during certain conditions)).
Regarding claim 5, ACAR further teaches:
the at least one leading indicator includes at least one of a processor metric, a storage metric, a bandwidth metric, or a latency metric ([Column 3, Lines 1-8] A metrics repository server that collect (i.e., “monitors”) metrics (i.e., “leading indicators”) for the cluster may indicate to the auto-scaling service that a specified condition has been triggered for adding a new instance to the cluster. Metrics can relate to resource utilization of the cluster, such as CPU utilization (i.e., “processor metric”), disk reads, disk writes (i.e., “storage metrics”), etc (i.e., latency metric is discussed in Column 5, Line 38)).
Regarding claim 11, CONSUL further teaches:
the at least one rendering task comprises a simulation task ([0001] In many domains, computer programs are being developed that need rendering of increasingly complex graphics scenes. These domains include games, genetic modeling, cinematic animation, simulations (e.g., flight simulators)).
Regarding claims 20 and 21, they are method and computer program product claims comprising limitations similar to those of claim 1, and are therefore rejected for similar rationale.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over ACAR, in view of CONSUL, in view of UNREAL, in view of FICARRA, in view of CHANG, in view of GEWICKEY, as applied to claim 1 above, and in further view of WEYBREW et al. Pub. No.: US 2008/0284798 A1 (hereafter WEYBREW).
WEYBREW was cited previously.
Regarding claim 8, while CONSUL teaches a rendering task related to a gaming application, the combination of ACAR, CONSUL, UNREAL, FICARRA, CHANG, and GEWICKEY does not explicitly teach:
the at least one rendering task comprises a pre-rendering task.
However, in analogous art that similarly renders graphics for gaming applications, WEYBREW teaches:
the at least one rendering task comprises a pre- rendering task ([0027] The overlay and compositing techniques in this disclosure may provide one or more advantages. For example, a video game may display complex 3D graphics as well as simple graphical objects, such as 2D graphics and relatively static objects. These simple graphical objects can be rendered as off-screen surfaces separate from the complex 3D graphics. The rendered off-screen surfaces can be overlayed (i.e. combined) with the complex 3D graphics surfaces to generate a final graphics frame. Because the simple graphical objects may not require 3D graphics rendering capabilities, such objects can be rendered using techniques that consume less hardware resources in a graphics processing system. For example, such objects may be rendered by a processor that uses a general purpose processing pipeline or rendered by a processor having 2D graphics acceleration capabilities. In addition, such objects may be pre-rendered and stored for later use within the graphics processing system. By rendering or pre-rendering the simple graphical objects separate from the complex 3D graphics, the load on the 3D graphics rendering hardware can be reduced (i.e., rendering video game graphics includes a pre-rendering phase that occurs prior to the primary rendering phase during a primary runtime loop of the graphics application (see [0024])).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined WEYBREW teaching of rendering and pre-rendering graphics for a gaming application, with ACAR, CONSUL, UNREAL, FICARRA, CHANG, and GEWICKEY’s teaching of rendering graphics for gaming applications, to realize, with a reasonable expectation of success, a system that pre-renders objects, as in WEYBREW, as part of a rendering task, as in ACAR, CONSUL, UNREAL, FICARRA, CHANG, and GEWICKEY. A person having ordinary skill would have been motivated to make this combination to reduce load on a 3D graphics rendering hardware (WEYBREW [0027]).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over ACAR, in view of CONSUL, in view of UNREAL, in view of FICARRA, in view of CHANG, in view of GEWICKEY, as applied to claim 1 above, and in further view of EADICICCO, LISA. “Review: Oculus Rift is Expensive, Complicated, and Totally Wonderful.” Available at https://time.com/4272506/oculus-rift-review/ on 28 March 2016 (hereafter EADICICCO).
EADICICCO was cited previously.
Regarding claim 9, while CONSUL teaches a rendering task related to a gaming application, the combination of ACAR, CONSUL, UNREAL, FICARRA, CHANG, and GEWICKEY does not explicitly teach:
the at least one rendering task is associated with augmented reality.
However, in analogous art that similarly teaches rendering graphics for gaming applications, EADICICCO teaches:
the at least one rendering task is associated with augmented reality (Before diving into virtual reality’s imaginary worlds, you’ll have to become familiar with the hardware—and a lot of it. When you order a Rift, Oculus sends the headset, a camera sensor, an Oculus Remote, an Xbox One controller, and plenty of cables to connect it all. Everything comes neatly packaged in a nice box with a premium feel. Because Oculus software requires a significant amount of processing power to generate virtual experiences that are immersive and lag-free, you’ll also need a beefy PC. Alienware, Asus, and Dell sell Oculus-ready computers that meet the Rift’s specifications. For our review, Oculus sent an Asus ROG G20 PC with an NVIDIA graphics card, a very capable gaming machine that runs about $1,000 (i.e., PCs perform graphical rendering and display tasks associated with the Oculus Rift Augmented Reality Headset))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined EADICICCO’s teaching of performing graphical rendering tasks associated with augmented reality gaming, with the combination of ACAR, CONSUL, UNREAL, FICARRA, CHANG, and GEWICKEY’s teaching of performing graphical rendering tasks associated with gaming, to realize, with a reasonable expectation of success, a system that performs graphical rendering tasks associated with gaming, as in CONSUL, where the gaming includes augmented reality, as in EADICICCO. A person having ordinary skill in the art would have been motivated to make this combination to enjoy rendered augmented reality games which allow users to play more immersive and interactive games than traditional ones.
Claims 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over ACAR, in view of CONSUL, in view of UNREAL, in view of FICARRA, in view of CHANG, in view of GEWICKEY, as applied to claim 1 above, and in further view of CATTONI Pub. No.: US 2019/0229998 A1 (hereafter CATTONI).
CATTONI was cited previously.
Regarding claim 12, while ACAR teaches determination of leading indicators, the combination of ACAR, CONSUL, UNREAL, FICARRA, CHANG, and GEWICKEY does not explicitly teach:
the at least one leading indicator is a member of a baseline vector.
However, in analogous art that similarly teaches collecting performance measurements of a cloud based system including resource utilization, CATTONI teaches:
the at least one leading indicator is a member of a baseline vector ([0088] Controller 202 may initiate a test plan that involves RS 100 or related component (e.g., system calibrator 140) to execute workloads under different configurations while probes and/or other measurement components 112 in RS 100 are used for gathering real-time or near real-time feedback and/or measurements (e.g., power consumption metrics, resource usage metrics (i.e., “leading indicators”), etc.) during execution of the workloads. In this example, the controller or another entity (e.g., ABISS 204) may generate calibration output, e.g., one or more correlation profiles and/or baseline behavior data (i.e., “baseline vector” which includes resource usage metrics), for RS 100 and/or related components (e.g., compute resource that can be used to detect abnormal or unusual behaviors (e.g., potentially malicious behaviors) when execution of other (e.g., non-test related) workloads).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined CATTONI’s teaching of monitoring resource utilization metrics indicative of a baseline behavior, with the combination of ACAR, CONSUL, UNREAL, FICARRA, CHANG, and GEWICKEY’s teaching of monitoring resource utilization metrics as leading indicators used in auto-scaling, to realize, with a reasonable expectation of success, a system that monitors resource utilization metrics indicative of baseline behavior, as in CATTONI, which are leading indicators used to determine auto-scaling behavior, as in ACAR. A person having ordinary skill would have been motivated to make this combination to better detect abnormal, unusual, or malicious behavior in the system to prevent damages due to such behavior and improve cloud security (CATTONI [0056]).
Regarding claim 13, ACAR further teaches:
the burst criteria comprises an anomaly detection criteria ([Column 11, Line 66-Column 12, Line 8] As shown, the method 700 begins at step 705, where the deployment engine 117 determines that one of the metrics observed by the metrics repository server 110 triggers an auto-scaling condition (i.e., “burst criteria”, wherein the state of the observed metrics that triggers the auto-scaling condition is considered to be “anomalous”)).
CATTONI further teaches:
anomaly detection criteria defined based at least on the baseline vector and at least in part on the at least one leading indicator ([0088] Controller 202 may initiate a test plan that involves RS 100 or related component (e.g., system calibrator 140) to execute workloads under different configurations while probes and/or other measurement components 112 in RS 100 are used for gathering real-time or near real-time feedback and/or measurements (e.g., power consumption metrics, resource usage metrics (i.e., “leading indicators”), etc.) during execution of the workloads. In this example, the controller or another entity (e.g., ABISS 204) may generate calibration output, e.g., one or more correlation profiles and/or baseline behavior data (i.e., “baseline vector” which includes resource usage metrics), for RS 100 and/or related components (e.g., compute resource that can be used to detect abnormal (i.e., “anomalous”) or unusual behaviors (e.g., potentially malicious behaviors) when execution of other (e.g., non-test related) workloads (i.e., anomalous behavior is detected based on the baseline behavior data and the gathered resource usage metrics)).
Claims 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over ACAR, in view of CONSUL, in view of UNREAL, in view of FICARRA, in view of CHANG, in view of GEWICKEY, as applied to claim 1 above, and in further view of STICH et al. Pub. No.: US 2014/0282591 A1 (hereafter STICH).
STICH was cited previously.
Regarding claim 12, while ACAR teaches determination of leading indicators, the combination of ACAR, CONSUL, UNREAL, FICARRA, CHANG, and GEWICKEY does not explicitly teach:
the at least one leading indicator represents a rate of change over time detected from the plurality of sensors.
However, in analogous art that similarly performs resource auto-scaling based on monitored performance data, STICH teaches:
the at least one leading indicator represents a rate of change over time detected from the plurality of sensors ([0021] The performance-data translation node 106 receives the predicted performance data, in the form of the extended time series, from the time-series extension node 104. The performance-data translation node 106 may save the extended time-series data in a database or similar storage element or device for later use or analysis. In one embodiment, the performance-data translation node 106 analyzes the time-series data to determine if the virtualized application is experiencing, or will experience in the future, a shortfall or over-allocation of allocated resources (e.g., memory, storage, CPU power, throughput, or other such factors) (i.e., monitoring node 102 of Fig. 1 collects performance data from plural resources using implicit “plural sensors” ). The performance-data translation node 106 may compare the resource utilization shown by the time-series data against one or more thresholds, such as maximum available resources (i.e., “burst criteria”), and determine that the virtualized application is or will experience a resource shortfall if one or more of the resources used by the virtualized application exceeds or is approaching one or more of the thresholds. The performance-data translation node 106 may also or in addition determine that the virtualized application is or will experience a resource shortfall if a rate of change of resource utilization exceeds a threshold).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined STICH’s teaching of monitoring resource utilization and using rate of change in resource utilization to determine auto scaling criteria, with the combination of ACAR, CONSUL, UNREAL, FICARRA, CHANG, and GEWICKEY’s teaching of monitoring resource utilization to determine auto scaling criteria, to realize, with a reasonable expectation of success, a system that monitors rate of change in resource utilization, as in STICH, to determine auto scaling criteria, as in ACAR. A person having ordinary skill would have been motivated to make this combination so that predictive advance provisioning of resources may be realized while considering utilization patterns and trends across different applications (STICH [0004]).
Regarding claim 15, STICH further teaches:
the rate of change over time comprises at least one of a first order derivative, a second order derivative, a third order derivative, or a forth order derivative ([0021] The performance-data translation node 106 may also or in addition determine that the virtualized application is or will experience a resource shortfall if a rate of change of resource utilization exceeds a threshold (i.e., in determining the rate of change of resource utilization, STICH implicitly determines a first order derivative of the resource utilization, because the instantaneous rate of change of a function is defined as the first order derivative of that function. For example: “derivative, in mathematics, the rate of change of a function with respect to a variable. Derivatives are fundamental to the solution of problems in calculus and differential equations. In general, scientists observe changing systems (dynamical systems) to obtain the rate of change of some variable of interest, incorporate this information into some differential equation, and use integration techniques to obtain a function that can be used to predict the behaviour of the original system under diverse conditions” (https://www.britannica.com/science/derivative-mathematics))).
Claims 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over ACAR, in view of CONSUL, in view of UNREAL, in view of FICARRA, in view of CHANG, in view of GEWICKEY, as applied to claim 1 above, and in further view of HARI Pub. No.: US 2020/0073717 A1 (hereafter HARI).
HARI was cited previously.
Regarding claim 16, while ACAR teaches provisioning a second set of cloud computing resources, the combination of ACAR, CONSUL, UNREAL, FICARRA, CHANG, and GEWICKEY does not explicitly teach:
the operations further include recording provisioning the second set of cloud computing resources on a notarized ledger as a burst activity.
However, in analogous art that similarly performs cloud resource autoscaling, HARI teaches:
the operations further include recording provisioning the second set of cloud computing resources on a notarized ledger as a burst activity ([0055] In Step 312, an alert generated from the performance information is received. In one or more embodiments, the alert is generated by the monitoring service in response to performance information that is received from the load balancer or monitoring agents of the containers of the application (i.e., “burst criteria” being satisfied generates the alert). [0058] In Step 318, the resources to be updated (i.e., “second set of resources”) are determined and updated parameters are generated. In one or more embodiments, the resources are determined based on the output vector, the alert, and the performance information. [0062] In Step 320, updated configuration costs are determined (i.e., updated configuration costs represents a “ledger” that is updated to reflect the updated allocation of resources used to execute the application). In one or more embodiments, the resource allocation service determines the updated configuration costs by applying the pricing information to the updated parameters. The updated parameters can change the configuration of the resources for the machine instances as well as the number of machine instances that are used to execute the application).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined HARI’s teaching of updating a cost ledger to reflect proposed additional resources to allocate in response to a performance condition, with the combination of ACAR, CONSUL, UNREAL, FICARRA, CHANG, and GEWICKEY’s teaching of allocating additional resources in response to a performance condition, to realize, with a reasonable expectation of success, a system that determines that a performance condition meets a threshold, and that resources are to be reallocated, as in ACAR, and modifies a cost ledger to reflect the updated pricing of the reallocated resources, as in HARI. A person having ordinary skill would have been motivated to make this combination to enable businesses to consider cost/pricing into their cloud resource autoscaling decisions to better meet the business objectives by optimizing cost in view of performance (HARI [0018]).
Regarding claim 17, HARI further teaches:
the operations further include billing for the second set of cloud computing resources based on the burst activity recorded on the notarized ledger ([0063] In Step 322, reallocation instructions are generated. In one or more embodiments, the resource allocation service generates the reallocation instructions by comparing the updated configuration costs to the budget goals. The budget information includes a budget goal that is compared to the updated configuration cost determined by the resource allocation service. As an example, the budget goal identifies a total cost for the next three months of operating the application using the cloud provider service. The number of hours in three months is multiplied by the updated configuration cost, which is priced in dollars per hour, to determine the projected cost for the next three months of operating the application. When the projected cost is less than the amount identified in the budget goal, then the resource allocation service generates instructions that will apply the updated parameters to the cloud provider service using the cloud API to adjust the resources and machine instances used by the containers that execute the application (i.e., applying the updated parameters to the resources causes the client to be billed for the updated configuration cost)).
Claims 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over ACAR, in view of CONSUL, in view of UNREAL, in view of FICARRA, in view of CHANG, in view of GEWICKEY, as applied to claim 1 above, and in further view of RAMARAO et al. Patent No.: US 9,497,136 B1 (hereafter RAMARAO).
RAMARAO was cited previously.
Regarding claim 18, while ACAR determines leading indicators, the combination of ACAR, CONSUL, UNREAL, FICARRA, CHANG, and GEWICKEY does not explicitly teach:
the monitoring the at least one leading indicator includes presenting the at least one leading indicator on a computer- based dashboard.
However, in analogous art that similarly monitors cloud resource utilization, RAMARAO teaches:
the monitoring the at least one leading indicator includes presenting the at least one leading indicator on a computer- based dashboard ([Abstract] A management console application provides a dashboard which centralizes data from and access to one or more other applications. In a specific implementation, the dashboard displays resource utilization (i.e., “leading indicator”) and tracking data generated by a first application, an application execution map generated by a second application that identifies the resources on which a third application is executing, or both).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined RAMARAO’s teaching of providing a dashboard that presents at least monitored resource utilization in a cloud, with the combination of ACAR, CONSUL, UNREAL, FICARRA, CHANG, and GEWICKEY’s teaching of monitoring resource utilization in a cloud, to realize, with a reasonable expectation of success, a system that monitors resource utilization in a cloud, as in ACAR, and presents the monitored resource utilization on a dashboard, as in RAMARAO. A person having ordinary skill would have been motivated to make this combination to better inform users or administrators of resource behavior in a cloud system for use in decision making processes.
Regarding claim 19, ROMARAO further teaches:
the computer-based dashboard comprises a network management tool ([Abstract] A management console application (i.e., enabling “management” of a “network” of cloud resources) provides a dashboard which centralizes data from and access to one or more other applications. In a specific implementation, the dashboard displays resource utilization and tracking data generated by a first application, an application execution map generated by a second application that identifies the resources on which a third application is executing, or both).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 PM.
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, Aimee Li can be reached on (571) 272-4169. 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.
/MICHAEL W AYERS/Primary Examiner, Art Unit 2195
Prosecution Insights