, 30Notice 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 Rejections - 35 USC § 101
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1 and 3-8 is/are rejected under 35 U.S.C. 101 because they are directed to an abstract idea without significantly more.
Regarding claims 1 and 3-8:
Step 1: With respect to claims 1 and 3-6, applying step 1, the preamble of claims 1and 3-6 claims an apparatus, which falls within the statutory category of an apparatus. With respect to claim 7, applying step 1, the preamble of claim 7 claims a method, which falls within the statutory category of a process. With respect to claim 8, applying step 1, the preamble of claim 8 claims a non-transitory computer readable medium, which falls within the statutory category of a manufacture.
Regarding claim 1,
Step 2A – Prong One: Claim 1 recites an abstract idea. The limitations of “for each acquisition requirement of the acquisition requirement group: identifying whether the input component is included in the acquisition requirement; determining whether the input component can be connected to a new component based on the relationship data;” are processes that can be performed in the human mind and fall within the mental processes grouping of abstract ideas. For example, a human could use observation and evaluation for each acquisition requirement to identify whether the input component is included in the acquisition requirement, and a human could use observation and judgement for each acquisition requirement to determine whether the input component can be connected to a new component based on relationship data. The limitation of “replacing the component in the acquisition requirement with the input component when the input component cannot be connected to the new component” is an abstract idea directed to mathematical concepts, for example, the process of generating a learning requirement by replacing a component with the input component when the input component cannot be connected to the new component amounts to replacing data using probabilistic comparison methods such as a Dice coefficient for determining a replacement.
Step 2A – Prong Two: Claim 1 fails to integrate the judicial exception into practical application. The elements of “a storage storing a system requirement group and relationship data, wherein the relationship data defines a plurality of relationships between component types with respect to a plurality of relationship types, and comprises information identifying which of the component types can be connected; receive input component data corresponding to an input component; acquire the system requirement group from the storage and add the acquired system requirement group to an acquisition requirement group;”, “when the input component is included in the acquisition requirement, generate a learning requirement by: adding the new component to the acquisition requirement and connecting it to the input component when the input component can be connected to the new component;” , and “outputting a graph comprising (i) a plurality of nodes corresponding to a plurality of components of the learning requirement, and (ii) a plurality of edges corresponding to a plurality of component relationships of the learning requirement” are insignificant extra-solution activity that amounts to no more than mere data gathering (See MPEP 2106.05(g)). Simply storing system requirements and relationship data, acquiring the system requirements and storing them in an acquisition requirement group, and outputting a graph of data does not impose any meaningful limitations on generating a learning requirement for a system. The additional element of “at least one processor; memory storing instructions; and wherein the instructions, when executed by at least one processor, cause the learning requirement generation apparatus to:” are mere instructions to apply the abstract idea on a generic computer (See MPEP 2106.05(h)). The computer is recited at a high level of generality and imposes no meaningful limitations on the claim.
Step 2B: Claim 1 does not contain any additional elements that would amount to significantly more than the judicial exception. The elements of “a storage storing a system requirement group and relationship data, wherein the relationship data defines a plurality of relationships between component types with respect to a plurality of relationship types, and comprises information identifying which of the component types can be connected; receive input component data corresponding to an input component; acquire the system requirement group from the storage and add the acquired system requirement group to an acquisition requirement group;”, “when the input component is included in the acquisition requirement, generate a learning requirement by: adding the new component to the acquisition requirement and connecting it to the input component when the input component can be connected to the new component;” , and “outputting a graph comprising (i) a plurality of nodes corresponding to a plurality of components of the learning requirement, and (ii) a plurality of edges corresponding to a plurality of component relationships of the learning requirement” are insignificant extra-solution activity that amounts to no more than mere data gathering (See MPEP 2106.05(g)). Data gathering is a well-understood, routine conventional activity as recognized by the courts (See MPEP 2106.05(d)(II)). Receiving input data, storing system requirements and relationship data, acquiring the system requirements and storing them in an acquisition requirement group, and outputting a graph of data does not impose any meaningful limitations on generating a learning requirement for a system. The additional element of “at least one processor; memory storing instructions; and wherein the instructions, when executed by at least one processor, cause the learning requirement generation apparatus to:” are mere instructions to apply the abstract idea on a generic computer (See MPEP 2106.05(h)). The computer is recited at a high level of generality and imposes no meaningful limitations on the claim.
Regarding claim 7,
Step 2A – Prong One: Claim 7 recites an abstract idea. The limitations of “for each acquisition requirement of the acquisition requirement group: identifying whether the input component is included in the acquisition requirement; determining whether the input component can be connected to a new component based on the relationship data;” are processes that can be performed in the human mind and fall within the mental processes grouping of abstract ideas. For example, a human could use observation and evaluation for each acquisition requirement to identify whether the input component is included in the acquisition requirement, and a human could use observation and judgement for each acquisition requirement to determine whether the input component can be connected to a new component based on relationship data. The limitation of “replacing the component in the acquisition requirement with the input component when the input component cannot be connected to the new component” is an abstract idea directed to mathematical concepts, for example, the process of generating a learning requirement by replacing a component with the input component when the input component cannot be connected to the new component amounts to replacing data using probabilistic comparison methods such as a Dice coefficient for determining a replacement.
Step 2A – Prong Two: Claim 7 fails to integrate the judicial exception into practical application. The elements of “storing, in a storage, a system requirement group and relationship data, wherein the relationship data defines a plurality of relationships between component types with respect to a plurality of relationship types, and comprises information identifying which of the component types can be connected; receiving input component data corresponding to an input component; acquiring the system requirement group from the storage and adding the acquired system requirement group to an acquisition requirement group;”, “when the input component is included in the acquisition requirement, generate a learning requirement by: adding the new component to the acquisition requirement and connecting it to the input component when the input component can be connected to the new component;” , and “outputting a graph comprising (i) a plurality of nodes corresponding to a plurality of components of the learning requirement, and (ii) a plurality of edges corresponding to a plurality of component relationships of the learning requirement” are insignificant extra-solution activity that amounts to no more than mere data gathering (See MPEP 2106.05(g)). Receiving input data, storing system requirements and relationship data, acquiring the system requirements and storing them in an acquisition requirement group, and outputting a graph of data does not impose any meaningful limitations on generating a learning requirement for a system.
Step 2B: Claim 7 does not contain any additional elements that would amount to significantly more than the judicial exception. The elements of “storing, in a storage, a system requirement group and relationship data, wherein the relationship data defines a plurality of relationships between component types with respect to a plurality of relationship types, and comprises information identifying which of the component types can be connected; receiving input component data corresponding to an input component; acquiring the system requirement group from the storage and adding the acquired system requirement group to an acquisition requirement group;”, “when the input component is included in the acquisition requirement, generate a learning requirement by: adding the new component to the acquisition requirement and connecting it to the input component when the input component can be connected to the new component;” , and “outputting a graph comprising (i) a plurality of nodes corresponding to a plurality of components of the learning requirement, and (ii) a plurality of edges corresponding to a plurality of component relationships of the learning requirement” are insignificant extra-solution activity that amounts to no more than mere data gathering (See MPEP 2106.05(g)). Receiving input data, storing system requirements and relationship data, acquiring the system requirements and storing them in an acquisition requirement group, and outputting a graph of data does not impose any meaningful limitations on generating a learning requirement for a system. Data gathering is a well-understood, routine conventional activity as recognized by the courts (See MPEP 2106.05(d)(II)). Receiving input data, storing system requirements and relationship data, acquiring the system requirements and storing them in an acquisition requirement group, and outputting a graph of data does not impose any meaningful limitations on generating a learning requirement for a system.
Regarding claim 8,
Step 2A – Prong One: Claim 8 recites an abstract idea. The limitations of “for each acquisition requirement of the acquisition requirement group: identifying whether the input component is included in the acquisition requirement; determining whether the input component can be connected to a new component based on the relationship data;” are processes that can be performed in the human mind and fall within the mental processes grouping of abstract ideas. For example, a human could use observation and evaluation for each acquisition requirement to identify whether the input component is included in the acquisition requirement, and a human could use observation and judgement for each acquisition requirement to determine whether the input component can be connected to a new component based on relationship data. The limitation of “replacing the component in the acquisition requirement with the input component when the input component cannot be connected to the new component” is an abstract idea directed to mathematical concepts, for example, the process of generating a learning requirement by replacing a component with the input component when the input component cannot be connected to the new component amounts to replacing data using probabilistic comparison methods such as a Dice coefficient for determining a replacement.
Step 2A – Prong Two: Claim 8 fails to integrate the judicial exception into practical application. The elements of “storing, in a storage, a system requirement group and relationship data, wherein the relationship data defines a plurality of relationships between component types with respect to a plurality of relationship types, and comprises information identifying which of the component types can be connected; receiving input component data corresponding to an input component; acquiring the system requirement group from the storage and adding the acquired system requirement group to an acquisition requirement group;”, “when the input component is included in the acquisition requirement, generate a learning requirement by: adding the new component to the acquisition requirement and connecting it to the input component when the input component can be connected to the new component;” , and “outputting a graph comprising (i) a plurality of nodes corresponding to a plurality of components of the learning requirement, and (ii) a plurality of edges corresponding to a plurality of component relationships of the learning requirement” are insignificant extra-solution activity that amounts to no more than mere data gathering (See MPEP 2106.05(g)). Receiving input data, storing system requirements and relationship data, acquiring the system requirements and storing them in an acquisition requirement group, and outputting a graph of data does not impose any meaningful limitations on generating a learning requirement for a system.
Step 2B: Claim 8 does not contain any additional elements that would amount to significantly more than the judicial exception. The elements of “storing, in a storage, a system requirement group and relationship data, wherein the relationship data defines a plurality of relationships between component types with respect to a plurality of relationship types, and comprises information identifying which of the component types can be connected; receiving input component data corresponding to an input component; acquiring the system requirement group from the storage and adding the acquired system requirement group to an acquisition requirement group;”, “when the input component is included in the acquisition requirement, generate a learning requirement by: adding the new component to the acquisition requirement and connecting it to the input component when the input component can be connected to the new component;” , and “outputting a graph comprising (i) a plurality of nodes corresponding to a plurality of components of the learning requirement, and (ii) a plurality of edges corresponding to a plurality of component relationships of the learning requirement” are insignificant extra-solution activity that amounts to no more than mere data gathering (See MPEP 2106.05(g)). Receiving input data, storing system requirements and relationship data, acquiring the system requirements and storing them in an acquisition requirement group, and outputting a graph of data does not impose any meaningful limitations on generating a learning requirement for a system. Data gathering is a well-understood, routine conventional activity as recognized by the courts (See MPEP 2106.05(d)(II)). Receiving input data, storing system requirements and relationship data, acquiring the system requirements and storing them in an acquisition requirement group, and outputting a graph of data does not impose any meaningful limitations on generating a learning requirement for a system.
Regarding claim 3,
Step 2A – Prong Two: Claim 3 fails to integrate the judicial exception into practical application. The element of “store the generated learning requirement in the storage and add the generated learning requirement to a learning requirement group, and output the learning requirement group” is insignificant extra-solution activity that amounts to no more than mere data gathering (See MPEP 2106.05(g)). Storing the learning requirements in the storage unit and adding the learning requirement to a group, and outputting the learning requirement group imposes no meaningful limitations on generating a learning requirement for a system, rather it only describes a process of storing and outputting the requirement.
Step 2B: Claim 3 does not contain any additional elements that would amount to significantly more than the judicial exception. The element of “store the generated learning requirement in the storage and add the generated learning requirement to a learning requirement group, and output the learning requirement group” is insignificant extra-solution activity that amounts to no more than mere data gathering (See MPEP 2106.05(g)). Data gathering is a well-understood, routine conventional activity as recognized by the courts (See MPEP 2106.05(d)(II)). Storing the learning requirements in the storage unit and adding the learning requirement to a group, and outputting the learning requirement group imposes no meaningful limitations on generating a learning requirement for a system, rather it only describes a process of storing and outputting the requirement.
Regarding claim 4,
Step 2A – Prong One: Claim 4 recites an abstract idea. The limitation of “for each of extension requirements that compose the extension requirement group, acquire a system requirement from the storage, the system requirement being similar to the extension requirement and not including the input component, and add the acquired system requirement to a similarity requirement group, and for each of the similarity requirements that compose the similarity requirement group, when a component that can be replaced with the input component is included in the similarity requirement, generate the learning requirement by replacing the component included in the similarity requirement with the input component,” is an abstract idea directed to mathematical concepts, for example, the process of determining a system requirement being similar to the extension requirement, and adding the acquired system requirement to a similarity requirement group, where each of the similarity requirements can be used to replace a component, and generating a new learning requirement with the replaced component amounts to comparing data using probabilistic comparison formulas such as the Dice coefficient, organizing the similar requirements such that they can be used to replace a data component in a dataset, and generating a new requirement with the replaced component is a mathematical process.
Step 2A – Prong Two: Claim 4 fails to integrate the judicial exception into practical application. The element of “for each of the acquisition requirements that compose the acquisition requirement group, when the input component is included in the acquisition requirement and the input component can be connected to the new component, generate an extension requirement by adding the new component to the acquisition requirement and by connecting the added new component to the input component, and then add the generated extension requirement to an extension requirement group;” is insignificant extra-solution activity that amounts to no more than mere data gathering (See MPEP 2106.05(g)). The process of acquiring the system requirement group and adding it to the acquisition requirement group, and an extension requirement generation unit that generates extension requirements by adding or connecting the input component to a new component to then add the generated extension requirement to a group, amounts to gathering data without imposing meaningful limitations on generating a learning requirement for a system.
Step 2B: Claim 4 does not contain any additional elements that would amount to significantly more than the judicial exception. The element of “for each of the acquisition requirements that compose the acquisition requirement group, when the input component is included in the acquisition requirement and the input component can be connected to the new component, generate an extension requirement by adding the new component to the acquisition requirement and by connecting the added new component to the input component, and then add the generated extension requirement to an extension requirement group;” is insignificant extra-solution activity that amounts to no more than mere data gathering (See MPEP 2106.05(g)). Data gathering is a well-understood, routine conventional activity as recognized by the courts (See MPEP 2106.05(d)(II)). The process of acquiring the system requirement group and adding it to the acquisition requirement group, and an extension requirement generation unit that generates extension requirements by adding or connecting the input component to a new component to then add the generated extension requirement to a group, amounts to gathering data without imposing meaningful limitations on generating a learning requirement for a system.
Regarding claim 5,
Step 2A – Prong Two: Claim 5 fails to integrate the judicial exception into practical application. The element of “store the generated extension requirement in the storage unit, store the generated learning requirement in the storage and add the generated learning requirement to the learning requirement group, and output the learning requirement group” is insignificant extra-solution activity that amounts to no more than mere data gathering (See MPEP 2106.05(g)). Storing the generated extension requirement, storing the generated learning requirement and adding it to the learning requirement group, and then outputting the learning requirement group amounts to collecting and outputting data and does not impose meaningful limitations on generating or evaluating system requirements.
Step 2B: Claim 5 does not contain any additional elements that would amount to significantly more than the judicial exception. The element of “store the generated extension requirement in the storage unit, store the generated learning requirement in the storage and add the generated learning requirement to the learning requirement group, and output the learning requirement group” is insignificant extra-solution activity that amounts to no more than mere data gathering (See MPEP 2106.05(g)). Data gathering is a well-understood, routine conventional activity as recognized by the courts (See MPEP 2106.05(d)(II)). Storing the generated extension requirement, storing the generated learning requirement and adding it to the learning requirement group, and then outputting the learning requirement group amounts to collecting and outputting data and does not impose meaningful limitations on generating or evaluating system requirements.
Regarding claim 6,
Step 2A – Prong One: Claim 6 recites an abstract idea. The limitation of “determine, by using a Dice coefficient, a similarity between each of the system requirements that do not include the input components and each of the corresponding extension requirements” is an abstract idea directed to mathematical concepts, for example, using a Dice coefficient to determine a numerical similarity for the purpose of replacing a component is a mathematical concept. Additionally, the element of “acquire the system requirement having a highest similarity to one of the extension requirements from the storage, and add the acquired system requirement to the similarity requirement group” is an abstract idea directed to mental processes, for example, a human could use observation and analysis to acquire the system requirement having a highest similarity to one of the extension requirements, and add the acquired system requirement to a group.
Step 2A – Prong Two: Claim 6 fails to integrate the judicial exception into practical application. The element of “the system requirements and the extension requirements having been stored in the storage” is insignificant extra-solution activity that amounts to mere data gathering (See MPEP 2106.05(g)).
Step 2B: Claim 6 does not contain any additional elements that would amount to significantly more than the judicial exception. The element of “the system requirements and the extension requirements having been stored in the storage” is insignificant extra-solution activity that amounts to mere data gathering (See MPEP 2106.05(g)). Data gathering is a well-understood, routine conventional activity as recognized by the courts (See MPEP 2106.05(d)(II)).
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1, 3-5, and 7-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US Pub. No. 2022/0126445, hereinafter “Zhu”), in view of Kuroda et al. (NPL: Model-Based IT Change Management for Large System Definitions with State-Related Dependencies, hereinafter “Kuroda”), and further in view of Maeda et al. (From IDS: JP2017/084224, hereinafter “Maeda”) and Hegedus et al. (NPL: A Model-driven Framework for Guided Design Space Exploration, hereinafter “Hegedus”).
Regarding claim 1, Zhu teaches a learning requirement generation apparatus comprising:
at least one processor; memory storing instructions (Zhu, [0065] – “In at least one embodiment, control computer system 102 includes a processor and memory-storing instructions” – teaches at least one processor and a memory storing instructions); and
a storage storing a system requirement group (Zhu, [0370] — “a system storage unit 1914 can connect to I/O hub 1907 to provide a storage mechanism for computing system 1900. In at least one embodiment, an I/O switch 1916 can be used to provide an interface mechanism to enable connections between I/O hub 1907 and other components, such as a network adapter 1918 and/or a wireless network adapter 1919 that may be integrated into platform, and various other devices that can be added via one or more add-in device(s) 1920.” — teaches storing a system requirement group)
wherein the instructions, when executed by the at least one processor, cause the learning requirement generation apparatus to (Zhu, [0065] – “control computer system 102 includes a processor and memory-storing instructions that as a result of being executed by said processor, cause control computer system 102 to”):
acquire the system requirement group from the storage and add the acquired system requirement group to an acquisition requirement group (Zhu, [0676] — “In at least one embodiment, processes of obtaining, acquiring, receiving, or inputting analog or digital data can be accomplished by transferring data via a computer network from providing entity to acquiring entity.” — teaches a requirement acquisition unit configured to acquire the system requirement group from the storage unit (providing entity) and add it to an acquisition group (acquiring entity));
Zhu fails to explicitly teach relationship data, wherein the relationship data defines a plurality of relationships between component types with respect to a plurality of relationship types, and comprises information identifying which of the component types can be connected, and replacing the component in the acquisition requirement with the input component when the input component cannot be connected to the new component.
However, analogous to the field of information communication technology, Kuroda teaches:
relationship data, wherein the relationship data defines a plurality of relationships between component types with respect to a plurality of relationship types, and comprises information identifying which of the component types can be connected (Kuroda, Section 2C Subsection 3 Paragraph 4 – “In version 1, “gateway Server” is connected with “rack” but it is replaced with “serverWithNIC” composite in version 2. Thus, the “gateway Server” is connected with old wires (“NW2” and “RS2”), and “server” and “nic” are connected with new wires (“NW3”, “RS3” and “PCI”) in the delta instance” and in Section 2C Subsection 1 Paragraph 2 – “A Wireport defines a port to connect the primitive with other component. There are two types of wireports: Consume and Accept. A wire2 (i.e., a connection) is always defined between a consume and accept of different components. Every wireport has a wire interface so that only pairs of consume and accept which have the same wire interface can be connected with each other.” and Section 2C Subsection 1 Paragraph 3 – “The “server” in Figure 2 has two parts: “box” and “top”, and three wireports: “NW”, “PCI” and “RS”. “NW” implies a connection of a network port, “PCI” means a connection of a PCIExpress port, and “RS” implies an insertion point for the server in the rack space… “top” and “RS” have mutual dependencies on their states. “server” has to be separated from “RS” when its top is being opened or closed. Dependencies can be defined between wireports. The dependency of “RS” onto sNW,sep means that the network port should be connected after the “server” is inserted into a rack space, and it should be separated before “server” is taken from the rack space” – teaches relationship data (wires, wireports) wherein the relationship data defines a plurality of relationships between component types with respect to a plurality of different relationship types (three different wireports), and comprises information (dependencies) identifying which of the component types can be connected (dependencies indicate which component types can be connected and when, such as the dependency of RS onto SNW,sep means network port is connected after server is inserted into rack space))
replacing the component in the acquisition requirement with the input component when the input component cannot be connected to the new component (Kuroda, Section 2C Subsection 3 Paragraph 4 — “Version 1 shows the current existing system states stored in our change management function and version 2 shows the definition of the desired states input by an administrator. In version 1, “gateway Server” is connected with “rack” but it is replaced with “serverWithNIC” composite in version 2. Thus, the “gateway Server” is connected with old wires (“NW2” and “RS2”), and “server” and “nic” are connected with new wires (“NW3”, “RS3” and “PCI”) in the delta instance.” — teaches replacing a component (replacing “gateway Server” component with “serverWithNIC”) in the acquisition requirements (desired state) when the component cannot be connected to the new component);
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the relationship data and replacing of components of Kuroda to the storage and acquisition units of Zhu in order to automatically generate learning requirements. Doing so would model-based IT change management scheme that can generate tasks that can not only deploy a system from scratch but also make changes to an already deployed system and automate the process of task generation (Kuroda, Section I).
The combination of Zhu and Kuroda fails to explicitly teach receiving input component data corresponding to an input component, for each acquisition requirement of the acquisition requirement group: identify whether the input component is included in the acquisition requirement, and when the input component is included in the acquisition requirement, generate a learning requirement by: adding the new component to the acquisition requirement and connecting it to the input component when the input component can be connected to the new component;
However, analogous to the field of the claimed invention, Maeda teaches:
receive input component data corresponding to an input component (Maeda, [0032] — “On the basis of the input new customer estimation request, the extraction unit 202 of the design item analysis item extracts a category of the target product, an item requiring analysis, and an item requiring learning with a priority order. The extracted design item and the estimation request are transmitted to the learning unit 108, and the analysis item and the product category are transmitted to the analysis model selection unit 301 of the simulation unit 106.” — teaches inputting component data representing an input component);
for each acquisition requirement of the acquisition requirement group: identify whether the input component is included in the acquisition requirement (Maeda, [0032] — “On the basis of the input new customer estimation request, the extraction unit 202 of the design item analysis item extracts a category of the target product, an item requiring analysis, and an item requiring learning with a priority order. The extracted design item and the estimation request are transmitted to the learning unit 108, and the analysis item and the product category are transmitted to the analysis model selection unit 301 of the simulation unit 106.” — identifying whether the input component is included in the acquisition requirement, for each acquisition requirement of the acquisition requirement group (extraction unit 202 extracts category of target product on basis of input new customer estimation request, and transmits to learning unit, thus identifying whether the input component is included in the acquisition requirement));
when the input component is included in the acquisition requirement, generate a learning requirement by: adding the new component to the acquisition requirement and connecting it to the input component when the input component can be connected to the new component (Maeda, [0053]- “Step S 504: The extraction unit 202 of the design item analysis item outputs the extracted item to the learning unit 108 and the analysis model selection unit 301. In the extraction unit 202 of the design item analysis item, the corrosion resistance added as the new customer request is output to the learning unit 108 as an additional design item. In addition, a corrosion analysis is extracted as an analysis item corresponding to the corrosion resistance, and transmitted to the analysis model selection unit 301.” — teaches an input component included in the acquisition requirement (extracted item, corrosion resistance) and connects the input component to a new component (added as a new customer request and output to learning unit 108) when the component can be connected to the new component);
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the receiving and identifying of input components, and adding and connecting of components of Maeda to the apparatus of Zhu and Kuroda in order to add the input components. Doing so would generate a design plan in a short period of time and enable interactive design of the plan dependent on various requests (Maeda, [0011]).
The combination of Zhu, Kuroda, and Maeda fails to explicitly teach determine whether the input component can be connected to a new component based on the relationship data and outputting a graph comprising (i) a plurality of nodes corresponding to a plurality of components of the learning requirement, and (ii) a plurality of edges corresponding to a plurality of component relationships of the learning requirement.
However, analogous to the field of the claimed invention, Hegedus teaches:
relationship data, wherein the relationship data defines a plurality of relationships between component types with respect to a plurality of relationship types, and comprises information identifying which of the component types can be connected (Hegedus, Section IV, Subsection B, Paragraph 3 – “Edge deployedOn is a relation that connects two different components denoting that the source node is deployed on the target node of this relation.” – teaches relationship data, wherein the relationship data defines a plurality of relationships between component types with respect to a plurality of relationship types (edge deployedOn denotes that the source node is deployed on the target node of this relation, thus defining a relationship between component types) and in Section IV, Subsection D, Paragraph 4 – “The addCM rule adds a new cloud CM, addS creates a new server S deploying it on top of a CM or cluster CI, however, a CI cannot have more than two S deployed on it. Rule addCI produces a new CI deploying it on top of a CM, addDb adds a new database DB deploying it on top of two S that have no other Node deployed on them, addApp creates a new application App deploying it on top of two DB that have no other Node deployed on them.” – teaches relationship data (rules) comprising information identifying which of the component types can be connected (rules indicate which components can be connected));
determine whether the input component can be connected to a new component based on the relationship data (Hegedus, Section IV, Subsection D, Paragraph 4 – “The addCM rule adds a new cloud CM, addS creates a new server S deploying it on top of a CM or cluster CI, however, a CI cannot have more than two S deployed on it. Rule addCI produces a new CI deploying it on top of a CM, addDb adds a new database DB deploying it on top of two S that have no other Node deployed on them, addApp creates a new application App deploying it on top of two DB that have no other Node deployed on them.” – teaches relationship data (rules) comprising information identifying which of the component types can be connected, and uses the relationship data to determine whether the input component can be connected to a new component (rules indicate which components can be connected)));
outputting a graph comprising (i) a plurality of nodes corresponding to a plurality of components of the learning requirement, and (ii) a plurality of edges corresponding to a plurality of component relationships of the learning requirement (Hegedus, Section IV, Subsection B, Paragraph 3 – “The left part of Figure 4 shows the metamodel for the cloud case study. The metamodel contains a cloud component Node designated graphically as a rectangle. The specific components Socket, Server, Database, Application and Storage are specialized from this node, Socket is a generalization of Cloud MW and Cluster). Edge deployedOn is a relation that connects two different components denoting that the source node is deployed on the target node of this relation. The right part of Figure 4 illustrates an instance model containing a database d deployed on two servers s1,s2 that are on cloud c. Note that in the rest of the paper, we omit deployedOn (dOn) relations by illustrating the relation using vertical arrangement of components.” – teaches outputting a graph comprising (i) a plurality of nodes corresponding to a plurality of components of the learning requirement (model contains a cloud component Node, each node in Fig. 4 is a component) and (ii) a plurality of edges corresponding to a plurality of component relationships (edge deployedOn is a relation that connects two different components, denoting that the source node is deployed on the target node of this relation) of the learning requirement).
Therefore, it would have been obvious to combine the determining of input component connections and output of graphs with nodes representing components and edges representing component relationships of Hegedus to the components, relationship data, adding components, and replacing components of Zhu, Kuroda, and Maeda in order to output a graph representing the components and their relationships. Doing so would support dynamic handling of goals, constraints and rules for different configurations (Hegedus, Section IV Subsection D).
Regarding claim 7, Zhu teaches a learning requirement generation method performed by a learning requirement generation apparatus, the learning requirement generation method comprising:
storing, in a storage, a system requirement group (Zhu, [0370] – “a system storage unit 1914 can connect to I/O hub to provide a storage mechanism for computing system 1900. In at least one embodiment, an I/O switch 1916 can be used to provide an interface mechanism to enable connections between I/O hub 1907 and other components, such as a network adapter 1918 and/or a wireless network adapter 1919 that may be integrated into platform, and various other devices that can be added via one or more add-in device(s) 1920.” — teaches storing a system requirement group)
acquiring the system requirement group from the storage and adding the acquired system requirement group to an acquisition requirement group (Zhu, [0676] — “In at least one embodiment, processes of obtaining, acquiring, receiving, or inputting analog or digital data can be accomplished by transferring data via a computer network from providing entity to acquiring entity.” — teaches a requirement acquisition unit configured to acquire the system requirement group from the storage unit (providing entity) and add it to an acquisition group (acquiring entity));
Zhu fails to explicitly teach relationship data, wherein the relationship data defines a plurality of relationships between component types with respect to a plurality of relationship types, and comprises information identifying which of the component types can be connected, and replacing the component in the acquisition requirement with the input component when the input component cannot be connected to the new component.
However, analogous to the field of information communication technology, Kuroda teaches:
relationship data, wherein the relationship data defines a plurality of relationships between component types with respect to a plurality of relationship types, and comprises information identifying which of the component types can be connected (Kuroda, Section 2C Subsection 3 Paragraph 4 – “In version 1, “gateway Server” is connected with “rack” but it is replaced with “serverWithNIC” composite in version 2. Thus, the “gateway Server” is connected with old wires (“NW2” and “RS2”), and “server” and “nic” are connected with new wires (“NW3”, “RS3” and “PCI”) in the delta instance” and in Section 2C Subsection 1 Paragraph 2 – “A Wireport defines a port to connect the primitive with other component. There are two types of wireports: Consume and Accept. A wire2 (i.e., a connection) is always defined between a consume and accept of different components. Every wireport has a wire interface so that only pairs of consume and accept which have the same wire interface can be connected with each other.” and Section 2C Subsection 1 Paragraph 3 – “The “server” in Figure 2 has two parts: “box” and “top”, and three wireports: “NW”, “PCI” and “RS”. “NW” implies a connection of a network port, “PCI” means a connection of a PCIExpress port, and “RS” implies an insertion point for the server in the rack space… “top” and “RS” have mutual dependencies on their states. “server” has to be separated from “RS” when its top is being opened or closed. Dependencies can be defined between wireports. The dependency of “RS” onto sNW,sep means that the network port should be connected after the “server” is inserted into a rack space, and it should be separated before “server” is taken from the rack space” – teaches relationship data (wires, wireports) wherein the relationship data defines a plurality of relationships between component types with respect to a plurality of different relationship types (three different wireports), and comprises information (dependencies) identifying which of the component types can be connected (dependencies indicate which component types can be connected and when, such as the dependency of RS onto SNW,sep means network port is connected after server is inserted into rack space))
replacing the component in the acquisition requirement with the input component when the input component cannot be connected to the new component (Kuroda, Section 2C Subsection 3 Paragraph 4 — “Version 1 shows the current existing system states stored in our change management function and version 2 shows the definition of the desired states input by an administrator. In version 1, “gateway Server” is connected with “rack” but it is replaced with “serverWithNIC” composite in version 2. Thus, the “gateway Server” is connected with old wires (“NW2” and “RS2”), and “server” and “nic” are connected with new wires (“NW3”, “RS3” and “PCI”) in the delta instance.” — teaches replacing a component (replacing “gateway Server” component with “serverWithNIC”) in the acquisition requirements (desired state) when the component cannot be connected to the new component);
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the relationship data and replacing of components of Kuroda to the storage and acquisition units of Zhu in order to automatically generate learning requirements. Doing so would model-based IT change management scheme that can generate tasks that can not only deploy a system from scratch but also make changes to an already deployed system and automate the process of task generation (Kuroda, Section I).
The combination of Zhu and Kuroda fails to explicitly teach receiving input component data corresponding to an input component, for each acquisition requirement of the acquisition requirement group: identify whether the input component is included in the acquisition requirement, and when the input component is included in the acquisition requirement, generate a learning requirement by: adding the new component to the acquisition requirement and connecting it to the input component when the input component can be connected to the new component;
However, analogous to the field of the claimed invention, Maeda teaches:
receiving input component data corresponding to an input component (Maeda, [0032] — “On the basis of the input new customer estimation request, the extraction unit 202 of the design item analysis item extracts a category of the target product, an item requiring analysis, and an item requiring learning with a priority order. The extracted design item and the estimation request are transmitted to the learning unit 108, and the analysis item and the product category are transmitted to the analysis model selection unit 301 of the simulation unit 106.” — teaches inputting component data representing an input component);
for each acquisition requirement of the acquisition requirement group: identifying whether the input component is included in the acquisition requirement (Maeda, [0032] — “On the basis of the input new customer estimation request, the extraction unit 202 of the design item analysis item extracts a category of the target product, an item requiring analysis, and an item requiring learning with a priority order. The extracted design item and the estimation request are transmitted to the learning unit 108, and the analysis item and the product category are transmitted to the analysis model selection unit 301 of the simulation unit 106.” — identifying whether the input component is included in the acquisition requirement, for each acquisition requirement of the acquisition requirement group (extraction unit 202 extracts category of target product on basis of input new customer estimation request, and transmits to learning unit, thus identifying whether the input component is included in the acquisition requirement));
when the input component is included in the acquisition requirement, generate a learning requirement by: adding the new component to the acquisition requirement and connecting it to the input component when the input component can be connected to the new component (Maeda, [0053]- “Step S 504: The extraction unit 202 of the design item analysis item outputs the extracted item to the learning unit 108 and the analysis model selection unit 301. In the extraction unit 202 of the design item analysis item, the corrosion resistance added as the new customer request is output to the learning unit 108 as an additional design item. In addition, a corrosion analysis is extracted as an analysis item corresponding to the corrosion resistance, and transmitted to the analysis model selection unit 301.” — teaches an input component included in the acquisition requirement (extracted item, corrosion resistance) and connects the input component to a new component (added as a new customer request and output to learning unit 108) when the component can be connected to the new component);
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the receiving and identifying of input components, and adding and connecting of components of Maeda to the apparatus of Zhu and Kuroda in order to add the input component. Doing so would generate a design plan in a short period of time and enable interactive design of the plan dependent on various requests (Maeda, [0011]).
The combination of Zhu, Kuroda, and Maeda fails to explicitly teach determining whether the input component can be connected to a new component based on the relationship data and outputting a graph comprising (i) a plurality of nodes corresponding to a plurality of components of the learning requirement, and (ii) a plurality of edges corresponding to a plurality of component relationships of the learning requirement.
However, analogous to the field o