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 .
Claim Objections
Claims 1-20 are objected to because of the following informalities:
Claim 1 discloses “least one processor” (line 3), however, it is recommended that this is revised to “at least one processor.”
Claim 11 discloses “least one processor” (line 6), however, it is recommended that this is revised to “at least one processor.”
Claim 20 discloses “least one processor” (line 4), however, it is recommended that this is revised to “at least one processor.”
Claim 1 recite “the tokenized commands” (line 14), however, it recommended that this is revised to “the tokenized one or more commands.”
Claim 11 recite “the tokenized commands” (line 17), however, it recommended that this is revised to “the tokenized one or more commands.”
Claim 20 recite “the tokenized commands” (line 15), however, it recommended that this is revised to “the tokenized one or more commands.”
Claims 2-10 are 12-19 are also objected based on their dependency on the respective parent claims.
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 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
Claims 1-9, 11-20 are rejected under 35 U.S.C. 103 as being unpatentable over Nickolov et al. (US 2017/0034023, hereinafter Nickolov) in view of Rao et al. (US 11,956,123, hereinafter Rao).
Regarding claim 1, Nickolov discloses
A computer-implemented method for optimizing a distributed computing network, comprising:
receiving, by least one processor, first data characterizing one or more constituent devices of the distributed computing network, each of the one or more constituent devices (paragraph [0147]: Configuration Collection: Configuration Collection 311 may be configured or designed to include functionality for collecting configuration data from Subscriber Servers 300; paragraph [0153]: Configuration Feed: Configuration Feed 321 may be configured or designed to include functionality for receiving configuration data from the Subscriber Gateways 310 (and/or the Subscriber Servers 300 directly)) configured with a configuration structure (paragraph [0029]: the DataGrid Application may be configured or designed to expose an API (e.g., REST API) which may be used to feed configuration and signal data for servers belonging to different customer accounts to the application) comprising one or more configuration … (paragraph [0313]: In at least one embodiment, when the DataGrid System receives such a configuration it stores it in the database. In at least one embodiment in this process, the received data is separated into two sets and stored as two different records or documents. The first is termed the system record or document, and the second is termed the configuration record or document);
determining, using the at least one processor, a subset of the one or more constituent devices (paragraph [1007]: the DataGrid System may identify 347 servers which match the user specified hardware resource requirements, and may automatically and/or dynamically group the identified servers into a plurality of different logical groups based on identical or similar hardware resources and other characteristics (e.g., such as location, etc.)) based on the received first data (paragraph [1004]: Serve as a starting point for a user to manage servers, including changes to their package configurations, using server groups which are automatically created based on similar or identical characteristics (e.g., hardware, CPU type, disk type, amount of memory, location, role, application, etc.); paragraph [1005] Group servers automatically according to similar or identical characteristics (e.g., hardware type and resources));
determining, using the at least one processor, second data characterizing at least one configuration discrepancy between each of the one or more constituent devices included in the determined subset (paragraphs [1052]-[1058], [1063]-[1069]: identifying configuration discrepancies that correspond to missing security-related configuration elements, which result in vulnerabilities in the system; Note: Nickolov’s GUI 4430 displays vulnerabilities based on configuration values and other configuration elements reported from the system, including missing or improperly set commands that enable security features), the second data determined by tokenizing (paragraph [0150]: The Token Map Repository 314 may be configured or designed to include functionality for tokenization of sensitive data (e.g., in collected configurations and signals); paragraph [0744]: “To” configuration which is arrived at by upgrading or downgrading packages in the From list to their corresponding package in the To list) … each of the one or more configuration … used to configure each of the one or more constituent devices included in the determined subset (paragraph [0313]: In at least one embodiment, when the DataGrid System receives such a configuration it stores it in the database. In at least one embodiment in this process, the received data is separated into two sets and stored as two different records or documents. The first is termed the system record or document, and the second is termed the configuration record or document) and identifying the at least one configuration discrepancy (paragraphs [1052]-[1058], [1063]-[1069]: identifying configuration discrepancies that correspond to missing security-related configuration elements, which result in vulnerabilities in the system; Note: Nickolov’s GUI 4430 displays vulnerabilities based on configuration values and other configuration elements reported from the system, including missing or improperly set commands that enable security features)) based on the tokenized configuration (paragraph [0150]: The Token Map Repository 314 may be configured or designed to include functionality for tokenization of sensitive data (e.g., in collected configurations and signals); paragraph [0744]: “To” configuration which is arrived at by upgrading or downgrading packages in the From list to their corresponding package in the To list);
determining, using the at least one processor and based on the tokenized commands (paragraph [0150]: The Token Map Repository 314 may be configured or designed to include functionality for tokenization of sensitive data (e.g., in collected configurations and signals); paragraph [0744]: “To” configuration which is arrived at by upgrading or downgrading packages in the From list to their corresponding package in the To list), third data characterizing a predominant configuration profile across each of the one or more constituent devices included in the determined subset (paragraph [0227] Analyze data collected from different subscribers' Tracked Servers, both configuration and event/monitoring data, to determine configurations that are more frequently used (or indicate they are rare/unusual); paragraph [0430]: the plugin may display the DGRI Score for the current configuration, the score for the target configuration, the score change (improvement or degradation), and optionally additional information such as the number of known data points for the new configuration and vulnerability information. These data points may include: the number of systems using the target configuration historically or current; paragraph [0161]: the percentile may be showed both as of the current configuration as well as for the target configuration (e.g., after a set of changes is selected using the GUI from FIG. 33; Note: Nickolov’s teachings collectively show how the system analyzes tracked servers to find the most common (or rare) configurations, reports how many systems use a given target configuration, and provides percentile rankings—together producing data that characterizes the predominant configuration profile across the devices in a selected subset);
determining, using the at least one processor and based on the second data (paragraph [0021]: Various features of the DataGrid Technology may also be configured or designed to provide functionality for identifying troublesome configurations; paragraph [0227] Analyze data collected from different subscribers' Tracked Servers, both configuration and event/monitoring data, to determine configurations that are more frequently used (or indicate they are rare/unusual)) and third data (paragraph [0234]: Model compatibility of packages, either on the same system or across subscriber-server (or multi-point) connections, based on configurations found and positive/negative signals from differing configurations, identify particular combinations of packages/versions and configuration/operations parameters that work well together (or don't work together), make recommendations for best combinations), one or more modifications to at least one of the one or more configuration … of the one or more constituent devices (paragraph 0241] Provide a conditional software/configuration update which will be executed (or rejected) based on information provided from DataGrid service (e.g., upgrade package if the new package provides significant improvement of DGRI score, is widely deployed and it has not been found to cause problems in other deployments));
determining, using the at least one processor and based on the determined one or more modifications, fourth data characterizing a revised configuration of the one or more constituent devices (paragraph [0429]: DataGrid yum plugin: The DataGrid yum plugin intercepts configuration change operations (e.g., install, upgrade, uninstall, downgrade, as well as ‘history undo’), and after yum determines the full set of changes, including their dependencies, the plugin checks the DGRI Score and other information relevant to the confidence of the proposed configuration changes. It does this by taking the existing configuration of the server (e.g., in the form of a list of installed packages and their specific version information) and performing the changes that yum is about to do upon this list to create a target configuration. The plugin feeds the target configuration using the DataGrid API, and requests the DGRI Score for the target configuration and any additional relevant information. It then displays this information and asks the user whether or not to proceed with executing the configuration change); and
providing, by the at least one processor, the fourth data to a network configuration device to cause the revised configuration to be applied to the one or more constituent devices (paragraph [0429]: The plugin feeds the target configuration using the DataGrid API, and requests the DGRI Score for the target configuration and any additional relevant information. It then displays this information and asks the user whether or not to proceed with executing the configuration change).
Nickolov does not disclose a configuration structure comprising one or more configuration layers; tokenizing one or more commands included in each of the one or more configuration layers; the tokenized one or more commands; one or more modifications to at least one of the one or more configuration layers of the one or more constituent devices. Rao discloses a configuration structure comprising one or more configuration layers (col. 8, lines 26-38: A common mechanism for modeling the configuration states of network devices at the controller is a tree-like configuration structure. In a tree-like configuration structure, the configuration hierarchy is represented by an extensible tree diagram consisting of elements such as root node, a member that has np superior/parent, and nodes which are linked together with lines connections called branch that represent the relationships and connections between members. In a tree-like configuration hierarchy, each node may represent an aspect of the device running configurations. In some examples, the tree-like models to model configuration of network devices may include NX-OS, IOS-XR, IOS-XE, and Arista EOS); tokenizing one or more commands (col. 7, lines 45-65: CLI templates are a set of re-usable device configuration commands with the ability to parameterize select elements of the configuration as well as add control logic statements. Such (CLI) configuration template may be used by, for example, controller 116, to generate a device deployable configuration by replacing the parameterized elements (variables) with actual values and evaluating the control logic statements. Sub-templates may be regarded as a parts of configuration blocks, each of which matches an aspect of a device running configuration. A controller may generate general configuration statements from a configuration template in order to match the current running configuration of a device. The template generated configuration expressions may then be used as masks to identify matching configuration patterns in the device running configuration. When a portion of a device running configuration matching a specific sub template-generated configuration expression is found, the controller service may extract relevant network-related parameter values and other key information from the relevant portion of the device running configuration) included in each of the one or more configuration layers (col. 8, lines 26-28: A common mechanism for modeling the configuration states of network devices at the controller is a tree-like configuration structure); the tokenized one or more commands (col. 7, lines 45-65: CLI templates are a set of re-usable device configuration commands with the ability to parameterize select elements of the configuration as well as add control logic statements. Such (CLI) configuration template may be used by, for example, controller 116, to generate a device deployable configuration by replacing the parameterized elements (variables) with actual values and evaluating the control logic statements. Sub-templates may be regarded as a parts of configuration blocks, each of which matches an aspect of a device running configuration. A controller may generate general configuration statements from a configuration template in order to match the current running configuration of a device. The template generated configuration expressions may then be used as masks to identify matching configuration patterns in the device running configuration. When a portion of a device running configuration matching a specific sub template-generated configuration expression is found, the controller service may extract relevant network-related parameter values and other key information from the relevant portion of the device running configuration); one or more modifications (col. 3, lines 63-col. 4, lines 2: When the OOB changes has occurred in the configuration of a network device, the device configuration is out of synchronization state. To return the device configuration state to synchronization state, the controller may need to resynchronize the device's configuration stored in the controller to match the device configuration) to at least one of the one or more configuration layers of the one or more constituent devices (col. 8, lines 26-28: A common mechanism for modeling the configuration states of network devices at the controller is a tree-like configuration structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Nickolov incorporating Rao’s template/sub-template extraction of CLI/configuration blocks, and parsing hierarchical (tree-like) configuration blocks and extracting the constituent keywords and parameter values from each matched subtree, thereby supplying those per-layer parsed fields as normalized tokens into Nickolov’s token-map analysis and frequency/count metrics because converting parsed fields into tokens is a routine normalization step in configuration management. The motivation would have been to provide a customizable way for a user to reproducibly configure the network devices in a very efficient and concise way (Rao col. 7, lines 42-45).
Regarding claim 11 referring to claim 1, Nickolov discloses A system comprising: at least one programmable processor; and a non-transitory machine-readable medium storing instructions that, when executed by the at least one programmable processor, cause the at least one programmable processor to perform operations comprising: … (paragraph [0103]).
Regarding claim 20 referring to claim 1, Nickolov discloses A computer program product comprising a non-transitory machine-readable medium storing instructions that, when executed by at least one programmable processor, cause the at least one programmable processor to perform operations comprising: … (paragraph [0103]).
Regarding claims 2 and 12, Nickolov discloses
wherein the tokenizing (paragraph [0150]: 0150] Token Map Repository: The Token Map Repository 314 may be configured or designed to include functionality for tokenization of sensitive data (e.g., in collected configurations and signals)).
Nickolov does not disclose wherein the tokenizing of the one or more commands includes determining, for each command of the one or more commands, an array that includes at least one string and at least one value indicating a presence of the command within one of the one or more configuration layers. Rao discloses wherein the tokenizing of the one or more commands (col. 7, lines 45-65: CLI templates are a set of re-usable device configuration commands with the ability to parameterize select elements of the configuration as well as add control logic statements. Such (CLI) configuration template may be used by, for example, controller 116, to generate a device deployable configuration by replacing the parameterized elements (variables) with actual values and evaluating the control logic statements. Sub-templates may be regarded as a parts of configuration blocks, each of which matches an aspect of a device running configuration. A controller may generate general configuration statements from a configuration template in order to match the current running configuration of a device. The template generated configuration expressions may then be used as masks to identify matching configuration patterns in the device running configuration. When a portion of a device running configuration matching a specific sub template-generated configuration expression is found, the controller service may extract relevant network-related parameter values and other key information from the relevant portion of the device running configuration) includes determining, for each command of the one or more commands, an array that includes at least one string and at least one value indicating a presence of the command (col. 7, lines 60-65: When a portion of a device running configuration matching a specific sub template-generated configuration expression is found, the controller service may extract relevant network-related parameter values and other key information from the relevant portion of the device running configuration) within one of the one or more configuration layers (col. 8, lines 26-28: A common mechanism for modeling the configuration states of network devices at the controller is a tree-like configuration structure). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Nickolov incorporating Rao’s template/sub-template extraction of CLI/configuration blocks, and parsing hierarchical (tree-like) configuration blocks and extracting the constituent keywords and parameter values from each matched subtree, thereby supplying those per-layer parsed fields as normalized tokens into Nickolov’s token-map analysis and frequency/count metrics because converting parsed fields into tokens is a routine normalization step in configuration management. The motivation would have been to provide a customizable way for a user to reproducibly configure the network devices in a very efficient and concise way (Rao col. 7, lines 42-45).
Regarding claims 3 and 13, Nickolov discloses
wherein the identifying of the at least one configuration discrepancy (paragraphs [1052]-[1058], [1063]-[1069]: identifying configuration discrepancies that correspond to missing security-related configuration elements, which result in vulnerabilities in the system; Note: Nickolov’s GUI 4430 displays vulnerabilities based on configuration values and other configuration elements reported from the system, including missing or improperly set commands that enable security features) and the determining of the predominant configuration profile (paragraph [0227] Analyze data collected from different subscribers' Tracked Servers, both configuration and event/monitoring data, to determine configurations that are more frequently used (or indicate they are rare/unusual); paragraph [0430]: the plugin may display the DGRI Score for the current configuration, the score for the target configuration, the score change (improvement or degradation), and optionally additional information such as the number of known data points for the new configuration and vulnerability information. These data points may include: the number of systems using the target configuration historically or current; paragraph [0161]: the percentile may be showed both as of the current configuration as well as for the target configuration (e.g., after a set of changes is selected using the GUI from FIG. 33; Note: Nickolov’s teachings collectively show how the system analyzes tracked servers to find the most common (or rare) configurations, reports how many systems use a given target configuration, and provides percentile rankings—together producing data that characterizes the predominant configuration profile across the devices in a selected subset) includes evaluating the at least one value of the tokenized configuration (paragraph [0150]: The Token Map Repository 314 may be configured or designed to include functionality for tokenization of sensitive data (e.g., in collected configurations and signals); paragraph [0744]: “To” configuration which is arrived at by upgrading or downgrading packages in the From list to their corresponding package in the To list).
Nickolov does not disclose wherein the identifying of the at least one configuration discrepancy … includes evaluating the at least one value of the tokenized command. Rao discloses wherein the identifying of the at least one configuration discrepancy … (col. 4, lines 27-32: the controller may perform another series of algorithms to reconcile these policies with the existing policies to determine the policy configuration deviations. The controller may update the policies, and may notify the updated policies to the network devices based on the policy configuration deviations) includes evaluating the at least one value of the tokenized command (col. 7, lines 45-65: CLI templates are a set of re-usable device configuration commands with the ability to parameterize select elements of the configuration as well as add control logic statements. Such (CLI) configuration template may be used by, for example, controller 116, to generate a device deployable configuration by replacing the parameterized elements (variables) with actual values and evaluating the control logic statements. Sub-templates may be regarded as a parts of configuration blocks, each of which matches an aspect of a device running configuration. A controller may generate general configuration statements from a configuration template in order to match the current running configuration of a device. The template generated configuration expressions may then be used as masks to identify matching configuration patterns in the device running configuration. When a portion of a device running configuration matching a specific sub template-generated configuration expression is found, the controller service may extract relevant network-related parameter values and other key information from the relevant portion of the device running configuration). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Nickolov incorporating Rao’s template/sub-template extraction of CLI/configuration blocks, and parsing hierarchical (tree-like) configuration blocks and extracting the constituent keywords and parameter values from each matched subtree, thereby supplying those per-layer parsed fields as normalized tokens into Nickolov’s token-map analysis and frequency/count metrics because converting parsed fields into tokens is a routine normalization step in configuration management. The motivation would have been to provide a customizable way for a user to reproducibly configure the network devices in a very efficient and concise way (Rao col. 7, lines 42-45).
Regarding claims 4 and 14, Nickolov discloses
wherein the determination of the one or more modifications is (paragraph [0429]: DataGrid yum plugin: The DataGrid yum plugin intercepts configuration change operations (e.g., install, upgrade, uninstall, downgrade, as well as ‘history undo’), and after yum determines the full set of changes, including their dependencies, the plugin checks the DGRI Score and other information relevant to the confidence of the proposed configuration changes. It does this by taking the existing configuration of the server (e.g., in the form of a list of installed packages and their specific version information) and performing the changes that yum is about to do upon this list to create a target configuration. The plugin feeds the target configuration using the DataGrid API, and requests the DGRI Score for the target configuration and any additional relevant information. It then displays this information and asks the user whether or not to proceed with executing the configuration change) based on the evaluation of the at least one value of the tokenized configuration (paragraph [0150]: The Token Map Repository 314 may be configured or designed to include functionality for tokenization of sensitive data (e.g., in collected configurations and signals); paragraph [0744]: “To” configuration which is arrived at by upgrading or downgrading packages in the From list to their corresponding package in the To list).
Nickolov does not disclose wherein the determination of the one or more modifications is based on the evaluation of the at least one value of the tokenized command. Rao discloses wherein the determination of the one or more modifications (col. 3, lines 63-col. 4, lines 2: When the OOB changes has occurred in the configuration of a network device, the device configuration is out of synchronization state. To return the device configuration state to synchronization state, the controller may need to resynchronize the device's configuration stored in the controller to match the device configuration) is based on the evaluation of the at least one value of the tokenized command (col. 7, lines 60-65: When a portion of a device running configuration matching a specific sub template-generated configuration expression is found, the controller service may extract relevant network-related parameter values and other key information from the relevant portion of the device running configuration). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Nickolov incorporating Rao’s template/sub-template extraction of CLI/configuration blocks, and parsing hierarchical (tree-like) configuration blocks and extracting the constituent keywords and parameter values from each matched subtree, thereby supplying those per-layer parsed fields as normalized tokens into Nickolov’s token-map analysis and frequency/count metrics because converting parsed fields into tokens is a routine normalization step in configuration management. The motivation would have been to provide a customizable way for a user to reproducibly configure the network devices in a very efficient and concise way (Rao col. 7, lines 42-45).
Regarding claims 5 and 15, Nickolov discloses
wherein the subset of the one or more constituent devices is determined based on at least one of: a location of the one or more constituent devices (paragraph [1007]: the DataGrid System may identify 347 servers which match the user specified hardware resource requirements, and may automatically and/or dynamically group the identified servers into a plurality of different logical groups based on identical or similar hardware resources and other characteristics (e.g., such as location, etc.)), a vendor and model of the one or more constituent devices, a measure of similarity of connections of the one or more constituent devices exceeding a predetermined threshold, and a presence of shared configuration elements.
Regarding claims 6 and 16, Nickolov discloses
further comprising: determining a graphical depiction characterizing the at least one configuration discrepancy (paragraphs [1052]-[1058], [1063]-[1069]: identifying configuration discrepancies that correspond to missing security-related configuration elements, which result in vulnerabilities in the system; Note: Nickolov’s GUI 4430 displays vulnerabilities based on configuration values and other configuration elements reported from the system, including missing or improperly set commands that enable security features); and providing the graphical depiction (paragraph [1007]: the DataGrid System may identify 347 servers which match the user specified hardware resource requirements, and may automatically and/or dynamically group the identified servers into a plurality of different logical groups based on identical or similar hardware resources and other characteristics (e.g., such as location, etc.) to a graphical user interface for display therein (paragraph [0871]: In the specific embodiment of FIG. 29, it is assumed that the user has used the tree-form menu checkboxes to select Florida 2903, 2913 and Ireland 2905, 2915 as the selected geographical scopes of the servers to be managed. In at least one embodiment, the tree view presents multiple different selection criteria, for example: region, application, server role, etc. In some embodiments, the user can also select all servers)
Regarding claims 7 and 17, Nickolov discloses
wherein the fourth data includes prioritization data characterizing a ranking assigned to one or more portions of the revised configuration (paragraph [0241]: Provide a conditional software/configuration update which will be executed (or rejected) based on information provided from DataGrid service (e.g., upgrade package if the new package provides significant improvement of DGRI score, is widely deployed and it has not been found to cause problems in other deployments)), wherein the ranking is based on a rate of occurrence of the at least one configuration discrepancy (paragraph [0713]: The DGRI score is programmatically calculated from a large, and growing, set of historical data crowdsourced from many servers. The determination of a DGRI score may also be affected by other data sources such as publically available package vulnerability data; paragraph [1057] Examine lists of vulnerabilities 4430 affecting the system based on the configuration, including vulnerability details such as CVE ID, severity, description, and list of packages and their specific versions that include the vulnerability, as well as configuration values and other configuration elements reported from the system; paragraph 1058] Examine vulnerability summaries in the block 4431, including total number of vulnerabilities affecting the system, maximum severity level, and maximum severity level that the system will have if all vulnerabilities that have fixes available are fixed (e.g., maximum severity level of the vulnerabilities for which a fix is currently not available); paragraph [1061] Percentile of all servers (among all customers/subscribers or within a group of subscribers that have common characteristics, such as location, hardware architecture, products/packages in use, etc.) where this particular server is, based on reliability, projected MTBF, security, vulnerability, reliability or other characteristics by which servers are compared; the percentile may be showed both as of the current configuration as well as for the target configuration (e.g., after a set of changes is selected using the GUI from FIG. 33), and wherein the revised configuration characterized by the fourth data is based on the prioritization data (paragraph [0241]: Provide a conditional software/configuration update which will be executed (or rejected) based on information provided from DataGrid service (e.g., upgrade package if the new package provides significant improvement of DGRI score, is widely deployed and it has not been found to cause problems in other deployments)).
Regarding claims 8 and 18, Nickolov discloses
wherein the at least one configuration discrepancy characterizes an absence of a security command within one or more of the one or more configuration layers (paragraphs [1052]-[1058], [1063]-[1069]: identifying configuration discrepancies that correspond to missing security-related configuration elements, which result in vulnerabilities in the system; Nickolov’s GUI 4430 displays vulnerabilities based on configuration values and other configuration elements reported from the system, including missing or improperly set commands that enable security features).
Nickolov does not disclose one or more of the one or more configuration layers. Rao discloses one or more of the one or more configuration layers (col. 8, lines 26-28: A common mechanism for modeling the configuration states of network devices at the controller is a tree-like configuration structure). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Nickolov incorporating Rao’s template/sub-template extraction of CLI/configuration blocks, and parsing hierarchical (tree-like) configuration blocks and extracting the constituent keywords and parameter values from each matched subtree, thereby supplying those per-layer parsed fields as normalized tokens into Nickolov’s token-map analysis and frequency/count metrics because converting parsed fields into tokens is a routine normalization step in configuration management. The motivation would have been to provide a customizable way for a user to reproducibly configure the network devices in a very efficient and concise way (Rao col. 7, lines 42-45).
Regarding claims 9 and 19, Nickolov discloses
further comprising: determining, using the at least one processor, a graphical user interface that characterizes the determined one or more modifications and one or more of the one or more configuration … , and providing, using the at least one processor, the graphical user interface to a display for depiction thereon (Fig. 33, paragraph [0744]: “To” configuration which is arrived at by upgrading or downgrading packages in the From list to their corresponding package in the To list)).
Nickolov does not disclose determined one or more modifications and one or more of the one or more configuration layers. Rao discloses determined one or more modifications (col. 3, lines 63-col. 4, lines 2: When the OOB changes has occurred in the configuration of a network device, the device configuration is out of synchronization state. To return the device configuration state to synchronization state, the controller may need to resynchronize the device's configuration stored in the controller to match the device configuration) and one or more of the one or more configuration layers (col. 8, lines 26-28: A common mechanism for modeling the configuration states of network devices at the controller is a tree-like configuration structure). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Nickolov incorporating Rao’s template/sub-template extraction of CLI/configuration blocks, and parsing hierarchical (tree-like) configuration blocks and extracting the constituent keywords and parameter values from each matched subtree, thereby supplying those per-layer parsed fields as normalized tokens into Nickolov’s token-map analysis and frequency/count metrics because converting parsed fields into tokens is a routine normalization step in configuration management. The motivation would have been to provide a customizable way for a user to reproducibly configure the network devices in a very efficient and concise way (Rao col. 7, lines 42-45).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Nickolov et al. (US 2017/0034023, hereinafter Nickolov) in view of Rao et al. (US 11,956,123, hereinafter Rao) as applied to claim 1, and further in view of Imms (US 2024/0069940, hereinafter Imms).
Regarding claim 10, Nickolov discloses
further comprising: determining, based on the determined one or more modifications, … program that is configured to provide a graphical prompt (paragraph [0429]: DataGrid yum plugin: The DataGrid yum plugin intercepts configuration change operations (e.g., install, upgrade, uninstall, downgrade, as well as ‘history undo’), and after yum determines the full set of changes, including their dependencies, the plugin checks the DGRI Score and other information relevant to the confidence of the proposed configuration changes. It does this by taking the existing configuration of the server (e.g., in the form of a list of installed packages and their specific version information) and performing the changes that yum is about to do upon this list to create a target configuration. The plugin feeds the target configuration using the DataGrid API, and requests the DGRI Score for the target configuration and any additional relevant information. It then displays this information and asks the user whether or not to proceed with executing the configuration change).
Nickolov in view of Rao does not disclose further comprising: determining … an auto-completion program that is configured to provide a graphical prompt characterizing a second, following portion of the one or more commands in response to the user inputting a first, preceding portion of the one or more commands. However, Nickolov teaches an interactive GUI/plugin workflow that generates a target configuration for proposed changes, retrieves scoring/metadata (e.g., DGRI) for the target, and displays that information to the user for approval (Nickolov paragraph [0429]).
Imms discloses further comprising: determining … an auto-completion program (abstract, paragraphs [0015]-[0017]: a custom shell script with an autocompletion engine that consults a CLI command repository containing the most current and historical versions of the CLI command structure) that is configured to provide a graphical prompt characterizing a second, following portion of the one or more commands in response to the user inputting a first, preceding portion of the one or more commands (paragraph [0049]: When the terminal emulator detects a trigger character, the terminal emulator knows that the user needs assistance in completing a CLI command; paragraph [0050]: When the terminal emulator detects the trigger character in the CLI input, the terminal emulator generates the autocompletion request sequence; paragraph [0051]: The terminal emulator transmits the autocompletion request sequence to the shell through the established secure direct bidirectional communication path; Notes: Together, passages teache an autocompletion mechanism in which a terminal emulator detects a partially-formed CLI command, transmits an autocompletion request to a shell-integrated custom shell script and autocompletion engine that consults a CLI command repository (current and historical CLI structure), and returns autocompletion candidates that the terminal emulator displays using the native UI). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Imms’ shell-side autocompletion into Nickolov (in view of Rao)’s plugin/UI flow so that, when presenting or editing proposed configuration changes, the system can provide interactive graphical completion prompts in response to partially-entered commands. The motivation would have been to provide improved functioning of the computer since updates to the CLI command structure are made to the shell without impacting the user device (Imms paragraph [0057]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SISLEY N. KIM whose telephone number is (571)270-7832. The examiner can normally be reached M-F 11:30AM -7: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, April Y. Blair can be reached on (571)270-1014. 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.
/SISLEY N KIM/Primary Examiner, Art Unit 2196 12/30/2025