DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
1. Claims 1-2, 4-5, 12-13, 15-16, 21, 24-25, 33, 38-40, and 44-50 are currently pending in this application.
Claims 1, 12, and 21 are amended as filed on 04/27/2026.
Claims 3, 6-11, 14, 17-20, 22-32, 34-37, 41-43 are canceled as filed on 04/27/2026.
Claims 48-50 are new as filed on 04/27/2026.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 48 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. More specifically, claim 48 contains the limitation “wherein the latency requirement parameter further comprises forcible information indicating whether the latency assurance system is to strictly meet the latency requirement on a premise of a basic resource currently in use for the cloud service, and wherein when the forcible information indicates that the latency requirement is to be strictly met and a smallest latency achievable using the basic resource currently in use exceeds the latency requirement, the method further comprises automatically adjusting the basic resource to a resource type that is capable of meeting the latency requirement”.
This claim is unclear as forcible information, strictly enforced, and smallest latency achievable cannot be properly determined by the provided context. Latency will generally always have a standard deviation and etc.. For examination purposes, the limitation will be treated as if referring to ensuring that latency is enforced. However, appropriate correction/clarification is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2, 4-5, 12-13, 15-16, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Stenberg et al. (Pre-Grant Publication No. US 2020/0076709 A1), hereinafter Stenberg, in view of Lucas et al. (Patent No. US 10,560,372 B1), hereinafter Lucas, in view of Chang et al. (Pre-Grant Publication No. US 2013/0297769 A1), hereinafter Chang, in view of George et al. (Pre-Grant Publication No. US 2017/0371558 A1), hereinafter George, and in further view of Zerr et al. (Pre-Grant Publication No. US 2016/0184710 A1), hereinafter Zerr.
2. With respect to claims 1, 12, and 21, Stenberg taught a method comprising: receiving, from a terminal device, a latency requirement parameter comprising first information about a service of the user and a latency requirement that the service needs to meet (0004, where the latency assurance can be seen in 0039); and providing latency assurance for the service according to the latency requirement (0039).
However, Stenberg did not explicitly state generating, based on the latency requirement parameter and a formulation policy, a latency assurance policy used to implement a latency assurance cloud service; obtaining latency information of the cloud service, wherein the latency information indicates an actual latency of the cloud service; calculating a difference between the latency requirement that the cloud service needs to meet and the actual latency of the cloud service; generating an adjustment policy for adjusting a first resource used for the cloud service when the difference indicates that the actual latency of the cloud service does not meet the latency requirement that the cloud service needs to meet; and adjusting, according to the adjustment policy, the first resource used for the cloud service. On the other hand, Lucas did teach generating, based on the latency requirement parameter and a formulation policy, a latency assurance policy used to implement a latency assurance cloud service (13:46-63, where the latency policy adjustment can be seen in 8:39-45, and where the service is a cloud service in accordance with 2:48-50); obtaining latency information of the cloud service, wherein the latency information indicates an actual latency of the cloud service (13:46-63); calculating a difference between the latency requirement that the cloud service needs to meet and the actual latency of the cloud service (13:46-63); generating an adjustment policy for adjusting a first resource used for the cloud service when the difference indicates that the actual latency of the cloud service does not meet the latency requirement that the cloud service needs to meet (8:39-45); and adjusting, according to the adjustment policy, the first resource used for the cloud service (8:39-45). Both of the systems of Stenberg and Lucas are directed towards managing assurance policies and therefore, it would have been obvious to a person having ordinary skill in the art, at the time of the effective filing of the invention, to modify the teachings of Stenberg, to utilize generating an assurance policy, as taught by Lucas, in order to efficiently implement the requested requirements.
However, Stenberg did not explicitly state performing actions when a plurality of actual latencies within a preset duration does not meet the latency requirement that the cloud service needs to meet, wherein the plurality of actual latencies comprises processing latencies. On the other hand, George did teach performing actions when a plurality of actual latencies within a preset duration does not meet the latency requirement that the cloud service needs to meet (0086, the actual latency values), wherein the plurality of actual latencies comprises processing latencies (0045, the measured operations). Both of the systems of Stenberg and George are directed towards improving system performance and therefore, it would have been obvious to a person having ordinary skill in the art, at the time of the effective filing of the invention, to modify the teachings of Stenberg, to utilize actual latency determinations, as taught by George, in order to more specifically optimize the system.
However, Stenberg did not explicitly state wherein the plurality of actual latencies comprises transmission latencies and wherein the plurality of actual latencies within the preset duration does not meet the latency requirement when none of the plurality of actual latencies meets the latency requirement. On the other hand, Zerr did teach wherein the plurality of actual latencies comprises transmission latencies (0042, the transmission rates) and wherein the plurality of actual latencies within the preset duration does not meet the latency requirement when none of the plurality of actual latencies meets the latency requirement (0043, the actual measured latency fails if not within threshold, with teaches the “none” limitation under broadest reasonable interpretation. Furthermore, the plurality of measured actual latencies can be seen in 0025). Both of the systems of Stenberg and Zerr are directed towards optimizing security and therefore, it would have been obvious to a person having ordinary skill in the art, at the time of the effective filing of the invention, to modify the teachings of Stenberg, to utilize actual latency determinations for transmission latencies, as taught by Zerr, in order to more specifically optimize the system.
However, Stenberg did not explicitly state sending to a cloud platform, the latency assurance policy to instruct the cloud platform to provide the cloud service to the terminal device according to the latency requirement; wherein the latency requirement parameter is received after an initial deployment of the cloud service has been completed, wherein a cloud platform on which the cloud service is deployed comprises a service provision system and a latency assurance system that are separately deployed, and wherein the first information comprises a service identifier identifying the cloud service in the service provision system and a service object identifier identifying a service object implementing the cloud service in the service provision system; meet; generating, based on the user selection of the one of the plurality of formulation policies and the latency requirement parameter, a latency assurance policy for the cloud service identified by the service identifier, wherein the latency assurance system directly applies the latency assurance policy to the cloud service identified by the service identifier. On the other hand, Chang did teach sending to a cloud platform, the latency assurance policy to instruct the cloud platform to provide the cloud service to the terminal device according to the latency requirement (0011, where the deployment to a terminal device in a cloud can be seen in 0059); wherein the latency requirement parameter is received after an initial deployment of the cloud service has been completed, wherein a cloud platform on which the cloud service is deployed comprises a service provision system and a latency assurance system that are separately deployed, and wherein the first information comprises a service identifier identifying the cloud service in the service provision system and a service object identifier identifying a service object implementing the cloud service in the service provision system (figure 1, items 12 & 14, where the identifiers are given); meet; generating, based on the user selection of the one of the plurality of formulation policies and the latency requirement parameter, a latency assurance policy for the cloud service identified by the service identifier, wherein the latency assurance system directly applies the latency assurance policy to the cloud service identified by the service identifier (0057-0058, the deployment, where the simulating includes latency determinations in accordance with 0025). Both of the systems of Stenberg and Chang are directed towards managing policy implementation and therefore, it would have been obvious to a person having ordinary skill in the art, at the time of the effective filing of the invention, to modify the teachings of Stenberg, to utilize transmitting a policy to a cloud platform, as taught by Chang, in order to efficiently implement the requested requirements.
3. As for claims 2 and 13, they are rejected on the same basis as claims 1 and 12 (respectively). In addition, Stenberg taught wherein the latency requirement parameter further comprises one or more of second information about a resource used to provide the latency assurance, third information about time used to provide the latency assurance, forcible information for providing the latency assurance, a preference formulation policy used to provide the latency assurance, or a collection period of latency information of the service (0039, the resource allocations, at least, teaches the information about a resource used limitation), and wherein the latency assurance method further comprises further providing, based on the latency requirement parameter, the latency assurance for the service (0039, where the assurance is provided).
4. As for claims 4 and 15, they are rejected on the same basis as claims 3 and 14 (respectively). In addition, Chang taught adjusting one or more of a network resource used for the service, a computing resource used for the service, or a storage resource used for the service (0059, where the allocation is the adjustment).
5. As for claims 5 and 16, they are rejected on the same basis as claims 3 and 14 (respectively). In addition, Chang taught reserving the resource for the service; or adjusting a restriction of the resource that can be used for the service (0059, the deployment).
6. As for claim 48, it is rejected on the same basis as claim 1. In addition, Chang taught wherein the latency requirement parameter further comprises forcible information indicating whether the latency assurance system is to strictly meet the latency requirement on a premise of a basic resource currently in use for the cloud service, and wherein when the forcible information indicates that the latency requirement is to be strictly met and a smallest latency achievable using the basic resource currently in use exceeds the latency requirement, the method further comprises automatically adjusting the basic resource to a resource type that is capable of meeting the latency requirement (0025 & 0058, where the enforcement teaches the forcible information and strict latency under broadest reasonable interpretation).
7. As for claim 49, it is rejected on the same basis as claim 1. In addition, Chang taught wherein generating the latency assurance policy comprises: generating a plurality of candidate latency assurance policies using the plurality of formulation policies; simulating resource adjustment according to each of the plurality of candidate latency assurance policies; obtaining a yield resulting from resource adjustment according to each of the plurality of candidate latency assurance policies; and selecting, as the latency assurance policy, the candidate latency assurance policy according to which a highest yield is achieved at a lowest cost (0057-0058, the deployment, where the simulating includes latency determinations in accordance with 0025).
8. As for claim 50, it is rejected on the same basis as claim 1. In addition, Chang taught wherein adjusting the first resource used for the cloud service comprises one or more of: adjusting a quality of service policy for a port of a service object implementing the cloud service; adjusting a priority of traffic used for the cloud service; adjusting a multi-queue configuration of a network adapter used to transmit a service packet for the cloud service; or adjusting a deployment location of the service object implementing the cloud service (0058, where the deployment adjusts the system resources and performs the associated actions to allow them to be properly deployed).
Claim(s) 33 is rejected under 35 U.S.C. 103 as being unpatentable over Stenberg, in view of Lucs, in view of Chang, in view of George, in view of Zerr, and in further view of Sharma et al. (Pre-Grant Publication No. US 2019/0363954 A1), hereinafter Sharma.
9. As for claim 33, it is rejected on the same basis as claim 1. However, Chang did not explicitly state providing, to the terminal device, a graphical user interface, wherein the graphical user interface is configured to receive a service identifier, a service object identifier, and a latency upper limit value, and wherein receiving the latency requirement parameter comprises receiving, from the graphical user interface, the service identifier, the service object identifier, and the latency upper limit value. On the other hand, Sharma did teach providing, to the terminal device, a graphical user interface, wherein the graphical user interface is configured to receive a service identifier, a service object identifier, and a latency upper limit value, and wherein receiving the latency requirement parameter comprises receiving, from the graphical user interface, the service identifier, the service object identifier, and the latency upper limit value (0014, where the GUI can be seen in 0078). Both of the systems of Chang and Sharma are directed to QoS management and therefore, it would have been obvious to a person having ordinary skill in the art, at the time of the effective filing of the invention, to modify the teachings of Chang, to utilize a graphical user interface that specifically allows a user to enter desired requirements, as it could be argued that the GUI would’ve been required at some point in order to perform the functions. However, Sharma provides a more explicit showing the claimed limitation.
Claim(s) 39-40 and 45-46 are rejected under 35 U.S.C. 103 as being unpatentable over Stenberg, in view of Von, in view of Dilley, in view of George, in view of Zerr, and in further view of Watt et al. (Pre-Grant Publication No. US 2021/0099542 A1), hereinafter Watt.
10. As for claims 39 and 45, they are rejected on the same basis as claims 1 and 12 (respectively). However, the combination of Stenberg and Dilley did not explicitly state wherein the configuration for implementing the cloud service further comprises a number of cores of each of the processors and a memory size of each of the processors to implement the cloud service. On the other hand, Watt did teach wherein the configuration for implementing the cloud service further comprises a number of cores of each of the processors and a memory size of each of the processors to implement the cloud service (0017). Both of the systems of Dilley and Watt are directed towards managing the provisioning of resources and therefore, it would have been obvious to a person having ordinary skill in the art, at the time of the effective filing of the invention, to modify the teachings of Dilley, to utilize specifying the number of cores and memory per processor, as taught by Watt, in order to efficiently implement the user’s desired system.
11. As for claims 40 and 46, they are rejected on the same basis as claims 39 and 45 (respectively). In addition, Dilley taught wherein the bandwidth limits comprise bandwidth limits of ports of the virtual machines to implement the cloud service (21:18-21).
Claim(s) 44 and 47 rejected under 35 U.S.C. 103 as being unpatentable over Stenberg, in view of Lucas, in view of Chang, and in further view of Official Notice.
12. As for claims 44 and 47, they are rejected on the same basis as claim 1 and 12 (respectively). However, Lucas did not explicitly state pre-charging for latency assurance; and performing, based on actual usage of a final resource, settlement for the latency assurance. On the other hand, business strategies, such as charging for usage were well known and therefore, it would have been obvious to a person having ordinary skill in the art, at the time of the effective filing of the invention, to modify the teachings of Stenberg, to utilize charging strategies for actual usage, in order to efficiently bill clients for their usage.
Response to Arguments
Applicant’s arguments with respect to the claim(s) have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 JOSEPH L GREENE whose telephone number is (571)270-3730. The examiner can normally be reached Monday - Thursday, 10:00am - 4:00pm.
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, Nicholas R. Taylor can be reached at 571 272-3889. 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.
/JOSEPH L GREENE/Primary Examiner, Art Unit 2443
Prosecution Insights