DETAILED ACTION
Claims 1, 3-18, and 21-22 remain for examination. The amendment filed 7/22/26 amended claims 1, 15, & 21; and cancelled claim 2.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 6/23/26 has been considered by the examiner.
Response to Arguments
Applicant’s arguments, see pages 8-9 of the amendment filed 7/22/26, with respect to the rejections under 35 USC 101 have been fully considered and are persuasive. The rejection of claims 1-18 and 21-22 under 35 USC 101 has been withdrawn.
Applicant's arguments filed 7/22/26 regarding the rejection of the claims under 35 USC 102 have been fully considered but they are not persuasive. Applicant argues:
According to paragraph [0018] of Starr, the "intent" generally refers to an overall desired outcome. However, the user strategy in the amended claims indicates at least one of a network function or a security function desired by a user. Starr fails to define that the overall desired outcome is the at least one of a network function or a security function desired by a user. Thus, Starr does not implement a user strategy that is equivalent to the user strategy recited in the amended independent claims.
Examiner disagrees, noting that paragraph 0018 rather clearly describes the purpose of Starr’s invention as follows:
In effect, the O&A platform maintains a knowledge of what is required to implement a given intent, and upon receiving a change request that is ignorant of all of the changes required to implement the intent of the change request, the O&A platform translates the intent into hardware and software application changes specific to the hardware and software applications used in the particular scenario to effectuate the intent.
As but one non-limiting example, Starr discloses wherein one can use his invention to configure a firewall to provision a new user with certain permissions, or otherwise change the security policy implemented by said firewall, as disclosed in paragraphs 0039-0041 (emphasis Examiner’s):
[0039] As used herein, a “change class” generally refers to groupings of types of changes that have similar life cycles. Non-limiting examples of change classes include, but are not limited to, a Life Cycle Management (LCM) class, a Configuration Management (CM) class, and a Customer Configuration Management (CCM) class. The LCM class may include system changes (e.g., operating system upgrades to infrastructure associated with the O&A platform) having the potential to impact multiple customers of the O&A platform. The CM class may include system-specific configurations (e.g., initial provisioning of a Firewall as a Service (FWaaS) customer or adding a new virtual private network (VPN) server) having the potential to impact a single customer of the O&A platform. The CCM class may include customer-specific configurations (e.g., internal policy updates to their cloud firewall or endpoint control or changing Web Application Firewall (WAF) domain settings), the impact of which is limited to the customer at issue. Based upon the disclosure provided herein, one of ordinary skill in the art will recognize a variety of change classes that may be used in relation to various embodiments discussed herein.
[0040] As used herein, a “configurable endpoint” or just “endpoint” generally refers to any device or software application that is configurable by O&A platform whose configuration, state, and/or behavior can be changed by a change source. Non-limiting examples of configurable endpoints include, but are not limited to, infrastructure associated with the O&A platform, such as servers, network devices, network security appliances, VMs, network service, network security service, desktop computers, tablets, phones, and/or the cloud enabled services. Based upon the disclosure provided herein, one of ordinary skill in the art will recognize a variety of configurable endpoints that may be configured using embodiments discussed herein.
[0041] As used herein, a “job” generally refers to a request that is a group of one or more tasks that when performed together effectuate a specific intent. For example, creating an internal policy via a portal for a customer using FWaaS might have multiple jobs, and one of the jobs might be to create a security policy on a firewall. Doing this might require multiple tasks (e.g., a couple of discrete “set” commands) like giving the policy a name, setting the source/destination IP addresses, or applying advanced security profiles. Based upon the disclosure provided herein, one of ordinary skill in the art will recognize a variety of jobs that may be performed in relation to one or more embodiments to effectuate a specific intent.
A firewall would be reasonably construed as either or both of a “network function module” or a “security function module” under the broadest reasonable interpretation of the terms in view of the instant specification. Regardless, given a user’s request to e.g. change a firewall’s settings, the Starr invention will clearly select the firewall and determine what specific steps it must take in order to implement what the user requested, which the Examiner maintains reads on the claims as currently presented.
Applicant’s remaining arguments are rebutted for substantially similar reasons as discussed supra.
Claim Rejections - 35 USC § 102
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1, 3-18 and 21-22 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Starr (U.S. Patent Publication 2022/0261276).
Regarding claim 1:
Starr discloses a method for function orchestration, comprising: obtaining a user strategy, wherein the user strategy indicates at least one of a network function or a security function desired by a user (the “intents”, which describe an overall goal that a user is trying to achieve: see paragraph 0018: “As used herein, an “intent” generally refers to an overall desired outcome. Conveying intent is a simplified way of communicating a desired outcome to an orchestration and automation (O&A) platform, and in turn the O&A platform translates the intent into a myriad of operations (jobs and then tasks) that effectuate the overall outcome corresponding to the intent”; see also paragraph 0046: “O&A platform 106 may retrieve change requests from a change source, where the change request is a representation of an intent to perform a certain action(s) on one or more configurable endpoint devices located across different networks…The change sources may include, but are not limited to, a user interacting with the O&A platform 106 or a machine or process generating alerts, instructions, or commands” [emphasis Examiner’s]); obtaining a first sequence based on the user strategy (the intent is converted into a sequence of one or more jobs, which in turn are comprised of one or more tasks; see paragraph 0018 as cited supra; and paragraphs 0041-0042, including “As used herein, a “job” generally refers to a request that is a group of one or more tasks that when performed together effectuate a specific intent” and “As used herein, a “task” generally refers to a single interaction with a configurable endpoint that by itself has a specific intent”); and sending the first sequence to enable a function module receiving the first sequence to provide a network and security service desired by a user based on the first sequence (paragraph 0047: “In an embodiment, O&A platform 106 categorizes the change request into a particular change class (i.e., one of a number of possible change classes), determines multiple jobs that are required to be completed to effectuate the change request, and assigns one or more automation engines to execute tasks associated with the aforementioned multiple jobs” [emphasis Examiner’s]; see also e.g. paragraph 0041: “For example, creating an internal policy via a portal for a customer using FWaaS might have multiple jobs, and one of the jobs might be to create a security policy on a firewall. Doing this might require multiple tasks (e.g., a couple of discrete “set” commands) like giving the policy a name, setting the source/destination IP addresses, or applying advanced security profiles”), wherein obtaining the first sequence comprises: obtaining a first sequence that comprises at least one of a network function module or a security function module, by analyzing the user strategy and selecting the at least one of the network function module or the security function module (paragraph 0047, including: “O&A platform 106 determines the change type associated with the particular class. O&A platform 106 orchestrates the performance of one or more jobs based on the particular class in part by determining a prerequisite for completing one or more jobs”; see also paragraph 0041).
Regarding claim 3: Starr further discloses wherein obtaining the first sequence based on the user strategy comprises: obtaining the first sequence, by determining an identifier of each module in the first sequence based on at least one of: a description of a network function module, a description of a security function module, a module identifier, or a plurality of function descriptions in the user strategy; wherein the plurality of function descriptions in the user strategy indicate a description of the network function desired by the user and/or a description of the security function desired by the user (Starr, paragraph 0078, including “Change anatomy 600 may include metadata fields, configuration data fields, and status fields. The metadata fields include a unique identifier assigned to a change (UUID) request, change source details (e.g., change source ID, or IP address), type of change being requested, version of the change type, timestamp of the change request and “Not-before” field. The UUID is used as a unique reference for auditing, rollback, associating telemetry data, etc. The change source, type, and version together give orchestration the context it needs to start processing the change request. The unique change source (portal), type (initial FWaaS), and version allows for orchestration to invoke the correct automation engine, proper location(s) to pull data from and invoke the correct permutation with which to interact with the appropriate configurable endpoints”; and paragraph 0081, including “In an embodiment, the system may identify a candidate automation engine based on change type/class combo”).
Regarding claim 4: Starr further discloses further comprising: receiving registration information sent by a plurality of function modules, wherein the registration information carries at least one of: identifier information of each function module, a description of a network function, or a description of a security function (paragraph 0081, and Figure 7).
Regarding claim 5: Starr further discloses wherein obtaining the first sequence based on the user strategy comprises: obtaining the first sequence based on the user strategy and a preset rule (the invention inherently has a preset rule to categorize each change request into a change class, as per paragraph 0047: “In an embodiment, O&A platform 106 categorizes the change request into a particular change class (i.e., one of a number of possible change classes), determines multiple jobs that are required to be completed to effectuate the change request, and assigns one or more automation engines to execute tasks associated with the aforementioned multiple jobs” [emphasis Examiner’s]; and paragraph 0022: “The methods further include categorizing, by the O&A module, the change request into a particular change class. The particular change class is one of a plurality of change classes, and the particular change class indicates one or more jobs to be performed to effectuate the change request”; see also paragraph 0039 regarding “change classes”).
Regarding claim 6: Starr further discloses wherein obtaining the first sequence based on the user strategy and the preset rule comprises: determining a plurality of function modules, based on at least one of: a description of a network function module, a description of a security function module, a module identifier, or a plurality of function descriptions in the user strategy; and obtaining the first sequence based on the preset rule and the plurality of function modules (paragraph 0047, including: “O&A platform 106 determines the change type associated with the particular class. O&A platform 106 orchestrates the performance of one or more jobs based on the particular class in part by determining a prerequisite for completing one or more jobs”).
Regarding claim 7: Starr further discloses wherein obtaining the first sequence based on the preset rule and the plurality of function modules comprises: obtaining the first sequence, by selecting and/or sorting the plurality of function modules based on the preset rule (Ibid).
Regarding claim 8: Starr further discloses: receiving operating state information sent by the plurality of function modules (paragraph 0068, including: “The metadata and configuration data present within the change request may include a variety of information about the systems and/or software applications issuing the change request including, but not limited to, current user profiles”); wherein obtaining the first sequence based on the preset rule and the plurality of function modules comprises: obtaining the first sequence, by selecting the plurality of function modules based on the operating state information (Ibid).
Regarding claim 9: Starr further discloses wherein obtaining the first sequence based on the preset rule and the plurality of function modules comprises: obtaining the first sequence based on at least one of network topology, network latency, or load balancing of network traffic (network latency considerations at paragraph 0047: “While scheduling the jobs, the O&A platform 106 tries to minimize the overall time required to complete one or more jobs while ensuring minimal locking and disturbance to other resources and services”).
Regarding claim 10: Starr further discloses wherein obtaining the first sequence based on at least one of the network topology, the network latency, or the load balancing of network traffic comprises: obtaining a source address and a destination address in the user strategy (paragraph 0041: “…setting the source/destination IP addresses…”); and obtaining the first sequence based on at least one of the network topology, the network latency, or the load balancing of network traffic (paragraph 0047).
Regarding claim 11: Starr further discloses wherein the first sequence matches some or all of forwarding paths determined based on the source address and the destination address (paragraphs 0019 & 0041).
Regarding claim 12: Starr further discloses wherein obtaining the first sequence based on at least one of the network topology, the network latency, or the load balancing of network traffic comprises: obtaining an assets address in the user strategy (paragraphs 0041 & 0078); and obtaining the first sequence based on at least one of the network topology, the network latency, or the load balancing of network traffic (paragraph 0047).
Regarding claim 13: Starr further discloses wherein some or all of the function modules indicated in the first sequence are function modules reachable to the assets address via a network (Ibid; see also Figure 1).
Regarding claim 14: Starr further discloses wherein sending the first sequence comprises: sending the first sequence and a strategy corresponding to each function module in the first sequence, wherein the strategy corresponding to each function module is obtained based on the user strategy (paragraphs 0041-0042).
Regarding claim 15:
Starr discloses a method for function orchestration, comprising: receiving a first sequence, wherein the first sequence is obtained based on a user strategy (paragraph 0047: “In an embodiment, O&A platform 106 categorizes the change request into a particular change class (i.e., one of a number of possible change classes), determines multiple jobs that are required to be completed to effectuate the change request, and assigns one or more automation engines to execute tasks associated with the aforementioned multiple jobs” [emphasis Examiner’s]), and the user strategy indicates a network function and/or a security function desired by a user (paragraph 0018: “As used herein, an “intent” generally refers to an overall desired outcome. Conveying intent is a simplified way of communicating a desired outcome to an orchestration and automation (O&A) platform, and in turn the O&A platform translates the intent into a myriad of operations (jobs and then tasks) that effectuate the overall outcome corresponding to the intent”; see also paragraph 0046: “O&A platform 106 may retrieve change requests from a change source, where the change request is a representation of an intent to perform a certain action(s) on one or more configurable endpoint devices located across different networks…The change sources may include, but are not limited to, a user interacting with the O&A platform 106 or a machine or process generating alerts, instructions, or commands” [emphasis Examiner’s]); and providing a network and security service desired by a user based on the first sequence (paragraph 0041: “For example, creating an internal policy via a portal for a customer using FWaaS might have multiple jobs, and one of the jobs might be to create a security policy on a firewall. Doing this might require multiple tasks (e.g., a couple of discrete “set” commands) like giving the policy a name, setting the source/destination IP addresses, or applying advanced security profiles”), wherein obtaining the first sequence comprises: obtaining a first sequence that comprises at least one of a network function module or a security function module, by analyzing the user strategy and selecting the at least one of the network function module or the security function module (paragraph 0047, including: “O&A platform 106 determines the change type associated with the particular class. O&A platform 106 orchestrates the performance of one or more jobs based on the particular class in part by determining a prerequisite for completing one or more jobs”; see also paragraph 0041).
Regarding claim 16: Starr further discloses further comprising: sending registration information, wherein the registration information carries at least one of: identifier information of each function module, a description of a network function, or a description of a security function (paragraph 0081, and Figure 7).
Regarding claim 17: Starr further discloses further comprising: sending operating state information, wherein the operating state information is configured to obtain the first sequence by selecting a plurality of function modules based on the operating state information (paragraph 0068: “The metadata and configuration data present within the change request may include a variety of information about the systems and/or software applications issuing the change request including, but not limited to, current user profiles”).
Regarding claim 18: Starr further discloses wherein receiving the first sequence comprises: receiving the first sequence and a strategy corresponding to each function module in the first sequence, wherein the strategy corresponding to each function module is obtained based on the user strategy (paragraphs 0041-0042).
Regarding claim 21:
The rejection of claim 1 applies mutatis mutandis to claim 21.
Regarding claim 22:
The rejection of claim 15 applies mutatis mutandis to claim 22.
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 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 Thomas A Gyorfi whose telephone number is (571)272-3849. The examiner can normally be reached 10:00am - 6:30pm.
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, Amir Mehrmanesh can be reached at 571-270-3351. 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.
THOMAS A. GYORFI
Examiner
Art Unit 2435
/THOMAS A GYORFI/Examiner, Art Unit 2435 10/2/2026
/AMIR MEHRMANESH/Supervisory Patent Examiner, Art Unit 2435
