DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Allowable Subject Matter
Claims 1-7, 9-17 and 19-20 represent allowable subject matter (i.e., are allowable over the prior art). However, the claims remain rejected under 35 USC §101.
Response to Arguments
The previous objection to the drawings and rejections of the claims under 35 USC §§101, 102 and 103 have been withdrawn, in light of the amendments. However, the rejection of the claims under 35 USC §101 has been modified in order to address the newly amended claim language.
Applicant's arguments, filed 11/5/2025, concerning the previous rejection of the claims under 35 USC §101 have been fully considered but they are not persuasive.
Regarding the previous rejection of the claims under 35 USC §101, Applicants argue on page 8 in the Remarks section that the rejection under 35 USC 101 does not satisfy Step 2A Prong One because the step of generating a knowledge corpus requires computer operations that extract, model and link command templates using hierarchical and graph data structures.
The Office respectfully disagrees. First, it is noted that Applicants are asserting language that is not being claimed. Additionally, the language being asserted abstracting/modelling/linking are all abstract terms. And, the mere use of hierarchical/graph structures reflects the use of an abstraction (abstract representation of data), and can be performed using paper and pencil.
Additionally, Applicants argue on page 9 in the Remarks section that the rejection under 35 USC 101 does not satisfy Step 2A Prong Two because the claim language enables generation of management interfaces with direct interaction, improving manageability and reducing dependency on hardware access.
The Office respectfully disagrees. First, it is noted that Applicants’ remarks seem to be an admission of Abstractness, as the asserted claim language “requires” no device interaction (just mental interaction?). Additionally, the language being asserted abstracting/modelling/linking are all “abstract” terms. There are no recited implementation details reflecting how the asserted “abstract” concepts of abstracting/modelling/linking are to be accomplished. And, the language being asserted is not recited in the claims.
Additionally, Applicants argue on pages 9-10 in the Remarks section that the rejection under 35 USC 101 does not satisfy Step 2B because the claim language is directed to a technique for creating a machine-readable corpus derived from static documentation, programmatically organizing command structures and relationships for automated management.
The Office respectfully disagrees. First, it is noted that Applicants’ remarks seem to be an admission of Abstractness, as the asserted claim language “requires” no device interaction (just mental interaction?). Additionally, the language being asserted abstracting/modelling/linking are all “abstract” terms. There are no recited implementation details reflecting how the asserted “abstract” concepts of abstracting/modelling/linking are to be accomplished. I.e., there is no “particular solution” being expressly claimed. And, the language being asserted is not recited in the claims.
The other independent claims (11 and 20) are substantially similar to claim 1, and therefore likewise rejected. Claims 2-7 and 9-10 depend upon parent claim 1, claims 12-17 and 19 depend upon parent claim 11, and do not correct the issues with respect to 35 USC 101 raised in claim 1. These dependent claims are also likewise rejected.
Therefore, it is maintained that the rejections of the claims under 35 USC 101 are valid and reasonable.
Claim Rejections – 35 U.S.C. § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-7, 9-17 and 19-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter.
These claims are rejected under 35 USC §101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites at a very high level, receiving and changing data format including providing an abstract or visual representation of that data, that data having a particular intended use. Thus, the claims encompass the performance of the limitations in the mind, or alternatively the solving of a math problem (i.e., a series of mathematical steps) that are not tied to a practical application.
Regarding independent claim 1:
Statutory Category: Yes, recites a series of steps executed (therefore a process ).
Step 2A, Prong 1 (Judicial Exception Recited?): Yes. The claim recites a series of steps, not explicitly/positively embodied in generic hardware processing elements, including obtaining / acquiring data and generating / forming another named grouping of that data in which the data has an intended use. The data may be associated with devices, but it’s still merely data (text, numerical?). These concepts, under a broadest reasonable interpretation, encompass the performance of the limitations in the mind, or alternatively the solving of a math problem (e.g., possibly restructuring data). This limitation can be performed in the mind or simply with the aid of pencil and paper. Alternatively, use of a mathematical concept integrated into a practical application may represent patent eligible subject matter, but the mere solving of a math problem is considered an abstract idea. A claim to “collecting information, analyzing it, and displaying certain results of the collection and analysis,” where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016).
It is further noted that (for at least the claim set related to claim 1) no generic hardware is also claimed.
For example, the claim limitations directed to “obtaining a static dataset …” and “generating a knowledge corpus based on the static dataset …” encompasses acquiring data and reformatting it (or merely renaming it). If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic components, then it falls within the “Mental Processes” grouping of abstract ideas.
Alternatively, other than reciting additional generic elements (such as processors and storage in analogous / substantially similar claims), nothing in the claim precludes its characterization as a mathematical concept. For example, the claim also encompasses the performance of mathematical operations/steps based upon mathematical relationships to transform data data/values. These limitations are therefore reasonably characterized as encompassing mathematical concepts (i.e., an abstract idea).
Accordingly, the claim recites an abstract idea. I.e., these limitations encompass mental processes, or in the alternative a mathematical concept (an abstract idea).
Step 2A, Prong 2 (Integrated into a Practical Application?): No. The claim recites a series of steps, including obtaining/receiving data that may not have been viewed (via generic hardware),and reformatting or grouping that data. Under a broadest reasonable interpretation, nothing in the claim precludes characterization as a mental concept or alternatively a mathematical concept.
Furthermore, the limitation of obtaining data (i.e., “obtaining a static dataset …”) is identified as insignificant extra-solution activity, and this element is well-understood, routine, and conventional as evidenced by the court cases set forth in MPEP 2106.05(d)(II). E.g., “i. Receiving or transmitting data over a network, e.g., using the Internet to gather data (Symantec, 838 F. 3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); … OIP Techs, Inc. v. Amazon.com, In., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); ), and thus remains insignificant extra-solution activity that does not provide significantly more. And, the limitation directed to describing a particular data format/use [i.e., the formatting use of knowledge corpus / template line / view] is merely linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h) – and, therefore remains insignificant extra-solution activity and does not provide significantly more.
(Note, regarding analogous / substantially similar independent claims: The computing elements are recited at a high-level of generality such that the claim amounts to no more than mere instructions to apply the exception using generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose meaningful limits on practicing the abstract idea.) Therefore, the claim is directed to an abstract idea.
Step 2B (Inventive Concept Provided?): No. As discussed with respect to Step 2A, the elements (i.e., steps of obtaining and generating) in the claim amount to no more than mere instructions to apply the exception. Mere instructions to apply an exception (even using generic computer components [e.g., a processor and memory]) cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Therefore, the claim is not patent eligible, and is reasonably rejected under 35 USC §101.
Independent claims 11 and 20 are each substantially similar to claim 1. Therefore, these claims are likewise rejected.
Claims 2-7 and 10, and 12-17 and 19 depend upon claims 1 [2-7 and 9-10] and 11 [12-17 and 19], respectively, and do not correct the issues set forth above. These claims merely further recite generic hardware/storage (in the case of analogous / substantially similar claims), further manipulate the data items (e.g., as graph/tree elements, by identifying data element components/fields, or via displaying/visualizing), or further classify/categorize the data items. Therefore, these claims are likewise rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Relevance is provided in at least the Abstract of each cited document.
Non-Patent Literature
Deca, Rudy, et al., “Configuration Model for Network Management”, In: Gaiti et al (eds.), Network Control and Engineering for QoS, Security and Mobility, III, NetCon 2004, IFIP International Federation for Information Processing, vol 165. Springer, Boston, MA, conference held Nov. 2-5, 2004, pp. 3-14.
To enforce the configuration consistence and integrity, it is necessary to enhance the validation capabilities of the management tools. The Meta-CLI Model presented in this paper captures the dependences among the configuration components and the network service properties and translates them into validation rules. It also translates the device configuration information into tree-like models and checks their integrity and consistence using these[s] rules. (page 3, Abstract). In a configuration, there is a hierarchy of elements from simple to complex, namely from the parameters, going through several levels of aggregation, up to the network services. This grouping expresses the common goal and of the components and the dependences that exist among them. (page 5, subsection “D. Parameter Hierarchy and Service Composition”, of section “1.1 Configuration Dependencies”). Due to their complexity, the dependences can exist at different levels within network services, from parameters to sub-services. 1. Parameter and command dependences As already shown, the parameters and commands that compose the services can have their intrinsic, lower-level, dependences, which can be either independent or dependent on the device environment (software and hardware). EXAMPLE The dependence C.1 is generic, whereas D.2 is command implementation-specific. (page 6, section “1.2 Dependenc[i]es among network service components”).
Chen, Huangxsun, et al., “Software-Defined Network Assimilation: Bridging the Last Mile Towards Centralized Network Configuration Management with NAssim”, SIGCOM ‘22, Amsterdam, The Netherlands, August 22-26, 2022, pp. 281-297.
We design a semantics-enhanced tree structure to represent the native device model. Nodes of tree are CLI command templates with placeholder parameters, e.g., node 'peer group '. Edges of tree represent configuration hierarchy, e.g., edge from node 'bgp ' to node 'peer group ' denotes the latter CLI command works under the sub-view enabled by the former. Each node are linked to its relevant semantic corpus extracted from user manual, e.g., node 'peer group 'is associated with corpus shown in Figure 3. The entire tree describes the configuration model of the device, including the CLI command set supported, the command hierarchy and the semantics of commands. (page 285, section “VDM Data Structure”). CLI model hierarchy refers to the relationship between individual CLI commands, i.e., each command has a viable working view, i.e., parent view enabled by its parent CLI command. Configuration models of most vendors follows tree-based hierarchy, but the tree is usually implicit in manuals—only Nokia’s manuals specify their hierarchy along with individual CLIs syntax/semantic description. Some devices have special CLI commands to display their model hierarchy on the terminal, but only command syntax is shown without explicit linking to their semantic descriptions. We find a reliable way to derive model hierarchy accompanied with semantic context by fully exploiting 'Examples' fields in VDM corpus. Revisiting the structure of corpus shown in Figure 3, most fields centred around the 'CLIs' field to provide detailed semantic description. However, the 'Examples' field demonstrates an instantiated version of current 'CLIs' field in a configuration snippet, implicitly bridging the relationship between the current CLI and its parent CLI in the instantiated cases. Therefore, the basic idea of our hierarchy derivation scheme is as follows: take Figure 3 as the example, for a corpus, we first identify the corresponding CLI instance in 'Examples' fields, i.e., peer 10.1.1.1 group test. Then we track back to find the parent CLI instance based on the prefix indentation, i.e., bgp 100. Finally, we search within all corpus to find a 'CLIs' field matching with CLI instance bgp 100, i.e., bgp in this case. Combined with 'BGP view' indicated in 'ParentView' field, it follows that the CLI command bgp enters the 'BGP view'. Other 'CLIs' with the same parent view can directly reuse the previous derivation, or they can derive based on their own 'Examples' fields for majority voting. (page 287, 1st two paragraphs of section “5.2 Model Hiercharchy Derivation and Validation”).
US Patent Application Publications
Ghosh 2023/0161561
An architectural diagram recommendation engine is implemented in a data processing system for software architectural diagram analysis and recommendation. The architectural diagram recommendation engine analyzes a software requirements specification document using natural language processing to identify functional requirements and security requirements. The architectural diagram recommendation engine analyzes a digital software architectural diagram image to identify functional components and identifies one or more discrepancies between the functional components of the digital software architectural diagram image and the functional requirements or security requirements. The architectural diagram recommendation engine generates an alert concerning the one or more discrepancies and presents the alert in association with the digital software architectural diagram image. (Abstract). Smart architectural diagram recommendation engine 350 recommends placement of different components, networks, actors, third party integrations, services, and blocks (user profiles, services, firewalls, connections, configurations, etc.) and their corresponding limits during the creation of digital architectural diagram images. Smart architectural diagram recommendation engine 350 performs textual requirement analysis. From a historical knowledge corpus, smart architectural diagram recommendation engine 350 invention identifies which architectural blocks and components are to be used. Smart architectural diagram recommendation engine 350 also uses architectural templates 360 and selects an appropriate template. For example, if the number of users is 100 versus 1000, then a different template may be selected. (para 0057).
Cai 2021/0035022
Some embodiments of the present disclosure relate to Internet technologies and disclose a method for updating a service system, an electronic device, and a readable storage medium. In some embodiments of the present disclosure, the method for updating the service system comprises: acquiring training language materials generated by the service system in a service process, and storing the training language materials in a corpus; updating the service system after it is determined data in the corpus meets a first preset requirement; where the first preset requirement is that the data in the corpus is greater than a first threshold, or the data in the corpus grows faster than a second threshold. (Abstract). Specifically, when the similarity coefficient of the template matching module 31 fails to meet the requirement, the non-business component activates an online knowledge question and answer component, and retrieves a cloud knowledge corpus 34 through the online retrieval module 32. Accuracy of a template matched by the template matching module 31 depends to a great extent on reasons such as relevance between an implicit meaning and depth (relevance of context) of the non-service request data, and the like. If the coefficient of the overall similarity between the sample of the template matching module 31 in the matching and the corresponding template fails to meet the requirement, it also indicates that the non-business request data has a more profound grammatical structure and knowledge background (that is similar to an encyclopedia question and answer reply) (para 0104).
US Patents
A 11,296,954
This disclosure describes techniques by which controller device 10 can support SLA in near real time. For example, controller device 10 may support concurrent intent provisioning. Controller device 10 may use enhanced resource matching filters to include and exclude certain system resources. Controller device 10 may further maintain the network in a consistent state while managing business SLA. Controller device 10 may also support concurrent stateless intent provisioning. That is, controller device 10 may support concurrent intent updates without invalidating other intent changes. Controller device 10 may also support a current version of an intent graph until pending changes have been deployed. U.S. application Ser. No. 16/125,245, entitled “DYNAMIC INTENT ASSURANCE AND PROGRAMMABILITY IN COMPUTER NETWORKS,” filed Sep. 7, 2018, and incorporated herein by reference in its entirety, describes resource filter query semantics as below: TABLE-US-00001 site(name: ″Bangalore″ ) { @Resource(“PE”) device(role: ″PE″, bgp-session-count<1000) ) { //”@Resource” signify it is a resource with name PE . id, @Resource(“PE-Port”) interface ( min:latency ) { //”@Resource” signify it is a resource with name PE-PORT name } } } From this, controller device 10 may derive decision variables, objective, and constraints. Controller device 10 may enhance the query to support extended resources and included resources, e.g., as shown below: TABLE-US-00002 site(name: ″Bangalore″ ) { @Resource(“PE”) device(role: ″PE″, bgp-session-count<1000, excluded: {d1, d2}, included: {d3}) ) { //”@Resource” signify it is a resource with name PE . id, @Resource(“PE-Port”) interface ( min:latency ) { //”@Resource” signify it is a resource with name PE-PORT name } } } The excluded list may become a constraint to the resource selection optimization algorithm, while the included list may also become a constraint to the resource selection optimization algorithm. In the example above, the constraints include limits on resources defined as “not in {d1, d2}” and “in {d3}.” (col. 8 line 13 – col. 9 line 6).
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 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 date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT STEVENS whose telephone number is (571)272-4102. The examiner can normally be reached Mon - Fri 6:00 - 2:30.
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, Amy Ng can be reached on (571) 270-1698. 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.
/ROBERT STEVENS/Primary Examiner, Art Unit 2164
January 30, 2026