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 – 20 are currently pending in this application.
Claims 1, 8, 15, and 18 are amended as filed on 02/04/2026.
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 (i.e., changing from AIA to pre-AIA ) 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-4, 7-9, 11, 14-15, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Carranza Giotto et al. (Patent No. US 10,212,034 B1), hereinafter Carranza, in view of Golla et al. (Pre-Grant Publication No. US 2021/0234754 A1), hereinafter Golla, and in further view of Patino-Bueno et al. (Pre-Grant Publication No. US 2016/0378437 A1), hereinafter Patino.
2. With respect to claims 1 and 8, Carranza taught a method comprising: obtaining, by a processing system including a processor, a plurality of workflows associated with executing one or more changes in a communications network (Title & abstract), wherein each workflow is generated by graphically selecting a sequence of building blocks via a user interface that facilitate a composition of a catalog of building blocks (11:48 to 12:8), wherein each building block has an application programming interface (11:30-38, where the API is given in order to be able to translate selected scripts into updating their associated resources) and wherein each building block in the sequence executes a specific function needed to implement a specific change in the communications network and the selected sequence of building blocks aligns input and output of each workflow with inputs and outputs of the building blocks in the sequence (11:48 to 12:8. See also, the deployment schedule of 6:37-52), and each generated workflow is associated with an application resource container, the application resource container including a meta-code stitching of the building blocks in the sequence into the associated workflow and being referenced using the API for a newly created workflow (6:37-52, where the stitching of the code is given in order to the deployment schedule to function automatically after being implemented. Further, the modules containing associated metadata can be seen in 8:1-45); obtaining, by the processing system, one or more verification rules for comparing pre-impact network performance and post-impact network performance associated with the one or more changes (5:65 to 6:10); determining, by the processing system, a schedule for deploying the one or more changes in the communications network, wherein the deploying the one or more changes is based on the plurality of workflows, the one or more verification rules, and scheduling constraints (6:37-52. See also: 6:53 to 7:13. Accordingly, the workflow is given in accordance with scripting order and the verification can be seen in 8:24-45),
wherein the scheduling constraints comprise a conflict scope constraint (6:53 to 7:13, where this, at least, teaches the conflict scope constraint as it’s defined in the applicant’s specification: 0032); executing, by the processing system, the one or more changes in the communications network according to the schedule by invoking the API (6:11-25); subsequent to executing the one or more changes in the communications network, determining, by the processing system, whether a comparison of the pre-impact network performance and the post-impact network performance is within one or more thresholds associated with the one or more verification rules (5:65 to 6:10); and sending, by the processing system, an alert when the comparison is outside the one or more thresholds (10:59-67).
However, Carranza did not explicitly state that the API was a REST API and
wherein the scheduling constraints comprise, a concurrency constraint, a uniformity constraint, and a localize constraint. On the other hand, Golla did teach that the API was a REST API (0073) and wherein the scheduling constraints comprise, a concurrency constraint, a uniformity constraint, and a localize constraint (0040 & 0053, where the concurrency constraint can be seen in 0093). Both of the systems of Carranza and Golla are directed towards managing policy/change prioritization of network devices 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 Carranza, to utilize a REST API as well as the specified constraints, as taught by Golla, a these were standard interfaces and constraints that were contemporary to the time of the invention for managing deployment of devices.
However, Carranza did not explicitly state that at a building block level, each individual building block has a REST API. On the other hand, Patino did teach that at a building block level, each individual building block has a REST API (0012 & 0071). Both of the systems of Golla and Patino are directed towards REST APIs 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 Golla, to utilize each building block containing a REST API, as taught by Patino, as doing so allows the REST system to more easily interface with the workflow blocks.
3. With respect to claim 15, Carranza taught a non-transitory, computer readable storage medium storing computer executable instructions that when executed by a computing device cause said computing device to effectuate operations comprising: obtaining a plurality of workflows associated with executing one or more changes in a communications network, wherein each workflow is generated by graphically selecting a sequence of building blocks, and wherein each building block in the sequence executes a specific function needed to implement a specific change in the communications network and the sequence of building blocks aligning input and output of each workflow with inputs and outputs of the building blocks in the sequence (11:48 to 12:8), wherein each building block has an application programming interface (11:30-38, where the API is given in order to be able to translate selected scripts into updating their associated resources); and each generated workflow is associated with an application resource container including a meta-code stitching of the building blocks in the sequence into the associated workflow, the application resource container being referenced using the REST API for a newly created workflow (6:37-52, where the stitching of the code is given in order to the deployment schedule to function automatically after being implemented. Further, the modules containing associated metadata can be seen in 8:1-45); obtaining one or more verification rules for comparing pre-impact network performance and post-impact network performance associated with the one or more changes (5:65 to 6:10); automatically discovering a schedule for deploying the one or more changes in the communications network that conforms to a scheduling constraint, wherein the deploying the one or more changes is based on the plurality of workflows and the one or more verification rules (6:37-52. See also: 6:53 to 7:13. Accordingly, the workflow is given in accordance with scripting order and the verification can be seen in 8:24-45), wherein the scheduling constraints comprise a conflict scope constraint (6:53 to 7:13, where this, at least, teaches the conflict scope constraint as it’s defined in the applicant’s specification: 0032); executing, by the processing system, the one or more changes in the communications network according to the schedule by invoking the API (6:11-25); subsequent to executing the one or more changes in the communications network, determining, by the processing system, whether a comparison of the pre-impact network performance and the post-impact network performance is within one or more thresholds associated with the one or more verification rules (5:65 to 6:10); and sending, by the processing system, an alert when the comparison is outside the one or more thresholds (10:59-67); and halting or reversing the one or more changes in the communications network when the comparison is outside the one or more thresholds (10:59-67).
However, Carranza did not explicitly state that the API was a REST API and
wherein the scheduling constraints comprise, a concurrency constraint, a uniformity constraint, and a localize constraint. On the other hand, Golla did teach that the API was a REST API (0073) and wherein the scheduling constraints comprise, a concurrency constraint, a uniformity constraint, and a localize constraint (0040 & 0053, where the concurrency constraint can be seen in 0093). Both of the systems of Carranza and Golla are directed towards managing policy/change prioritization of network devices 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 Carranza, to utilize a REST API as well as the specified constraints, as taught by Golla, a these were standard interfaces and constraints that were contemporary to the time of the invention for managing deployment of devices.
However, Carranza did not explicitly state that at a building block level, each individual building block has a REST API. On the other hand, Patino did teach that at a building block level, each individual building block has a REST API (0012 & 0071). Both of the systems of Golla and Patino are directed towards REST APIs 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 Golla, to utilize each building block containing a REST API, as taught by Patino, as doing so allows the REST system to more easily interface with the workflow blocks.
4. As for claim 2, it is rejected on the same basis as claim 1. In addition, Carranza taught halting or reversing the one or more changes in the communications network when the comparison is outside the one or more thresholds (10:59-67).
5. As for claim 3, it is rejected on the same basis as claim 1. In addition, Golla taught wherein the scheduling constraints comprise a consistency constraint including deploying software upgrades by grouping base stations operating under at least two different communication standards together (0040, where the grouped-localized devices could utilize a plurality of protocols in accordance with 0041 & 0043, and wherein network devices includes base stations under broadest reasonable interpretation).
6. As for claim 4, it is rejected on the same basis as claim 1. In addition, Carranza taught wherein the conflict scope constraint avoids concurrent changes on the same network function instance by dependent network function instances on a service chain or by multiple work groups (6:53 to 7:13).
7. As for claim 7, it is rejected on the same basis as claim 8. In addition, Golla taught wherein the determining the schedule further comprises automatically discovering a new schedule that conforms to the conflict scope constraint, the concurrency constraint, the uniformity constraint, the localize constraint, and a consistency constraint in response to a request to change the schedule (0101, where the policy mapper and scheduler discovers that appropriate policies, which would conform to the required constraints listed in 0040, 0053, & 0093).
8. As for claim 9, it is rejected on the same basis as claim 8. In addition, Carranza taught halting or reversing the one or more changes in the communications network when the comparison is outside the threshold (10:59-67).
9. As for claim 11, it is rejected on the same basis as claim 8. In addition, Carranza taught wherein the comparison comprises service performance (5:65 to 6:10).
10. As for claim 14, it is rejected on the same basis as claim 8. In addition, Golla taught wherein the scheduling constraints comprise a consistency constraint (0093).
11. As for claim 18, it is rejected on the same basis as claim 15. In addition, Carranza taught wherein the input of each workflow comprises a network function instance and the output of each workflow comprises a status of execution (9:13-24).
Claim(s) 5-6, 10, and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Carranza, in view of Golla, in view of Patino, and in further view of Young et al. (Pre-Grant Publication No. US 2022/0030117 A1), hereinafter Young.
12. As for claim 5, it is rejected on the same basis as claim 1. However, Carranza did not explicitly state wherein the one or more thresholds is for one or more key performance indicators that comprise latency in a geographic location involving one or more nodes that changed during the one or more changes in the communications network. On the other hand, Young did teach wherein the one or more thresholds is for one or more key performance indicators that comprise latency in a geographic location involving one or more nodes that changed during the one or more changes in the communications network (0046). Both of the systems of Carranza and Young are directed towards managing network devices 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 Carranza, to utilize the specific KPIs and changes, listed by Young, in order to efficiently manage network changes.
13. As for claim 6, it is rejected on the same basis as claim 1. In addition, Young taught wherein the one or more thresholds is for one or more key performance indicators that comprise successful voice and data establishments, call drops, and latency (0046).
14. As for claim 10, it is rejected on the same basis as claim 8. However, Carranza did not explicitly state wherein the deploying the one or more changes in the communications network further comprises deploying the one or more changes for network devices including eNodeBs, gNodeBs, smart integrated access device, MME or a combination thereof. On the other hand, Young did teach wherein the deploying the one or more changes in the communications network further comprises deploying the one or more changes for network devices including eNodeBs, gNodeBs, smart integrated access device (SIAD), MME or a combination thereof (0046, where this, at least, teaches the gNodeB and MME limitations). Both of the systems of Carranza and Young are directed towards managing network devices 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 Carranza, to utilize the specific KPIs and changes, listed by Young, in order to efficiently manage network changes.
15. As for claim 12, it is rejected on the same basis as claim 8. However, Carranza did not explicitly state wherein the threshold is for one or more key performance indicators that comprise latency in a geographic location involving one or more nodes that changed during the one or more changes in the communications network. On the other hand, Young did teach wherein the threshold is for one or more key performance indicators that comprise latency in a geographic location involving one or more nodes that changed during the one or more changes in the communications network (0036 & 0046). Both of the systems of Carranza and Young are directed towards managing network devices 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 Carranza, to utilize the specific KPIs and changes, listed by Young, in order to efficiently manage network changes.
16. As for claim 13, it is rejected on the same basis as claim 8. In addition, Young taught wherein the threshold is for one or more key performance indicators that comprise successful voice and data connection establishments (0046).
Claim(s) 16-17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Carranza, in view of Golla, in view of Patino, and in further view of Alluboyina et al. (Patent No. US 11,108,638 B1), hereinafter Allu.
17. As for claim 16, it is rejected on the same basis as claim 15. However, Carranza did not explicitly state wherein the obtaining the plurality of workflows further comprises obtaining one or more workflows directed to a software upgrade workflow using the building blocks of a health check block, a software upgrade block, a pre/post comparison block, and a roll-back block. On the other hand, Allu did teach wherein the obtaining the plurality of workflows further comprises obtaining one or more workflows directed to a software upgrade workflow using the building blocks of a health check block, a software upgrade block, a pre/post comparison block (6:39-48, where the health check & upgrade can be seen in 3:54-60, and where the comparison can be seen in 7:43-49), and a roll-back block (3:54-60. See also, Carranza: 2:21-23). Both of the systems of Carranza and Allu are directed towards managing network devices 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 Carranza, to utilize specific workflow controls, as taught by Allu, in order to maintain an efficient system.
18. As for claim 17, it is rejected on the same basis as claim 16. In addition, Allu taught wherein the software upgrade workflow further comprises decisions operators after the health check block, the software upgrade block, and the pre/post comparison block (7:43-49 & 3:54-60, where the decision to perform further actions was previously shown by Carranza: 2:21-23).
19. As for claim 19, it is rejected on the same basis as claim 15. However, Carranza did not explicitly state wherein each building block corresponds to a node and an edge connects two building blocks. On the other hand, Allu did teach wherein each building block corresponds to a node and an edge connects two building blocks (1:62-64 & figure 6). Both of the systems of Carranza and Allu are directed towards managing network devices 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 Carranza, to utilize specific workflow controls, as taught by Allu, in order to maintain an efficient system.
Claim(s) 20 is rejected under 35 U.S.C. 103 as being unpatentable over Carranza, in view of Golla, in view of Patino, in view of Allu, and in further view of Official Notice.
20. As for claim 20, it is rejected on the same basis as claim 19. However, the combination of Carranza and Allu did not explicitly state wherein the obtaining one or more verification rules further comprises checking a presence of a building block having no edge. On the other hand, the examiner gives official notice that having an unconnected block return a null result was well known as part of workflow interfacing 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 the combination of Carranza and Allu, to utilize the specific GUI verification techniques, as claimed with official notice, in order to effectuate an easy to use system for establishing workflow rules and their associated configuration setups and testing.
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