DETAILED ACTION
This action is responsive to the Applicant’s response filed 8/13/26.
As indicated in Applicant’s response, claims 1, 10-11, 16, 18 have been amended and claims 5-6, 12 cancelled. Claims 1-4, 7-11, 13-20 remain and are pending an office action.
Claim Rejections - 35 USC § 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.
Claim 11 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 11 is/are directed to Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of 2-step analysis as following.
Step I
Claim 11 is directed to a method/process category
Step 2A
Prong one:
The claim recites steps of "identifying" (inter-component relationships), "parsing"
(composition files metadata, values of variables), "determining" (component is logically related),
"generating" (solution composition recommendations) and these are construed as steps descriptive of
a user being presented via a computer interface, expression of a component or component
relationships, metadata whereby the user can derive - mentally parsing, finding a solution - further metadata or variables or relationship among them, which are typical processes that can be performed in a human mind – or via use of pen/paper – in terms of data being generated, re-organized as result of the mental processes in the mind of the human, which amount to what the circuits courts defined as Mental Process subgroup of a Abstract Idea type Judicial Exception. MPEP 2106.04(a). Further, the identification and linking logic relies entirely on evaluating relational equivalencies between data sets (matching output variable values to input variable values), which represents basic logical manipulation of abstract information (see Electric Power Group, LLC v. Alstom SA, 830 F.3d 1350 (Fed. Cir. 2016)). See MPEP 2106.04(a)(A) for Mathematical concepts/generic data manipulation.
Prong two:
The elements recited as “solution composition files”, “metadata”, “output/input variables”, (generate) “a final solution that is executable” include generic computer components (metadata, composition files, variables) such as data structures associated with performing standard computer operations, and merely executing abstract data-matching logic on generic SW artifacts cannot transform the judicial exception into a eligible practical application. MPEP 2106.04(d)(2). The limitation “generate … final solution that is executable” represents generic post-solution activity – MPEP 2106(4)(d)(2) that broadly claims a desirable result without reciting specific technical details for a operation expressed via Hardware or non-conventional protocols.
The feature recited as “connecting … the component and the second component” as result of “determining … second component is logically related to the component” based on “linked variable value” amounts to post-activity that can be subsumed into consequence of the mental process of determining, when no particular hardware or machine setting is described with the “connecting” act, especially when the “by modifying” feature merely sets variable or component input from within a file (“composition file”) which amount to generic structure interacting with standard computer operations; i.e. well-understood feature in a field of SW engineering and dependency linking – MPEP 2106.05(d), 2106.05(g)
Merely applying or connecting a determined/calculated result using generic computer components amount to merely apply an Exception, not integrating it into a practical application. MPEP 2106.05(f)
The elements recited as "receiving" (a component), "populating" (a solution comprising a component), and "component with a linked variable" are extra-solution activities or mere descriptive characterization of component comprised with the receiving/populating step and therefore cannot be viewed as elements that improve upon the technical field of analyzing data and expressing recommendation based on its analysis
As shown from the above, the additionally recited features do not demonstrate that the recited steps improve the operational functioning of a computer itself (e.g., reducing physical RAM consumption, accelerating hardware execution clock cycles, or resolving a hardware-level network bottleneck). Rather, the claim merely improves an abstract process of software file composition or wiring (see SAP America, Inc. v. Versata Development Group, Inc., 862 F.3d 1381 (Fed. Cir. 2017)).
As a whole, the claim does not integrate the abstract Idea into a practical application.
Step 2B
Additional elements include “command line tool” and this understood as a tool or means to acquire data cannot be viewed as implementation details that supports a novel improvement of a computer field about acquiring data and deriving relationship based on its analytical processing. the “receiving”, “populating” steps can be viewed as well-known activities – e.g. extra-solution or pre-activity features - that bear no novelty to the “determining”, “identifying”, “parsing” acts identified in the Judicial Exception (see MPEP § 2106.05(d))
As no particular hardware or machine setting is described with the “connecting” or “modifying” acts – e.g. “by modifying” feature merely understood as setting a variable or component input from within a file (“composition file”), the additional feature of “connecting” (by setting output/input of a file components) amount to post-activity – MPEP 2106.05(g) - and/or generic structure interacting with standard computer operations; i.e. well-understood feature in a field of SW engineering and dependency linking – MPEP 2106.05(d)
Individually considered, parsing files, matching variable names, modifying text/code references, and compiling/generating executable files are well-understood, routine, and conventional activities in the field of software engineering and dynamic dependency linking (MPEP § 2106.05(d)).
Considered as an ordered combination, the steps simply follow the standard, logical sequence of traditional automated dependency management: read input file → determine relationships → modify references → output build file. Stacking well-understood and conventional computer operations in their normal operating sequence does not yield "significantly more" than the sum of their standard parts. MPEP 2106.05(e)
In all, the additional elements as mentioned above fail to add significantly more to the abstract Idea or fail to amount to demonstrate a inventive concept under step 2B; claim 11 is therefore non-statutory under 35 USC § 101.
Claims 1 and 16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 1 and 16 is/are directed to Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of 2-step analysis as following.
Eligibility of claim 1
Step I: claim 1 is directed to a machine/product category
Step 2A
Prong one:
Claim 1 recites steps of "identify" (inter-component relationships), "parse" (composition files
metadata, values of variables), "determine" (component is logically related), "generate" (solution
composition recommendations) and these are construed as steps descriptive of activities that can be
performed in a human mind (identifying, parsing, determining) or via use of pen/paper (for
presenting/recommending a solution). The steps of identifying, parsing, determining and generating (recommendation) from above, amount to what the circuits courts defined as Mental Process subgroup of an Abstract Idea type Judicial Exception. MPEP 2106.04(a)
Prong two:
The elements recited as "receive" (instance of a component, via an interface), "populate" (via
the interface, a module the supports the component) can be viewed as extra-solution pre-activity steps
that acquire and preprocess the received data into a form destined for use by the mental processes
identified in Prong One. Thus, the extra-solution activities of receiving and populating cannot be
seen as transforming the Abstract Idea (of prong One) into a non-conventional technical improvement
over the field of analyzing data via use of a computer tool, interface. The above extra-solution
activities are also viewed as well-understood routines of acquiring data for an Abstract Idea, thus
cannot translate the Abstract Idea of prong One into a Practical Application. MPEP 2106.05 (a) (c)
The element recited as “connecting … the component and the second component” as result of “determining … second component is logically related to the component” based on “linked variable value” amounts to activity that depends on the “determining” step (component is logically related) that can be subsumed into the mental process of determining or post-activity thereof – MPEP 2106.05 (g) - as no particular hardware or machine setting is described with the “connecting” act, especially when the “by modifying” feature merely sets variable or component input from within a file (“composition file”) which amount to generic structure interacting with standard computer operations; i.e. well-understood feature in a field of SW engineering and dependency linking – MPEP 2106.05(d). Merely applying or connecting a determined/calculated result using generic computer components amount to merely apply an Exception, not integrating it into a practical application. MPEP 2106.05(f)
Step 2B
Additional elements include “command line tool” and this understood as a tool or means to acquire data cannot be viewed as implementation details that supports a novel improvement of a computer field about acquiring data and deriving relationship based on its analytical processing. the “receiving”, “populating” steps can be viewed as well-known activities – e.g. extra-solution or pre-activity features - that bear no novelty to the “determining”, “identifying”, “parsing” acts identified in the Judicial Exception (see MPEP § 2106.05(d))
As no particular hardware or machine setting is described with the “connecting” or “modifying” act, the “by modifying” feature (input variable of second component set to output variable of component) is merely understood as setting a variable or component input from within a computer readable structure (e.g. “composition file”) in response to a “determining” step; that is, the “connecting” feature (by setting output/input of a file components) as an “additional element” amounts to a post-activity – MPEP 2106.05(g) – in form of generic structure interaction with standard computer operations, which constitutes no more than well-understood, conventional routines in a field of SW engineering and dependency linking – MPEP 2106.05(d)
Individually considered, parsing files, matching variable names, modifying text/code references, and compiling/generating executable files are well-understood, routine, and conventional activities in the field of software engineering and dynamic dependency linking (MPEP § 2106.05(d)).
Considered as an ordered combination, the steps simply follow the standard, logical sequence of traditional automated dependency management: read input file → determine relationships → modify references → output build file. Stacking well-understood and conventional computer operations in their normal operating sequence does not yield "significantly more" than the sum of their standard parts. MPEP 2106.05(e)
In all, claim 1 is not eligible under 35 USC § 101 statute.
Eligibility of claim 16:
Step I: claim 16 is directed to a computer medium/product category
Step 2A
Prong one:
Claim 16 recites steps of "identify" (inter-component relationships), "parsing" (composition files metadata, values of variables), "determining" (component is logically related), "generate" (solution composition recommendations) and these are construed as steps descriptive of activities that can be performed in a human mind (identifying, parsing, determining) or via use of pen/paper (for
presenting/recommending a solution); and as set forth above for eligibility of claim 1, these steps
amount to what the circuits courts defined as Mental Process subgroup of an Abstract Idea type
Judicial Exception. MPEP 2106.04(a)
Prong two:
The elements recited as "receive" (instance of a component, via an interface), "populate" (via the interface, a module the supports the component) can be viewed as extra-solution pre-activity steps
that acquire and preprocess the received data into a form destined for use by the mental processes
identified in Prong One. Thus, the extra-solution activities of receiving and populating cannot be
seen as transforming the Abstract Idea of prong One into a non-conventional technical improvement
over the field of analyzing data via use of a computer tool, interface. The above extra-solution
activities are also viewed as well-understood routines - MPEP 2106.05(d) - of acquiring data for an
Abstract Idea, thus cannot translate the Abstract Idea of prong One into a Practical Application.
MPEP 2106.05 (a) (c) (g)
The feature recited as “connecting” or “modifying” act – e.g. “by modifying” - associated with “connect the component and the second component” in terms of setting of input/output between components identified within a structure, is merely understood as conventional activity between a computer structure and components of a computer field; further this additional element of “connecting” (by setting output/input of parsed components) amounts to a post-activity – MPEP 2106.05(g) – to the “determining” step and includes generic structure interacting with standard computer operations; i.e. well-understood feature in a field of SW engineering and dependency linking – MPEP 2106.05(d)
Merely applying or connecting a determined/calculated result using generic computer components amounts to merely apply an Exception, which cannot integrate the abstract Idea into a practical application. MPEP 2106.05(f)
Step 2B
Additional elements include “command line tool” and this understood as a tool or means to acquire data cannot be viewed as implementation details that supports a novel improvement of a computer field about acquiring data and deriving relationship based on its analytical processing. the “receiving”, “populating” steps can be viewed as well-known activities – e.g. extra-solution or pre-activity features - that bear no novelty to the “determining”, “identifying”, “parsing” acts identified in the Judicial Exception (see MPEP § 2106.05(d))
As no particular hardware or machine setting is described with the “connecting” or “modifying” act, the “by modifying” feature (connect the component and the second component by modifying…) is merely understood as setting a variable or component input from information derived within a file (“composition file”) in response to a “determining” step; that is, this additional feature of “connecting” (by setting output/input of a file components) amounts to a post-activity of no significance – MPEP 2106.05(g) - and/or generic structure interacting with standard computer operations; i.e. well-understood feature in a field of SW engineering and dependency linking – MPEP 2106.05(d)
Individually considered, parsing files, matching variable names, modifying text/code references, and compiling/generating executable files are well-understood, routine, and conventional activities in the field of software engineering and dynamic dependency linking (MPEP § 2106.05(d)).
Considered as an ordered combination, the steps simply follow the standard, logical sequence of traditional automated dependency management: read input file → determine relationships → modify references → output build file. Stacking well-understood and conventional computer operations in their normal operating sequence does not yield "significantly more" than the sum of their standard parts. MPEP 2106.05(e)
In all, claim 16 is not eligible under 35 USC § 101 statute
Step 2B analysis of dependent claims.
Claim 7 or 13 recites action of "parse" definitions of a component or command by processors,
which constitutes a pre-activity to the "identifying" or "generating" step of claim 1 or 11, which is
insufficient to make claim 1 or 11 to amount to much more than a Judicial Exception.
Claim 8 or 14 recites processor to "generate" a graph with nodes and edges, and as such,
when viewed as a mere post-activity step, fails to upconvert the "identifying", "parsing",
"determining" or "generating" step of claim 1 or 11 to make the Abstract Idea much more than a
itself.
Claim 2 or 17, recites composition files in terms of it being a resource, a provider,
input/output variables or relationship type data. Static description of a component fails to transform
the "identifying" "parsing" "determining or "generating" step of the base claim into a Practical
Application or to upconvert the Abstract Idea into significantly much more than itself.
Claim 3 or 19 recites receiving an user command identifying a global variable or user-defined
value therefor, and this pre-activity step amounts to insignificant addition to the step of
"identifying", "parsing", "determining", "generating" by the mental process deficiency in the base
claim.
Claim 15 recites receiving an user command to remove connection between components thereby, modifying a solution based on the reception from a command line interface; the acts of receiving and modifying a connection are construed as an extra-solution and use of generic computer to follow up the Abstract Idea (identifying, parsing, determining) in form of post-activities, and as such, cannot be seen as a transformation of significance made to the Abstract Idea construed as “determining” from step 2A ( relationship between components parsed from a composition file).
Claim 4 or 20 recites receiving user command identifying a non-global variable or user-
defined value thereof, and this pre-activity step amounts to insignificant addition to the step of
"identifying" by the mental process deficiency in the base claim.
Claim 5 recites description of input and output variables and this cannot render the Judicial
Exception of the base claim such that it would amount to much more than it already does
Claim 10 or 18 recites tool/medium of claim 1 or 16 to "parse" (files), "identify" (second
component) and "recommend" (connectivity between component); and as such, the parsing is
construed as pre-activity, whereas the identifying and recommending steps, when evaluated within
the whole claim elements, are construed as activities that can be achieved and retained inside one
human mind. Claim 10 or 18 per the context of the respective claim fails to integrate claim 1 or 16
into a Practical Application.
In all, claims 1-4, 7-8, 10-11, 13-20 are rejected under the 35 USC § 101 statute.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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, 8, 11, 14, 16 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Hammond et al, CN 109564505 (translation) 03-25-2022, 32 pgs (herein Hammond) in view of Vion-Dury et al, USPubN: 2010/0275117 (herein VionDury), Pyo Sung Min et al, KR 20230097976A, (translation) 7-03-2023, 19 pgs (herein Pyo_SM) and Browne USPubN: 2018/0293517 (herein Browne).
As per claim 1, Hammond discloses a command line interface tool for generating a solution
comprising one or more components, the command line interface tool (e.g. AI system include at least
a command line interface, client-side command line, server-side command line - pg. 17) comprising one or more processors configured to:
receive an instance of a component (basic network of the intelligent processing node, abbreviation "BRAIN" - pg. 13; command line configured to request information through a prompt new BRAIN - pg. 17; CLI include initiating and naming BRAIN - pg. 17 – Note0: a component provided from the user as representing an instance of a network abbreviated as "BRAIN" reads on instance of a component entered by a user into an interactive tool);
populate the solution (e.g. loader 521 configured to load training data database - pg. 14; learner module can access the previous problem previously constructed AI model storage collection of the solution statistic database - bottom pg. 6, top pg. 7) with at least one module (predictor module,
AI generator module, configurator module - pg. 7; one or more AI engine module - pg. 5) that supports the instance (basis network of the intelligent processing node, BRAIN -
pg. 13) of the component;
identify inter-component relationships (What AI engine to know? programming capture concept and the mutual relationship and forming a directed graph of concept - pg. 9; steering mental model in the InklingTM is also the AI model models the problem domain by coding the basic concept and the mutual relationship - pg. 8; teaching programming language Inkling code - pg. 6) comprising the instance of the component (artificial intelligence network abbreviation is "BRAIN" - pg. 13),
wherein identifying the inter-component relationships (InklingTM - pg. 6; teaching programming language can be compiled into definition field of the structured data object and instantiated to its own sub-concept node - top pg. 17; use the teaching programming language to define a mental model define one or more concept nodes using a teaching programming language - pg. 23; use of the teaching programming language defining one or more connection concept nodes in the mental model author can define the input and output of the mental model - pg. 23) comprises:
determining whether the second component is logically related to the component, the
second component being logically related (see pg. 24 per Note2 from below) when the component and the second component have at least one linked variable value comprising an output variable value of the component being used as an input variable value of the second component (e.g. use of the teaching programming language defining one or more connection concept nodes in the mental model and subsequent output acceptance concept node to define each concept node author can define the input and output of the mental model - pg. 23 - Note2: use of teaching programming language from a designer/author to package relationships among nodes or concept nodes of a mental Al model for configuring a Al model training according to which, each of the one or more blocks thereof is configured to receive input from any one or more of the one or more concept nodes of the mental mode and provide output to one or more concept node of the one or more flow nodes - see pg. 24 - reads on component inter-relationship determination/identification regarding whether a second component is logically related to a first component, the logical linkage thereof identifiable in terms of variable value comprising an output variable value of the first component being used as an input variable value of the second component; and so, based on input-output relationship among nodes or flow nodes of the mental model as defined/authored via effect of the teaching programming language); and
generate solution composition recommendations (e.g. mental model comprises one or more concept nodes, architect module propose a neural network layout from the assembly code - pg. 3; propose neural network layout for building and training determined by the features of the code - pg. 7) based on the identified inter-component relationships (e.g. one or more courses for respectively AI models on one or more of the concept nodes - pg. 3; capture concept and the mutual relationship - pg. 9; learner module can parse archived database of trained model, known past similar problem and proposed solution and other sources to suggest an optimal neural network topology - pg. 16).
Hammond does not explicitly disclose wherein identifying the inter-component relationships comprises
parsing one or more solution composition files comprising metadata associated with the component, the metadata identifying values of output variables of the component that are
used as values of input variables of a second component.
However, parsing configuration files or markup descriptive files to extract metadata and
reference from one component to other objects or components of relevant or similar type has been
shown in Viondury with access and referencing to substitutable resources of the same type (para
0056), the access reference pointing to replaceable, alternate resources being an enhancement implemented with XML/markup language or description (Fig. 1-2) file format that embodies link relocation and reliable referenced object linkage (para 0053-0054) and unique locator indicating a server object (para 0020); hence parsing a composition file and its structured metadata to determine from a current component, a second component logically related to thereto via value setting that references the other/second component is recognized.
Pyo_SM discloses the inter-connectivity relationships among nodes of an AI (artificial intelligence) model in that concept of input node and output node is relative as any node in an output
relationship with one node may have an input relationship with another node and vice versa(top pg. 10); that is, the value into variable input of a node may be determined based on data value at the output at a connected node in accordance with relationship that one or more input nodes are interconnected by respective links to one output nodes; e.g. an output node set to a link with corresponding values input to a respective input node to which the output node connects, as part of the I/O relationship among nodes of an AI model (middle pg. 10)
Based on use of descriptive or teaching language in which concepts are interpreted as nodes (pg. 9) in association with processing a mental model in Hammond (pg. 8) where this teaching language defines blocks of the mental model as capable of receiving input from preceding nodes and providing output to following nodes (see pg. 23; see Note2 from above), it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the learner/acquisition of descriptive information in Hammond CLI tool so that identifying of inter-
component relationships by this module would comprise parsing the one or more solution composition files - e.g. configuration files or markup descriptive files in Viondury or InklingTM teaching language in Hammond - in light of metadata associated with a given component comprised therein, in order to determine, based on the parsing, whether values of output variables of the component that are used as values of input variables of a second component - set forth above as a) using markup format and tag referencing in Viondury; b) the input/output relative relationship between input nodes and output nodes of a AI model per Pyo_SM or c) per the output of one being input to the other per a teaching programming language in Hammond; because
solution composition file provided in portable and highly structured format as set forth
above, would promulgate leverage of any import/export need into target developments, facilitating
cross-platform transport as well as language and concepts format capture/encoding adaptable for
parsing, in the sense that
1) this particular knowledge/information implemented in portable and structural format can
be adapted for use across multiple environments in which elements and data provided in a given file
layout or structure can be parsed, isolated and extracted, collected and/or grouped, filtered or
processed for a design arrangement, application purpose in terms of functional or abstract model,
workflow layout, and parameterized hierarchy/tree;
2) the in-depth parsing and querying of concepts and language node provided in this format
would not only assist in establishing of logically related data/components or objects referred to by
explicit linkage with which to build and augment model component or modular code, to exploit
inter-dependency among elements or objects with which to refer to/fetch or seek substitute or
alternate thereto in building a multi-concept, multi-node flow, but would also identify or suggest
where alternate resources or providers thereof can be located, e.g. navigating identifier type of
location (service URL) for additional resources in indicated location ID or domain provided in
markup portable format.
Nor does Hammond explicitly disclose one or more processors are configured to
(i) connect, based on determining that the second component is logically related to the component, the component and the second component by modifying the one or more solution
composition files such that an input variable of the second component is set to reference an output
variable of the component; and
(ii) generate, from the modified one or more solution composition files, a final solution that is executable.
As for (i)
Pyo_SM discloses inter-connectivity relationships among nodes of an artificial intelligence model in that one given node output may have relationship with input of another node and vice versa (top pg. 10); that is, the value into variable input of a node may be determined based on data value at the output at a connected node in accordance with relationship that one or more input nodes are interconnected by respective links to one output nodes; e.g. an output node set to a link with corresponding values input to a respective input node to which the output node connects, as part of the I/O relationship among nodes of an AI model (middle pg. 10); hence configuration of a AI model where output node set to a link corresponding to values input of nodes connected to the output node is recognized.
Browne discloses an architect module provided to create concept nodes in accordance to their interconnectivity relationship resulting in a AI model, each addition of a concept node made by wrapping (see Abstract) a new concept node (e.g. e.g. external code entity) into a respective SW container interface configured to provide information exchange and language protocol used by the concept node, i.e. the concept node entities formed by the architect module according to description from a scripted file that acts as pedagogical language to connect one concept node to another into a graph nodes (para 0006-0007) conducive to a resulting AI model. The architect module for instance, creates a second concept node derived from the scripted description file and connects the second concept node into the graph of nodes (para 0032-0033) resulting in the AI model, which is being used to effectuate a artificial solution training all the concept nodes (para 0008) to depict/simulate nodes of SW processes (para 0059) of a cooperative service (para 0060-0061) , the AI model being a neural network including interconnected network of processing elements, each neuron thereof receiving data from an input and send data to an output in accordance to connections between the processing elements or neurons of the neural network (para 0036), the wrapping of code entities per the SW services including respective process instance in which each process is configured to be aware of existence of other processes and knows whom to call and what data or input types to look for (para 0037-0038). Hence, use of a interconnect interface with guidance from a description file to add and connect AI nodes in terms of graph nodes representing NN entities, the adding in terms of recognizing input/output between neurons of the NN model where input data of neuron is to be cooperated with what is expected from output from a preceding neuron; depicting thereby the flow relationship of connecting a first component to a second component by modifying the one or more intelligent solution graph/configuration model such that an input variable of the second component is set to reference an output variable of the first component.
As for (ii)
Hammond also discloses training of concept nodes whose simulation can result in a target function to evaluate performance of a learning system, using Inkling TM code as declarative information for the educational learning application (pg. 10); hence configuring nodes of a AI model to generate final simulation configuration or AI-implemented solution that can be executable is recognized.
As shown above, Browne discloses use of a architect interface to connect concept nodes using a description file thereby forming graph nodes of a resulting AI model, which in turn enables simulation of cooperative SW processes of a service (para 0059-0061)
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement processor capability associated with relationship and logical connectivity between component parsed from composition/declaration file for configuring a AI model in Hammond so that based on a parser determination that the second component is logically related to a given first component, the processor is configured to
1) connect the given (first) component and the second component per a modification made to the one or more solution expressed from the parsed file such that an input variable of the second component is set to reference an output variable of the component in accordance to expectation of input/output relationship of node operations – as shown in Pyo_SM build of AI hierarchy of nodes or per the input/output data type linking in Brown for generating a AI neural network as a solution to simulate SW processes of a service; and
2) generate, from the modified one or more solution expressed by the parsed composition file, a final solution – a AI model as in Browne or a target solution for AI learning as in Hammond - that is executable in form of artificial intelligence model; because
building of graph representation of a target model per effect of tracking and collecting relationships from a descriptive structure as part of thorough capture of insights on I/O dependency and input/output variables/types associated with declaration of input and output elements of the components parsed from the descriptive structure (i.e. model composition file) would enhance the graph forming stage into configuration of a executable training model of Hammond, with certainty, safety and validity of the required functional flow dependency, data type dependency and component-to-component variable mapping, where checking interconnectivity of flow dependency associated with functions or calls between the components or nodes of the graph representation, would enable consolidating the proper input/output variables setting required from node inputs that received data outputted from other nodes as set forth above, would ensure the proper call flow between functions or neurons of a AI model (neural network as in Browne) when the graph is being finalized into a resulting AI model; so that simulation-training of actions or functions invoked in the execution of the finalized AI model engine would yield a proper runtime flow with minimal risk of fault and recovery action in which performance result and data flow actions meet expected standards or design requirement set by the AI-based learning environment.
As per claim 8, Hammond discloses command line interface tool of claim 1, wherein the one or more processors are configured to generate a graph (forming a directed graph of concepts - pg. 9) that represents connections between two or more components, the graph comprising: nodes that represent the components; and edges that represent connections between the components (architect module may generate a lower instance of the directed graph of the node - pg. 15, top)
As per claim 11, Hammond discloses a method for performing solution composition, the method comprising:
receiving, by a command line interface tool, an instance of a component;
populating, by the command line interface tool, a solution with at least one module that
supports the instance of the component;
identifying, by the command line interface tool, inter-component relationships comprising the
instance of the component,
wherein identifying the inter-component relationships comprises:
parsing one or more solution composition files comprising metadata associated with
the component, the metadata identifying values of output variables of the component that are
used as values of input variables of a second component; and
determining whether the second component is logically related to the component, the
second component being logically related when the component and the second component
have at least one linked variable value comprising an output variable value of the component
being used as an input variable value of the second component; and
connecting, based on determining that the second component is logically related to the
component, the component and the second component by modifying the one or more solution
composition files such that an input variable of the second component is set to reference an output
variable of the component; and
generating, from the modified one or more solution composition files, a final solution that is
executable.
( All of which having been addressed in claim 1)
As per claim 14, refer to claim 8.
As per claim 16, Hammond discloses a non-transitory computer-readable storage medium storing instructions that, when executed by one or more processors for performing solution composition, cause the one or more processors to:
receive an instance of a component;
populate a solution with at least one module that supports the instance of the component;
identify inter-component relationships comprising the instance of the component,
wherein identifying the inter-component relationships comprises:
parsing one or more solution composition files comprising metadata associated with
the component, the metadata identifying values of output variables of the component that are
used as values of input variables of a second component; and
determining whether the second component is logically related to the component, the
second component being logically related when the component and the second component
have at least one linked variable value comprising an output variable value of the component
being used as an input variable value of the second component; and
connect, based on determining that the second component is logically related to the
component, the component and the second component by modifying the one or more solution
composition files such that an input variable of the second component is set to reference an output
variable of the component; and
generate, from the modified one or more solution composition files, a final solution that is
executable.
( All of which having been addressed in claim 1)
Claims 2, 7, 13, 17 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Hammond et al, CN 109564505 (translation) 03-25-2022, 32 pgs (herein Hammond) in view of Vion-Dury et al, USPubN: 2010/0275117 (herein VionDury), Pyo Sung Min et al, KR 20230097976A, (translation) 7-03-2023, 19 pgs (herein Pyo_SM) and Browne USPubN: 2018/0293517 (herein Browne) further in view of Nawab et al, USPubN: 2023/0334365 (herein Nawab), and Gursha et al, WO 2023200741, 4-10-2023, 64 pgs (herein Gursha)
As per claim 2, Hammond does not explicitly disclose command line interface tool of claim 1, wherein the component comprises the one or more solution composition files, wherein the one or more solution composition files comprise:
a directory of one or more logically related resources used in the solution;
a directory storing data that identifies providers of the one or more logically related resources;
a directory of input variables to be defined in the solution;
a directory of output variables to be defined in the solution; and
a directory of data that corresponds to the inter-component relationships.
Hammond discloses use of InklingTM document to include facts and strategies concepts (pg.
8), which can be represented by a mental model depicting a basic concept (object, role, human) expressed with mutual relationship into a more complex multi-concept according to a need, a policy or a strategy, the multi-concept mental model re-expressed in form of hierarchy of concepts (pg. 9) for
facilitating generation code blocks that reflect the arrangement of the multi-concept nodes or flow of
nodes (see pg. 24), as part of the training of test data fed into the model.
Hence, as file that includes concepts such as facts and strategy elements which can be represented as an abstraction of multi-concept relationships or complex combination thereof, the abstracted model flow of nodes or hierarchy thereof entails file expressing data that corresponds to inter-component relationships for use in generating training code.
As for a logically related resources for implementing a code, Nawab discloses data
acquisition engine, purported for AI/ML analytics within an analytics platform, equipped with an
upload directory in a file system of a storage infrastructure based on which to upload (via APIs), and
store/save operations and items acquired from sources like servers, DAS and SANs, the saved items
to be used by an ingestion engine in coordinating processing resources and suitable parameters for runtime submission and parameterizations. Hence, use of a directory to store/save remotely acquired
items for use by an ingestion module so that file resources and suitable parameters can be submitted
for parameterizing runtime of an AI/ML application entails a file directory configured to contain one
or more logically related resources used in implementation of a solution.
VionDury discloses document and resource packaging being archived for containing inter-dependent resources under a suitable directory structure (para 0054-0055) secured with long-term stability endowed with access and referencing to substitutable resources of the same type (para 0056), the pointing to replaceable resources being an enhancement implemented with markup language or description (Fig. 1-2) file format that embodies link relocation and reliable referenced object linkage (para 0053-0054), the markup document providing unique identifier for path and address of a server via a URL (para 0020); hence implementation of a directory structure to store link relocation and long-term stable referenced object linkage in form of markup format/file entails directory structure for embodying/capturing one or more logically related resources or data that corresponds to the inter-component relationships for use in implementing a problem solution.
Further, Gursha discloses a folder-based management of content and metadata associated with a search-optimization tool operative with transfer of files (e.g. ZIP or XML format) for import or use by a recommendation tool that leverage artificial intelligence or ML algorithms in identifying one or more relationships between the files (para 0064-0065) and assets to provide suggestions, the latter converting content from folders and files into data supportive of a URL tool in form of file-based URLs or directory style URLs (e.g. directory-style URL such as /basketball// server may respond - para 0054-0055), the URL tool providing consistent URLs in accordance to the folder management and metadata incorporated therefrom (para 0066-0067) the contents of a URL or server locator assisting in optimizing depth search/optimization engine (para 0055-0056) and as expansion that can be used to deploy service of a cloud system (para 0068)
Hence, processing transferred XML files and convert their content into URL type directory in
form of consistent URLs indicative of server locations that include metadata and folder-based content in assisting deployment of service code or search engine entails directory storing data that identifies providers of the one or more logically related resources.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to implement relationships of components and modules in Hammond SO
that one or more solution composition files provided with the discovery of components and analysis
of their mutual relationships would comprise:
a directory of data that corresponds to the inter-component relationships as set forth in Nawab and VionDury;
a directory of one or more logically related resources used in the solution -as set forth in VionDury and Nawab;
a directory storing data that identifies providers of the one or more logically related resources - as in Gursha’s creating of directory style URLs and URL indicative of a server in Viondury; because
knowledge data or application-related content (e.g. solution type content) that has been processed and administered into a file system or directory store as configuration type data, logical
assets and related metadata as well as reference to various dependency type and other file records as
set forth above, when structured in format that facilitates their internal management, administrative up-to-date and stability state, import/export leverage and content parsing, would enable elements and data provided in a given layout or structure to be isolated and extracted, collected and/or grouped, filtered or processed for a designer arrangement, functional or abstract model layout for programmatic parameterization; and
parsing of file-based constructs contributes to aiding in the establishing of logically related data and/or components with which to build code and model, inter-dependency among elements or objects with which to refer to/fetch or seek substitute thereto in building a multi-concept, multi-node flow, as well as identifying or suggesting where alternate resources or providers thereof can be retrieved; e.g. in navigating identifier type of location (server URL) in the directory of knowledge domain and metadata referencing provided in files portable format.
As per claim 7, Hammond does not explicitly disclose command line interface tool of claim 1, wherein the one or more processors are configured to parse one or more directories comprising definitions of the component and the at least one module, wherein the definitions comprise one or more commands supported by the component.
But use of files prestored in file system or directory of information so that code forming in a
command line tool would yield SW commands that correspond to functionality of a component or
node- referred herein as (*) - of an artificial intelligence model as in Hammond has been further
illustrated with the teachings by VionDury in form of directory file embodying/capturing one or
more logically related resources or data that corresponds to the inter-component relationships for use
in implementing a problem solution; and in Gursha in terms of parsed contents of a URL or server
locator so to assist in SW implementation in optimizing depth search/optimization engine; as well as
in Nawab file directory which is configured to contain one or more logically related resources used in
implementation of a solution SW (refer to rationale in claim 2).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to implement use of remote storage and file system storage of configuration information associated with the learning and model abstraction stage in Hammond so
that the acquisition of information from solution composition files at the command-line tool would
parse files from one or more directories thereby to identify and extract definitions of a given
component (and/or the at least one module), wherein the definitions comprise programmatic
composition for creating and realizing one or more SW commands supported by the component
included with the intended target model/solution functionality; because
definitions and metadata pre-established in configuration files in terms of type setting,
naming and programmatic formation of variables, parameters would help code forming to generate
proper construct and generation of API/calls written in a specific language, which when translated
with a language compliant compiler would generate API calls or workflow commands that can be
reliably executed or deployed for realizing runtime aspects of a model as intended by Hammond's
system which basically builds its intended software from acquisition of past learning and definitions
from pre-established solution files obtained from repository records or file system directories.
As per claim 13, refer to rationale of claim 7 from above.
As per claim 17, Hammond discloses non-transitory computer readable storage medium of
claim 16, wherein the component comprises the one or more solution composition files, wherein the
one or more solution composition files comprise:
a directory of one or more logically related resources used in the solution;
a directory storing data that identifies providers of the one or more logically related resources;
a directory of input variables to be defined in the solution;
a directory of output variables to be defined in the solution; and
a directory of data that corresponds to the inter-component relationships.
(refer to rationale of claim 2)
Claims 3-4, 19-20 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Hammond et al, CN 109564505 (translation) 03-25-2022, 32 pgs (herein Hammond) in view of Vion-Dury et al, USPubN: 2010/0275117 (herein VionDury), Pyo Sung Min et al, KR 20230097976A, (translation) 7-03-2023, 19 pgs (herein Pyo_SM) and Browne USPubN: 2018/0293517 (herein Browne) further in view of Nawab et al, USPubN: 2023/0334365 (herein Nawab), and Gursha et al, WO 2023200741, 4-10-2023, 64 pgs (herein Gursha) and futher of Chang et al, TX I810419, (translation), 08-01-2023, 14 pgs (herein Chang)
As per claims 3-4, Hammond does not explicitly disclose command line interface tool of claim 2,
(i)wherein defining the input variables and the output variables comprises receiving a user command identifying global variables, wherein a global variable has a same user-defined value across all components within the solution.
(ii) wherein defining the input variables and the output variables comprises receiving a user command identifying non-global variables, wherein a non-global variable has a unique user-defined value in each component within the solution.
It is well-understood that global variables when declared are variable instances destined to
acquire runtime values across all programmatic components or functions declared with such variables
within the wide runtime context; whereas local, non-global variables are variable instances destined
to acquire runtime values for components or functions declared with such variables within a more
definite, restrictive, local runtime context.
Chang, for instance, discloses input and output variables of functions and methods declared
as user- defined parameters in code formation for a system of solving behavioral deviation of
processing equipment, via use of a numerical correction model for determining a range of dimensions
standard (pg. 3) or tolerance range (pg. 5) with which an error can be inspected, detected and for
which a correction parameter can be applied (pg. 6); the correction using a parameter file accorded to
the computer numerical control (CNC) programmed with SW, where preferably, user-defined
parameters are selected among variables that include local variables to adjust local processing
parameters of the equipment, and global variables used to adjust global processing parameters of the
equipment via macros and corrective model program (pg. 2)
Therefore, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to implement program parameters in the file-based implementation of a
solution in Hammond so that input/output variables associated programming code and training using
the command-line tool would include identifying:
1) user-defined global variables, wherein a global variable has a same user-defined value
across all components within the solution
2) user-defined non-global or local variables, wherein a non-global variable has a unique
user-defined value in each component within the solution; the user defined global and non-global
variables as set forth in Chang; because
program destined for executing implementation of a design includes environmental settings
and local settings, and use of defined variables by the programmer to respond to demand of respective settings in accordance to a given programming language in form of either global parameters or non-global parameters would enable optimization of runtime resources, cost reduction of memory space in that local variables as declared by the programmer are destined to operate (take on values) within a short-lived context of local calls defined with them, whereas global variables as declared by the programmer are intended to store values instances across larger environment contexts of global calls defined with them throughout the runtime, where need to maintain global values in runtime memory is expected to outlast the short-lived context of localized calls whose memory portion will be expunged when each local call terminates.
As per claims 19-20, refer to rejection of claims 3-4, respectively.
Claims 9-10, 15 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Hammond et al, CN 109564505 (translation) 03-25-2022, 32 pgs (herein Hammond) in view of Vion-Dury et al, USPubN: 2010/0275117 (herein VionDury), Pyo Sung Min et al, KR 20230097976A, (translation) 7-03-2023, 19 pgs (herein Pyo_SM) and Browne USPubN: 2018/0293517 (herein Browne),further in view of Shah et al, USPubN: 2004/0034497 (herein Shah)
As per claims 9-10, Hammond does not explicitly disclose command line interface tool of claim 1, wherein the one or more processors are configured to:
(ii) receive, from the user, a command to remove an auto-connection between two or more
components; and modify the solution based on the received user command.
(ii) generate solution composition recommendations based on the identified inter-component relationships, causing the one or more processors to further:
recommend that the component and third component within the solution be connected.
Use of inter-connectivity between model functions expressed by a graph of nodes along with call flows input/output relationship depicting AI neural network is shown in Browne, where based on the inter-component relationships comprise confirming how a node functional configuration of input/output includes input variables defined with type matching output from other nodes, or proper output variables defined with type matching input to other nodes, as set forth in the rationale B of claim 1, using the teaching by Browne and Pyo_SM.
Therefore, effect of modifying a graph configuration per a auto-connection action to add a new connection as per Browne is recognized; where finalizing the connectivity of graph nodes to generate a AI model representing a solution to recommend to the AI framework for execution of simulated components associated with the learning framework as set forth above entails generating solution composition recommendations based on the identified inter-component relationships, in which a first component, a second component and a third component is inter-correlated and built into the proposed flow configuration of a graph so to enable to a final build solution for realizing the intended application having simulating functionalities of a artificial intelligence model, as in Browne and Pyo_SM system.
As for adding, removing components and recommending solution based on editing inter-component relationships, Shah discloses a UI rendering of diagrams associated with implementation of specialized solutions for industries, communications, electronics etc. (para 0301), in form of a measurement system designer (MSD) environment that assist the user in designing and creating diagrams connectivity to implement the measurement experiment as intended (para 0011) where the MSD environment is able to automatically determine wiring relationships (para 0073) and automate creation of the programmatic entity therefor (para 0079-0080) where certain portion of the diagrams
(icons adding) may be automatically created based on the automatic detection (para 0093) where icons auto-arranging can be made automatically to improve the appearance (para 0096) or alternately,
the user can be prompted to fulfill the manual routing of a wiring/signal connection (para 0389, 0401)
as option proposed by the MSD, wherein, upon request received from the user, deletion of a direct
connection (para 0390) and removal or an icon/component (para 0178, 0194; user interact with the
tree view remove components - para 0195; para 0216, 0224, 0226; connectable element selected, the
graphical indication be removed - para 0243) can be also performed interactively.
Hence, modifying a graphical representation of solution model upon user request to add or via
an automated recommendation for a user option/prompt to remove an auto-connection between
components being auto-arranged and/or graphically presented is recognized.
Therefore, based on obviousness in the use of composition files to identify inter-component relationships and mutual dependency on logically related resources for a solution based of parsing
the files (refer to obviousness of rationale B in claim 1), it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement connection between nodes or components of the AI model in Hammond so that command line interface tool is configured to
1) modify the solution based on the received user command, such as command to remove an
auto-connection between two or more components - as set forth in the auto-arrangement of icons in
Shah diagram UI and user request to delete a connection or an icon therein;
2) generate a solution composition based on identified inter-component relationships as set forth in the node input/output connecting per Browne and Pyo_SM, in form of a recommendation communicated via an UI (e.g. prompting a user via an option) to the effect that a given component, a second component and the third component within the solution would have to be connected - as set forth with the automatic detection in Shah MSD tool generating a prompt for the user; because
interactive tool and GUI options provided therewith to enable automatic linking or connecting graphical components or icons would obviate constant latency-prone effect of seeking of user or developer approval notably when the tool is relying upon consulting knowledge set in configuration files that securely establish which resource or components are to be linked or interconnected to another resources or component of the solution model under development; and
capability of the tool to prompt user actions and listen to user requests or interaction in order to comply to request thereby to effect a critical editing such as add/remove a connection as set forth above would augment usability and user role by tool, whereas capability to recommend or propose the user with a action such as to add a connection or to link two related nodes - on basis of consulting knowledge information files - would further leverage or expose flexible support by the tool, in terms of responsive or adaptative recommendation by the tool - as set forth above - by which to further promulgate, augment a configuration intent and fine-tune a model functionality reflecting user purposes and context, align them with the how the components interrelate and inter-cooperate with via the model, notably when the model when finalized per the dynamic course of building components or graphical manipulation of concepts or actions associated with therewith, is slated as a recommended solution that particularly encompasses all the action flow arrangement of the intelligent modules provided as a deployable application or AI product that can be executed to support the scope of learning or simulation carried out as action flows as configured or modeled by the users.
As per claim 15, refer to the rationale of claim 9.
Claim 18 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Hammond et al, CN 109564505 (translation) 03-25-2022, 32 pgs (herein Hammond) in view of Vion-Dury et al, USPubN: 2010/0275117 (herein VionDury), Pyo Sung Min et al, KR 20230097976A, (translation) 7-03-2023, 19 pgs (herein Pyo_SM) and Browne USPubN: 2018/0293517 (herein Browne),further in view of Nawab et al, USPubN: 2023/0334365 (herein Nawab), Gursha et al, WO 2023200741, 4-10-2023, 64 pgs (herein Gursha) and Shah et al, USPubN: 2004/0034497 (herein Shah)
As per claim 18, Hammond discloses medium of claim 17, wherein the one or more processors are configured to generate solution composition recommendations based on the identified inter-component relationships, causing the one or more processors to further: recommend that the component and third component within the solution be connected
(refer to rejection of claim 10 as set forth above).
Response to Arguments
Applicant's arguments filed 8/3/26 have been fully considered but they are not persuasive. Following are the Examiner’s observations in regard thereto.
(A) The Applicant has submitted that no degree of generality from the “command line interface” and features of claim 1 would enable a human mind to modify a solution file “so that input variable of one component is set to reference an output variable of a another component” which makes the premise underlying step 2A of the 101 rejection (presented in the Final Action) untenable, notably when the “modification” to components of a file as recited in the claim results from parsing and identifying at variable-level linkages, which are all part of the improvement to the operation of solution tooling, as opposed to mere recitation of generic computer tool to conduct an Abstract Idea (Applicant's Remarks pg. 8-9); and that the “receive” and “populate” limitations are not incidental activities but rather solution-related operations. The new limitations (connect by modifying and setting) as currently added to the inter-component relationships (of claim 1) have addressed as additional activities (connect by modifying or setting) that are fundamentally based on activities or mental derivation from a Abstract Idea type subject matter (e.g. identify, parse, determine). Besides, eligibility merits raised upon a feature newly introduced in the claims being rejected by a previous office action cannot legitimize the statutory weight of the newly introduced feature. The limitations of “receive”and “populate” when construed from the claim, however, do not contain sufficient level of details to make them specifically solution-related or non-conventional activities that are largely superior to standard acts of gathering, forming information using generic computer support so to help mental recognition and data organization.
(B) The Applicant has submitted that Hammond, VionDury, Pyo_SM are not seen as prior art evidences that identify inter-connectivity relationships among nodes of a AI model, least among which about showing what is claimed as “modifying” the one or more solution files “such that input variable of a second component is set to reference an output variable of the other component” (Applicant's Remarks pg. 10-11). The merits of the newly introduced limitation have been prosecuted with an adjusted ground of rejection as presented herein with the latest Office Action, and any allegation of patentability merits of a amendment would be deemed largely premature and moot.
In all, the claims as amended and submitted will stand rejected as set forth above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tuan A Vu whose telephone number is (571) 272-3735. The examiner can normally be reached on 8AM-4:30PM/Mon-Fri.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Chat Do can be reached on (571)272-3721.
The fax phone number for the organization where this application or proceeding is assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571-272-3609.
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 Group receptionist: 571-272-2100.
/Tuan A Vu/
Primary Examiner, Art Unit 2193
August 22, 2026
Prosecution Insights