DETAILED ACTION
This office action is responsive to amendment filed on March 17, 2026 in this application Karani, U.S. Patent Application No. 18/429,412, (Filed January 31, 2024) (“Karani”). Claims 1 – 20 were pending. Claims 1, 2, 4 – 6, 8, 9, 11 – 13, 15, 16, and 18 – 20 are amended. Claims 1 - 20 are pending.
Applicants' arguments have been carefully and respectfully considered and found not persuasive. Accordingly, this action has been made FINAL.
Information Disclosure Statement
The information disclosure statement(s) (IDS) filed on 3/17/2026, 7/22/2026, and 9/1/2026 are in compliance with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609. The references listed therein have been considered and placed in the application file.
Response to Arguments
1. With respect to Applicant’s argument on pgs. 8 - 18 of the Applicant’s Remarks (“Remarks”) stating that the references cited in the Double Patenting rejections fail to disclose every limitation of the currently amended claims, examiner respectfully agrees. See infra § Claim Rejections - 35 USC §103, § Double Patenting. Prior art reference Shantharam is added which teaches the newly added limitations and the basis for the Double Patenting rejection has been adjusted to an obviousness based rejection. See infra.
Therefore, the claims remain rejected under Double Patenting.
2. With respect to Applicant’s argument on pgs. 23 - 24 of the Remarks stating that Applicant disagrees claims 8 – 20 are not indefinite because “the software is configurable during execution to perform these operations or not,” examiner respectfully disagrees. See infra § Claim Rejections - 35 USC §112. The claim recites that the “instructions…are configurable” which under the broadest reasonable interpretation includes where the instructions are presently not configured to perform the recited operations. Thus, claims 8 - 20 directed to a non-transitory storage medium providing instructions would, under the BRI, not perform the operations recited when executed if the instruction were not properly configured to do so. Examiner suggests deleting “are configurable to” to overcome the rejection.
Therefore, the claims remain rejected under 35 USC 112.
3. With respect to Applicant’s argument on pgs. 24 - 32 of the Remarks stating that a combination of Liljeback and Verma would fail to teach “a single risk level for a current release across a plurality of container clusters”, examiner respectfully agrees in part. See infra § Claim Rejections - 35 USC §103, § Claim 1. Prior art reference Shantharam is added which teaches the newly added limitations of “a single risk level for a current release across a plurality of container clusters”. Shantharam teaches a software update may be automatically analyzed to identify the severity level of the software and the update installed on a target group of devices based on the identified severity level of the update in combination with features of the devices in the group such as a match between the operating system the update applies to and the operating system running on devices in the group. Id. at ¶¶ 0016, 0040 – 0043, 0064 – 0067, 0072, 0075, 0083.
Therefore, the current prior art references teach “a single risk level for a current release across a plurality of container clusters.”
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 claims at issue 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
1. Claims 1, 8, and 15 are provisionally rejected on the ground of obviousness double patenting as being unpatentable over the following claims of U.S. Applications: Claims 1, 6, and 7 of 18/429,415. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of each Application anticipate the claims of the instant Application with the exception of the limitations “a single risk level” which would be obvious to one having ordinary skill in the art before the effective filing date of the claimed invention in light of the teachings of prior art reference Shantharam (see infra) which teaches a software update may be automatically analyzed to identify the severity level of the software and the update installed on a target group of devices based on the identified severity level of the update in combination with features of the devices in the group such as a match between the operating system the update applies to and the operating system running on devices in the group. Shantharam at ¶¶ 0016, 0040 – 0043, 0064 – 0067, 0072, 0075, 0083. One of ordinary skill the art would have been motivated to combine the teachings of the prior art reference with the Application for the purpose of using a known severity level stagger method with deployment method that requires staggering deployments based on stagger goals.
Claims 2 – 7, 9 - 14, and 16 – 20 are provisionally rejected on the ground of obviousness type double patenting as being unpatentable over the previous claims and applications. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims are obvious in view of the Applications cited and the art used infra to teach the dependent claims and associated motivation.
This is a provisional obviousness double patenting rejection because the conflicting claims have not in fact been patented.
2. Claims 1, 8, and 15 are rejected on the ground of obviousness double patenting as being unpatentable over the following claims of U.S. Patents: Claims 1 & 5 of 12,737,169 and Claim 1 of 12,438,773. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the Patents anticipate the claims of the instant Application with the exception of the limitations “a single risk level” which would be obvious to one having ordinary skill in the art before the effective filing date of the claimed invention in light of the teachings of prior art reference Shantharam (see infra) which teaches a software update may be automatically analyzed to identify the severity level of the software and the update installed on a target group of devices based on the identified severity level of the update in combination with features of the devices in the group such as a match between the operating system the update applies to and the operating system running on devices in the group. Shantharam at ¶¶ 0016, 0040 – 0043, 0064 – 0067, 0072, 0075, 0083. One of ordinary skill the art would have been motivated to combine the teachings of the prior art reference with the Patents for the purpose of using a known severity level stagger method with deployment method that requires staggering deployments based on stagger goals.
Claims 2 – 7, 9 - 14, and 16 – 20 are rejected on the ground of obviousness type double patenting as being unpatentable over the claims of the previous Patents. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims are obvious in view of the Patent/Application cited and the art used infra to teach the dependent claims and associated motivation.
Claim Rejections - 35 USC § 112(b)
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.
Claims 8 – 20 are 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 pre-AIA the applicant regards as the invention.
Claim 8 is rejected as being indefinite. Claim 8 recites “instructions…are configurable to cause the apparatus to perform operations.” It is unclear if the claimed instructions provided by the storage medium have or have not been configured to perform the steps of the claim and as such, under the broadest reasonable interpretation, none of the claim steps occur. It is therefore unclear if the term “configurable” is intended to make optional the steps of the claim or if some other meaning is intended.
Claim 15 is rejected for similar reasoning. Claims 9 – 14 and 16 - 20 are rejected as depending on claims 8 and 15 respectively.
Claim Rejections 35 U.S.C. §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 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Liljeback et al., United States Patent Application Publication No. 2022/0050675 (Published February 17, 2022, filed August 11, 2021) (“Liljeback”) in view of Verma et al., United States Patent Application Publication No. 2024/0394035 (Published November 28, 2024, filed May 25, 2023) (“Verma”) and Shantharam et al., United States Patent Application Publication No. 2018/0173517 (Published June 21, 2018, filed July 25, 2017) (“Shantharam”).
Claims 1, 8, and 15
With respect to claims 1, 8, and 15, Liljeback teaches the invention as claimed including a method for autonomous release orchestration, the method comprising: …across a plurality of container clusters; determining, …a set of one or more attributes of a stagger configuration, wherein the set of one or more attributes includes one or more of a number of staggers to include in a plurality of staggers, …and which subset of one or more of the plurality of container clusters is in each stagger in the plurality of staggers; and deploying the current release to the plurality of container clusters as a staggered release in accordance with the stagger configuration, including the determined set of one or more attributes. {Conducting a staged rollout of a software upgrade for a plurality of cloud tenant systems [container clusters] by identifying, using stagger attributes in a declarative deployment file 215, deployment groups of cloud systems to receive the upgrade, where each group is to be upgraded at a particular time and can contain geographically co-located related tenant systems, staggering the order of the deployment times of the groups to upgrade the tenant systems of each group in the specified order based on an error threshold parameter determined in part from logs of previous errors. Liljeback at Abstract; id. at ¶¶ 0015, 0016, 0028, 0032, 0035, & 0047 (grouping tenant systems based on geographically co-location, maintenance windows of low activity, and container “realms”); id. at ¶¶ 0018 & 0114 – 0119 (staggering groups); id. at ¶ 0033 (tenant systems to be upgraded are container clusters); id. at ¶¶ 0051 – 0053, 0063, 0076 (error threshold identified from prior errors and used for staggering); id. at ¶ 0038 (each update may have a type based on the risk the update will affect operation of the tenant system such as hotfix, migration, and patch updates); id. at fig. 4 (declarative deployment file 445 stagger attributes).}
However, Liljeback doesn’t explicitly teach the limitation:
an order for the staggers in the plurality of staggers, {Verma does teach this limitation. Verma teaches that staggering updates in light of errors, as taught in Liljeback, may include where the groups, or clusters of update targets are ranked as part of identifying the risk level of applying an update using a log of prior activity parameters such as the usage of update targets as represented by a target group temperature, where more staggers are used to first update lower temperature targets and then update the higher temperature targets, and where the grouping is based on the geographical location of the update targets. Verma at ¶¶ 0045, 0047, 0048, 0067; id. at ¶¶ 0005 & 0054, 0080, 0121 – 0125; id. at ¶ 0068 & 0069 (temperature and geographic region may be used together to determine stagger grouping); id. at ¶¶ 0021, 0033, 0036 - 0039 (ranking to determine an order of clusters for updating).
Liljeback and Verma are analogous art because they are from the “same field of endeavor” and are both from the same “problem-solving area.” Specifically, they are both from the field of software upgrading, and both are trying to solve the problem of how deploy updates.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine staggering updates in light of errors, as taught in Liljeback with using an order for the stagger groupings, as taught in Verma. Liljeback teaches that it is desirable to base deployments on “geographical locations of clients [and] client activity patterns.” Liljeback at ¶ 0005. Therefore, one having ordinary skill in the art would have been motivated to combine staggering updates in light of errors, as taught in Liljeback with using an order for the stagger groupings, as taught in Verma, for the purpose of using a known incremental deployment method based on incremental group updating with a deployment method that requires staggering deployments.}
However, Liljeback and Verma doesn’t explicitly teach the limitation:
obtaining a representation of a single risk level for a current release;…based at least in part on the single risk level for the current release across the plurality of container clusters, {Shantharam does teach this limitation. Shantharam teaches that staggering updates in light of a riskiness of deployment, as taught in Liljeback and Verma, may include where a software update may be automatically analyzed to identify the severity level of the software and the update installed on a target group of devices based on the identified severity level of the update in combination with features of the devices in the group such as a match between the operating system the update applies to and the operating system running on devices in the group. Shantharam at ¶¶ 0016, 0040 – 0043, 0064 – 0067, 0072, 0075, 0083.
Liljeback, Verma, and Shantharam are analogous art because they are from the “same field of endeavor” and are both from the same “problem-solving area.” Specifically, they are both from the field of software upgrading, and both are trying to solve the problem of how deploy updates.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine staggering updates in light of a riskiness of deployment, as taught in Liljeback and Verma with using the severity level of the update itself to identify update groups, as taught in Shantharam. Liljeback teaches that it is desirable to base deployments on “geographical locations of clients [and] client activity patterns.” Liljeback at ¶ 0005. Therefore, one having ordinary skill in the art would have been motivated to combine staggering updates in light of a riskiness of deployment, as taught in Liljeback and Verma with using the severity level of the update itself to identify update groups, as taught in Shantharam, for the purpose of using a known severity level stagger method bas with a stagger deployment method that requires staggering deployments based on the risk of impact of the deployment on group members.}
Claims 2, 9, and 16
With respect to claims 2, 9, and 16, Liljeback, Verma, and Shantharam, teach the invention as claimed including:
wherein the obtaining the representation of the [single] risk level comprises: obtaining an identifier that identifies one of a plurality of event log templates that each indicate different ones of event logging parameters; and obtaining from the identified event log template the representation of the [single] risk level. {The risk level of the update is determined from a log of prior activity parameters such as the usage of update targets as represented by a target group temperature, where when the risk (temperature) is higher more staggers are used to first update the lower temperature targets and then update the higher temperature targets, and where the grouping is based on the geographical location of the update targets. Verma at ¶¶ 0045, 0047, 0048, 0067; id. at ¶¶ 0005 & 0053-0054, 0080, 0121 – 0125; id. at ¶ 0068 & 0069 (temperature and geographic region may be used together to determine stagger grouping).}
single risk level {a software update may be automatically analyzed to identify the severity level of the software and the update installed on a target group of devices based on the identified severity level of the update in combination with features of the devices in the group such as a match between the operating system the update applies to and the operating system running on devices in the group. Shantharam at ¶¶ 0016, 0040 – 0043, 0064 – 0067, 0072, 0075, 0083.}
Claims 3, 10, and 17
With respect to claims 3, 10, and 17, Liljeback, Verma, and Shantharam, teach the invention as claimed including:
wherein the determining the set of one or more attributes comprises: determining which of the plurality of container clusters to include in each stagger based at least partly on geographic regions in which different ones of the plurality of container clusters are located. {The risk level of the update is determined from a log of prior activity parameters such as the usage of update targets as represented by a target group temperature, where when the risk (temperature) is higher more staggers are used to first update the lower temperature targets and then update the higher temperature targets, and where the grouping is based on the geographical location of the update targets. Verma at ¶¶ 0045, 0047, 0048, 0067; id. at ¶¶ 0005 & 0054, 0080, 0121 – 0125; id. at ¶ 0068 & 0069 (temperature and geographic region may be used together to determine stagger grouping).}
Claims 4, 11, and 18
With respect to claims 4, 11, and 18, Liljeback, Verma, and Shantharam, teach the invention as claimed including:
wherein the determining which of the plurality of container clusters to include in each stagger includes: determining whether to place different ones of the container clusters that are located in a same one of the geographic regions in different staggers or in a same stagger, wherein the determination is based at least in part on the representation of the [single] risk level. {The risk level of the update is determined from a log of prior activity parameters such as the usage of update targets as represented by a target group temperature, where when the risk (temperature) is higher more staggers are used to first update the lower temperature targets and then update the higher temperature targets, and where the grouping is based on the geographical location of the update targets. Verma at ¶¶ 0045, 0047, 0048, 0067; id. at ¶¶ 0005 & 0054, 0080, 0121 – 0125; id. at ¶ 0068 & 0069 (temperature and geographic region may be used together to determine stagger grouping).}
single risk level {A software update may be automatically analyzed to identify the severity level of the software and the update installed on a target group of devices based on the identified severity level of the update in combination with features of the devices in the group such as a match between the operating system the update applies to and the operating system running on devices in the group. Shantharam at ¶¶ 0016, 0040 – 0043, 0064 – 0067, 0072, 0075, 0083.}
Claims 5, 12, and 19
With respect to claims 5, 12, and 19, Liljeback, Verma, and Shantharam, teach the invention as claimed including:
wherein the determining the set of one or more attributes comprises: determining both the number of staggers and the order of the staggers based on the representation of the [single] risk level; and determining which ones of the plurality of container clusters to place in which ones of the plurality of staggers based on geographic regions in which the ones of the plurality of container clusters are located. {The risk level of the update is determined from a log of prior activity parameters such as the usage of update targets as represented by a target group temperature, where when the risk (temperature) is higher more staggers are used to first update the lower temperature targets and then update the higher temperature targets, and where the grouping is based on the geographical location of the update targets. Verma at ¶¶ 0045, 0047, 0048, 0067; id. at ¶¶ 0005 & 0054, 0080, 0121 – 0125; id. at ¶ 0068 & 0069 (temperature and geographic region may be used together to determine stagger grouping).}
single risk level {A software update may be automatically analyzed to identify the severity level of the software and the update installed on a target group of devices based on the identified severity level of the update in combination with features of the devices in the group such as a match between the operating system the update applies to and the operating system running on devices in the group. Shantharam at ¶¶ 0016, 0040 – 0043, 0064 – 0067, 0072, 0075, 0083.}
Claims 6, 13, and 20
With respect to claims 6, 13, and 20, Liljeback, Verma, and Shantharam, teach the invention as claimed including:
wherein the determining the set of one or more attributes comprises: determining the number of staggers to include in the plurality of staggers based at least in part on the representation of the [single] risk level, where a higher risk level corresponds to a larger number of staggers and a lower risk level corresponds to a lower number of staggers; determining which ones of the plurality of container clusters to place in which ones of the plurality of staggers based partly on the representation of the [single] risk level and partly on relationships between container clusters in the plurality of container clusters; and determining the order of the staggers based partly on the representation of the [single] risk level and partly on container cluster characteristics of the container clusters in the plurality of container clusters. {The risk level of the update is determined from a log of prior activity parameters such as the usage of update targets as represented by a target group temperature, where when the risk (temperature) is higher more staggers are used to first update the lower temperature targets and then update the higher temperature targets, and where the grouping is based on the geographical location of the update targets. Verma at ¶¶ 0045, 0047, 0048, 0067; id. at ¶¶ 0005 & 0054, 0080, 0121 – 0125; id. at ¶ 0068 & 0069 (temperature and geographic region may be used together to determine stagger grouping).}
single risk level {A software update may be automatically analyzed to identify the severity level of the software and the update installed on a target group of devices based on the identified severity level of the update in combination with features of the devices in the group such as a match between the operating system the update applies to and the operating system running on devices in the group. Shantharam at ¶¶ 0016, 0040 – 0043, 0064 – 0067, 0072, 0075, 0083.}
Claims 7 and 14
With respect to claims 7 and 14, Liljeback, Verma, and Shantharam, teach the invention as claimed including:
wherein relationships between container clusters include whether the container clusters are in a same geographic region or different geographic region, and wherein container cluster characteristics include one or more of volume of traffic and environment type. {The risk level of the update is determined from a log of prior activity parameters such as the usage of update targets as represented by a target group temperature, where when the risk (temperature) is higher more staggers are used to first update the lower temperature targets and then update the higher temperature targets, and where the grouping is based on the geographical location of the update targets. Verma at ¶¶ 0045, 0047, 0048, 0067; id. at ¶¶ 0005 & 0054, 0080, 0121 – 0125; id. at ¶ 0068 & 0069 (temperature and geographic region may be used together to determine stagger grouping).}
Conclusion
THIS ACTION IS MADE FINAL. 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 extension fee 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 THEODORE E HEBERT whose telephone number is (571)270-1409. The examiner can normally be reached on Monday to Friday 9:00 a.m. to 6:00 p.m..
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, Lewis Bullock can be reached on 571-272-3759. 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.
//T.H./ September 21, 2026
Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights