DETAILED ACTION
Status of the Claims
The following is a Non-final Office Action in response to amendments and remarks filed 27 March 2026.
Claim 1 has been amended.
Claims 1-5, 7, and 10-16 are pending have been examined.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 27 March 2026 has been entered.
Response to Arguments
Applicant argues that the claims are eligible under §101; however the Examiner respectfully disagrees. The Examiner notes that in order to be patent eligible under 35 U.S.C. 101, the claims must be directed towards a patent eligible concept, which, the instant claims are not directed. Contrary to Applicants’ assertion that the claims are not a mental process or certain method of organizing human activity, the Examiner notes that organizing information such as modules for a plant based upon semantics is commercial interaction such as how to store or file different modules in a library for a plant (i.e. a manufacturing business) and that the optimization of such is a mental judgement upon the data. The claims, at best, describe a general methodology of how to store information relating or describing modules for plants. Next, the claims are not directed to a practical application of the concept. The claims do not result in improvements to the functioning of a computer or to any other technology or technical field. They do not effect a particular treatment for a disease. They are not applied with or by a particular machine. They do not effect a transformation or reduction of a particular article to a different state or thing. And they are not applied in some other meaningful way beyond generally linking the use of the judicial exception (i.e., how to store or organize information related to business or plant modules) to a particular technological environment (i.e., using software). The newly amended aspect of having one or more computer processors performing the steps only amount to nothing more than an instruction to apply the abstract idea using a generic computer or invoking computers as tools by adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.04(d)(I) discussing MPEP 2106.05(f). Here, again as noted in the previous rejections, mere instructions to apply an exception using a generic computer component cannot provide an inventive concept - MPEP 2016.05(f). The claims recitation of the “resource management system,” “database” “module(s)” is only generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). The claim(s) is/are not patent eligible, even when considered as a whole.
Applicant next argues that the claims are an integration of the abstract idea into a practical application (citing Ex Parte Desjardins); however the Examiner respectfully does not find the assertion persuasive as this argument appears to be whether or not the use of computer or computing components for increased speed and efficiency (i.e. automatically) integrates the claims into a practical application; however the Examiner respectfully disagrees. Nor, in addressing the second step of Alice, does claiming the improved speed or efficiency inherent with applying the abstract idea on a computer provide a sufficient inventive concept. See Bancorp Servs., LLC v. Sun Life Assurance Co. of Can., 687 F.3d 1266, 1278 (Fed. Cir. 2012) (“[T]he fact that the required calculations could be performed more efficiently via a computer does not materially alter the patent eligibility of the claimed subject matter.”); CLS Bank, Int’l v. Alice Corp., 717 F.3d 1269, 1286 (Fed. Cir. 2013) (en banc) aff’d, 134 S. Ct. 2347 (2014) (“[S]imply appending generic computer functionality to lend speed or efficiency to the performance of an otherwise abstract concept does not meaningfully limit claim scope for purposes of patent eligibility.” (citations omitted)). As such the arguments are not persuasive, and the rejection not withdrawn.
Applicant next argues that the claims amount to significantly more; however the Examiner respectfully disagrees. Again, as noted in previous rejections and above, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception (Step 2B). As discussed above with respect to integration of the abstract idea into a practical application (Step 2A Prong 2), the additional element of using one or more processors with a database and modules within the steps amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Similarly, only generally linking the use of the judicial exception to a particular technical environment or field of use does not amount to significantly more. Reevaluating here in step 2B, the “receiving, by a computer-implemented module pipeline generation engine in response to user input at an input interface...,” “a database-implemented a module library storing machine-readable semantic modules representing respective real and virtual modules in a module pool, the modules being modular process equipment connectable together to form a process line, wherein a real module is an instance of a module of a particular type, implemented in software, firmware and/or hardware” step(s) which are insignificant extrasolution activities are also determined to be well-understood, routine and conventional activity in the field. The Symantec, TLI, and OIP Techs court decisions in MPEP 2106.05(d)(II) indicate that the mere receipt or transmission of data over a network is well-understood, routine, and conventional function when it is claimed in a merely generic manner (as is here). Therefore, when considering the additional elements alone, and in combination, there is no inventive concept in the claim. As such, the claim(s) is/are not patent eligible, even when considered as a whole (Step 2B: NO). As such the arguments are not persuasive, and the rejection not withdrawn.
Applicant’s arguments with respect to the prior art have been fully considered but are not persuasive for a plurality of reasons. Firstly, Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. Secondly, Applicant's arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references cited or the objections made. Further, they do not show how the amendments avoid such references or objections. More specifically, Applicant provides mere conclusory statements regarding portions of the Sobalvarro reference, without any further analysis. Applicant is simply restating the claim language and argues the reference does not teach or suggest the particular language. Thirdly, and contrary to Applicant’s assertions, the Sobalvarro workcells could actually be physically connected together and process equipment connectable together to form a process line (i.e. machines in order in a workcell or workcells connected together), which is a reasonable interpretation of one of ordinary skill in the art of manufacturing would glean as workcells or production cells in a lean or just-in-time environment are often connected to ensure less travel time for inventory/product/throughput etc. The Examiner also notes that this appears to be arguing the intended use a recitation of the intended use of the claimed invention must result in a structural (or methodical) difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure (or method) is capable of performing the intended use, then it meets the claim. And lastly, considering how Sobalvarro does determine the sequence, it need not matter whether there is any physical connection since it is entirely a software layout of the modular aspects for a plant. Sobalvarro is able to provide different layouts for simulation for factories in attempt to optimize factory performance, which is precisely what the instant invention seeks to patent. Here, as noted in previous rejections, the Sobalvarro is able to arrange factory objects such as machines or processes connected with a conveyor “Sub- Pick part from conveyor or Machining processes available tractive mobile transport machine (e.g. CNC, lathe, mill, drill metal or Machine or process part press, metal bending) plastic No allowed movement Machine brand and fabri- Speed and separation functionality cation monitoring or guarding Maintenance schedules and station consumables tables Physical dimensions of machines and possible part operations Additive Pick part from conveyor or Additive processes available metal or mobile transport machine (e.g. 3D printing, sintering) plastic Machine or process part Machine brand and fabri- through additive processes functionality cation No allowed movement Maintenance schedules and station Speed and separation consumables tables monitoring or guarding Physical dimensions of machines and possible part operations Welding Pick parts from conveyor or Weld types possible station mobile transport machine Electrical and mechanical Weld parts characteristics Offload welded parts to Brand and type of welding conveyor or mobile transport equipment machine Welding recipes No allowed movement Speed and separation monitoring (human may approach) General Pick parts from conveyor, (Sobalvarro Col. 7 lines 5-51).” As such, this argument is not persuasive, and the rejection not withdrawn.
In response to arguments in reference to any depending claims that have not been individually addressed, all rejections made towards these dependent claims are maintained due to a lack of reply by the Applicants in regards to distinctly and specifically pointing out the supposed errors in the Examiner's prior office action (37 CFR 1.111). The Examiner asserts that the Applicants only argue that the dependent claims should be allowable because the independent claims are unobvious and patentable over the prior art.
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.
Claims 1-5, 7, and 10-16 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims are directed to a process (an act, or series of acts or steps), a machine (a concrete thing, consisting of parts, or of certain devices and combination of devices), and a manufacture (an article produced from raw or prepared materials by giving these materials new forms, qualities, properties, or combinations, whether by hand labor or by machinery). Thus, each of the claims falls within one of the four statutory categories (Step 1). However, the claim(s) recite(s) providing or storing semantic descriptions of modules which is an abstract idea of a mental process.
The limitations of “accessing, a database-implemented a module library storing machine-readable semantic modules representing respective real and virtual modules in a module pool, the modules being modular process equipment connectable together to form a process line, wherein a real module is an instance of a module of a particular type, implemented in software, firmware and/or hardware and wherein a virtual module is a template for a module of a particular type,, at least one said semantic module comprising a semantic description of the respective module, wherein the semantic description comprises abstract data according to a semantic data model, wherein the abstract data comprises attributes encoded by an n-dimensional condition vector with numerical components representing aspects of the plant according to a predefined scheme, and wherein the abstract data describes attributes of the respective module not found in a standard description file for the module; receiving, input data indicating at least one precondition and at least one postcondition of a required pipeline for a modular plant; automatically generating...suggested semantic module pipeline representing one or more modules capable of transforming the at least one precondition, wherein the module pipeline generation engine selects from the module library one or more semantic modules for inclusion in the suggested semantic module pipeline on the basis of the n-dimensional condition vectors of the module attributes provided in the machine-readable semantic description of the selected semantic modules, wherein the one or more semantic modules comprise at least one real module, and wherein use of the at least one real module in the suggested semantic module pipeline prevents simultaneous use of the at least one real module in a different suggested semantic module pipeline and wherein the module pipeline generation engine: determines, based on input/output attributes and functionality attributes of the semantic modules in the module library, a sequence in which to physically connect one or more semantic modules together to form the suggested semantic module pipeline wherein input attributes of a first semantic module in the suggested semantic module pipeline match the at least one precondition and output attributes of a last semantic module in the suggested semantic module pipeline match the at least one postcondition; wherein functionalities of the one or more semantic modules in the sequence combine to transform the at least one precondition into the at least one postcondition; outputting a machine-readable semantic pipeline representation based on the suggested semantic module pipeline, the machine-readable semantic pipeline representation usable to assemble or reconfigure the modular plant based on the suggested semantic module pipeline” as drafted, is a process that, under its broadest reasonable interpretation, covers a mental process—concepts performed in the human mind (including an observation, evaluation, judgment, opinion) but for the recitation of generic computer components (Step 2A Prong 1). That is, other than reciting “A computer-implemented method for module pipeline generation method for a modular plant, the method comprising... at least one or more processors” nothing in the claim element precludes the step from practically being performed in the mind. For example, but for the “A method for managing resources for a modular plant, the method comprising,…using a resource management system” language, “providing” in the context of this claim encompasses the user manually mentally creating different modules in pools based semantics. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim(s) recite(s) an abstract idea.
This judicial exception is not integrated into a practical application (Step 2A Prong Two). The “receiving, by a computer-implemented module pipeline generation engine in response to user input at an input interface...,” “a database-implemented a module library storing machine-readable semantic modules representing respective real and virtual modules in a module pool, the modules being modular process equipment connectable together to form a process line, wherein a real module is an instance of a module of a particular type, implemented in software, firmware and/or hardware “elements are simply performing insignificant extrasolution data gathering activities. Next, the claim only recites one additional element – using one or more processor to perform the steps. The resource management system, database and modules steps is recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of electronic data query, storage and retrieval) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Specifically the claims amount to nothing more than an instruction to apply the abstract idea using a generic computer or invoking computers as tools by adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.04(d)(I) discussing MPEP 2106.05(f). The claims recitation of the “module pipeline generation engine,” “database” “module(s)” only generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.04(d)(I) discussing MPEP 2106.05(h). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea, even when considered as a whole.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception (Step 2B). As discussed above with respect to integration of the abstract idea into a practical application (Step 2A Prong 2), the additional element of using a one or more processors with database and modules within the steps amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Similarly, only generally linking the use of the judicial exception to a particular technical environment or field of use does not amount to significantly more. Reevaluating here in step 2B, the “receiving, by a computer-implemented module pipeline generation engine in response to user input at an input interface...,” “a database-implemented a module library storing machine-readable semantic modules representing respective real and virtual modules in a module pool, the modules being modular process equipment connectable together to form a process line, wherein a real module is an instance of a module of a particular type, implemented in software, firmware and/or hardware” step(s) which are insignificant extrasolution activities are also determined to be well-understood, routine and conventional activity in the field. The Symantec, TLI, and OIP Techs court decisions in MPEP 2106.05(d)(II) indicate that the mere receipt or transmission of data over a network is well-understood, routine, and conventional function when it is claimed in a merely generic manner (as is here). Therefore, when considering the additional elements alone, and in combination, there is no inventive concept in the claim. As such, the claim(s) is/are not patent eligible, even when considered as a whole (Step 2B: NO). The claim(s) is/are not patent eligible, even when considered as a whole.
Claims 2-5, 7, 14, and 16 recite the additional limitations still directed towards the abstract idea previously identified and is not an inventive concept that meaningfully limits the abstract idea. Again, as discussed with respect to claim 1, the claims are simply limitations which are no more than mere instructions to apply the exception using a computer or with computing components. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Even when considered as a whole, the claims do not integrate the judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Claims 10-13 and 15 recite the additional limitations that include mathematical concepts which is not an inventive concept that meaningfully limits the abstract idea. Again, as discussed with respect to claim 1, the claims are simply limitations which are no more than mere instructions to apply the exception using a computer or with computing components. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Even when considered as a whole, the claims do not integrate the judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Claims 1-5, 7, and 10-16 are therefore not eligible subject matter, even when considered as a whole.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 7, and 10-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sobalvarro et al. (US Patent No. 11,256,241) further in view of Wouhaybi et al. (US PG Pub. 2020/0310394).
As per claim 1, Sobalvarro discloses a computer-implemented method for module pipeline generation method for a modular plant, the method comprising; (Stored in non-volatile memory are a template store 120, a store 125 for optimized factory layouts, and a store 130 for optimized factory schedules. Any or all of these stores may be organized as databases or simple file hierarchies, Sobalvarro Col. 6 lines 28-31; for a modular factory, Col. 2 lines 4-28):
at least one or more processors (processor, Sobalvarro Col. 3 line 50-Col. 4 line 4)
accessing, a database-implemented a module library storing machine-readable semantic modules representing respective real and virtual modules in a module pool, the modules being modular process equipment connectable together to form a process line, wherein a real module is an instance of a module of a particular type, implemented in software, firmware and/or hardware and wherein a virtual module is a template for a module of a particular type,, at least one said semantic module comprising a semantic description of the respective module, wherein the semantic description comprises abstract data according to a semantic data model, wherein the abstract data comprises attributes encoded by an n-dimensional condition vector with numerical components representing aspects of the plant according to a predefined scheme, and wherein the abstract data describes attributes of the respective module not found in a standard description file for the module (factory objects, machines, a representative set of factory objects appears in Table 1 below. Each of the objects includes a set of associated methods as well as attributes specifying characteristics of, and parameter values associated with, the object. The simulator 145 instantiates specified objects and uses their associated methods and attributes to simulate operation of the elements that the objects represent, including interaction among elements. Frequently, an associated method is generic and, when instantiated, reads the attributes to obtain values for the method variables, Sub- Pick part from conveyor or Machining processes available tractive mobile transport machine (e.g. CNC, lathe, mill, drill metal or Machine or process part press, metal bending) plastic No allowed movement Machine brand and fabri- Speed and separation functionality cation monitoring or guarding Maintenance schedules and station consumables tables Physical dimensions of machines and possible part operations Additive Pick part from conveyor or Additive processes available metal or mobile transport machine (e.g. 3D printing, sintering) plastic Machine or process part Machine brand and fabri- through additive processes functionality cation No allowed movement Maintenance schedules and station Speed and separation consumables tables monitoring or guarding Physical dimensions of machines and possible part operations Welding Pick parts from conveyor or Weld types possible station mobile transport machine Electrical and mechanical Weld parts characteristics Offload welded parts to Brand and type of welding conveyor or mobile transport equipment machine Welding recipes No allowed movement Speed and separation monitoring (human may approach) General Pick parts from conveyor, Sobalvarro Col. 7 lines 5-51; In step 210, the layout subsystem selects a factory layout template or an initial set of factory objects from the template store 120. In the latter case, the layout subsystem 150 may define the set of all possible layouts based on the selected factory objects. One of these may be chosen (step 220) as the current layout, either at random or based on initial application of the provided constraints; this may involve selection of attribute values of the factory objects within their allowed ranges. The performance of the current layout is simulated, and the results of the simulation are evaluated (step 230) based on the objective function. Another layout is chosen, or the current layout is modified, based on an optimization algorithm, Col. 9 lines 4-16; see Col. 7 lines 4-42 discussing the different elements, processes, objects, workcells etc. represented in an electronic software format for simulation; instructions for simulating, Col. 3 line 51-Col. 4 line 7) (Examiner notes the templates as the virtual modules. Examiner also notes the attributes and parameters for the factory objects as the semantic description. Examiner further notes that machines/processes and workcells are capable of being physically connectible to form a production line layout via conveyor discussed in Col. 7 lines 5-51), and
receiving, by a computer-implemented module pipeline generation engine in response to user input at an input interface, input data indicating at least one precondition and at least one postcondition of a required pipeline for a modular plant (The new layout generated with each iteration of the chosen optimization algorithm, which may reflect a new configuration of objects and/or modification of attribute values within the allowed ranges, must satisfy the work order. The performance of this layout is calculated and compared to the current layout. Iteration continues in accordance with the algorithm until the system reaches a termination criterion (step 240) indicating that the objective function has been sufficiently optimized. Operation of the layout subsystem 150 may be understood with reference to the following example, in which a bicycle is assembled pursuant to a series of defined tasks. The first step is to identify and list all of the tasks called for or implied by a work order and arrange them into groups as they may be performed in practice. This preparatory step is generally performed manually. A factory object is then defined for each of the tasks. Task object attributes include the task description, time to complete the task, physical and labor inputs required to complete the task, material and labor cost inputs, previous tasks that must or may be performed first (“precedent tasks”), subsequent tasks (“dependent tasks”), and whether the task is optional or specific to a particular finished product. Task object attributes may also include tasks that can be considered “adjacent” to each other, so that they may be performed in groups, with tasks mapping to workcells whose object attributes include specific forms of assembly amenable to the particular group. Which tasks can be considered adjacent is a decision typically made by the human operator. Other task object attributes may be particular to a model-specific specific assembly process, and may include options—for example, “Gearing” for tasks involving assembly of bicycles with gears, as opposed to fixed gear; “Braking” for tasks involving assembly of bicycles with brakes; and “Luxury” for tasks involving high-end bicycles with, for example, a basket, headlights, or taillights, Sobalvarro Col. 9 line 37-Col. 10 line 25),
automatically generating, using the module pipeline generation engine, suggested semantic module pipeline representing one or more modules capable of transforming the at least one precondition, wherein the module pipeline generation engine selects from the module library one or more semantic modules for inclusion in the suggested semantic module pipeline on the basis of the n-dimensional condition vectors of the module attributes provided in the machine-readable semantic description of the selected semantic modules, wherein the one or more semantic modules comprise at least one real module, and wherein use of the at least one real module in the suggested semantic module pipeline prevents simultaneous use of the at least one real module in a different suggested semantic module pipeline and wherein the module pipeline generation engine (The new layout generated with each iteration of the chosen optimization algorithm, which may reflect a new configuration of objects and/or modification of attribute values within the allowed ranges, must satisfy the work order. The performance of this layout is calculated and compared to the current layout. Iteration continues in accordance with the algorithm until the system reaches a termination criterion (step 240) indicating that the objective function has been sufficiently optimized. Operation of the layout subsystem 150 may be understood with reference to the following example, in which a bicycle is assembled pursuant to a series of defined tasks. The first step is to identify and list all of the tasks called for or implied by a work order and arrange them into groups as they may be performed in practice. This preparatory step is generally performed manually. A factory object is then defined for each of the tasks. Task object attributes include the task description, time to complete the task, physical and labor inputs required to complete the task, material and labor cost inputs, previous tasks that must or may be performed first (“precedent tasks”), subsequent tasks (“dependent tasks”), and whether the task is optional or specific to a particular finished product. Task object attributes may also include tasks that can be considered “adjacent” to each other, so that they may be performed in groups, with tasks mapping to workcells whose object attributes include specific forms of assembly amenable to the particular group. Which tasks can be considered adjacent is a decision typically made by the human operator. Other task object attributes may be particular to a model-specific specific assembly process, and may include options—for example, “Gearing” for tasks involving assembly of bicycles with gears, as opposed to fixed gear; “Braking” for tasks involving assembly of bicycles with brakes; and “Luxury” for tasks involving high-end bicycles with, for example, a basket, headlights, or taillights, Sobalvarro Col. 9 line 37-Col. 10 line 25; see also Col. 3 lines 16-39 discussing the simulation and instructions for the layout; Col. 3 line 65-Col. 4 line 2 specifying inputs and outputs; Prevent overlapping tasks in a workcell. 2 Assign a task to a single workcell, Sobalvarro Col. 14 lines 44-45; and optimal sequence according to an objective function, Col. 12 line 65-Col. 13 line 16) (Examiner notes the sequence or flow for tasks as the pipeline for which there are precedent and subsequent tasks being the equivalent to the precondition/postconditions for the layout which is a modular plant):
determines, based on input/output attributes and functionality attributes of the semantic modules in the module library, a sequence in which to physically connect one or more semantic modules together to form the suggested semantic module pipeline wherein input attributes of a first semantic module in the suggested semantic module pipeline match the at least one precondition and output attributes of a last semantic module in the suggested semantic module pipeline match the at least one postcondition (The new layout generated with each iteration of the chosen optimization algorithm, which may reflect a new configuration of objects and/or modification of attribute values within the allowed ranges, must satisfy the work order. The performance of this layout is calculated and compared to the current layout. Iteration continues in accordance with the algorithm until the system reaches a termination criterion (step 240) indicating that the objective function has been sufficiently optimized. Operation of the layout subsystem 150 may be understood with reference to the following example, in which a bicycle is assembled pursuant to a series of defined tasks. The first step is to identify and list all of the tasks called for or implied by a work order and arrange them into groups as they may be performed in practice. This preparatory step is generally performed manually. A factory object is then defined for each of the tasks. Task object attributes include the task description, time to complete the task, physical and labor inputs required to complete the task, material and labor cost inputs, previous tasks that must or may be performed first (“precedent tasks”), subsequent tasks (“dependent tasks”), and whether the task is optional or specific to a particular finished product. Task object attributes may also include tasks that can be considered “adjacent” to each other, so that they may be performed in groups, with tasks mapping to workcells whose object attributes include specific forms of assembly amenable to the particular group. Which tasks can be considered adjacent is a decision typically made by the human operator. Other task object attributes may be particular to a model-specific specific assembly process, and may include options—for example, “Gearing” for tasks involving assembly of bicycles with gears, as opposed to fixed gear; “Braking” for tasks involving assembly of bicycles with brakes; and “Luxury” for tasks involving high-end bicycles with, for example, a basket, headlights, or taillights, Sobalvarro Col. 9 line 37-Col. 10 line 25; see also Col. 3 lines 16-39 discussing the simulation and instructions for the layout; Col. 3 line 65-Col. 4 line 2 specifying inputs and outputs; Prevent overlapping tasks in a workcell. 2 Assign a task to a single workcell, Sobalvarro Col. 14 lines 44-45; and optimal sequence according to an objective function, Col. 12 line 65-Col. 13 line 16); and
wherein functionalities of the one or more semantic modules in the sequence combine to transform the at least one precondition into the at least one postcondition (In step 210, the layout subsystem selects a factory layout template or an initial set of factory objects from the template store 120. In the latter case, the layout subsystem 150 may define the set of all possible layouts based on the selected factory objects. One of these may be chosen (step 220) as the current layout, either at random or based on initial application of the provided constraints; this may involve selection of attribute values of the factory objects within their allowed ranges. The performance of the current layout is simulated, and the results of the simulation are evaluated (step 230) based on the objective function. Another layout is chosen, or the current layout is modified, based on an optimization algorithm, (Sobalvarro Col. 9 lines 4-16; The new layout generated with each iteration of the chosen optimization algorithm, which may reflect a new configuration of objects and/or modification of attribute values within the allowed ranges, must satisfy the work order. The performance of this layout is calculated and compared to the current layout. Iteration continues in accordance with the algorithm until the system reaches a termination criterion (step 240) indicating that the objective function has been sufficiently optimized. Operation of the layout subsystem 150 may be understood with reference to the following example, in which a bicycle is assembled pursuant to a series of defined tasks. The first step is to identify and list all of the tasks called for or implied by a work order and arrange them into groups as they may be performed in practice. This preparatory step is generally performed manually. A factory object is then defined for each of the tasks. Task object attributes include the task description, time to complete the task, physical and labor inputs required to complete the task, material and labor cost inputs, previous tasks that must or may be performed first (“precedent tasks”), subsequent tasks (“dependent tasks”), and whether the task is optional or specific to a particular finished product. Task object attributes may also include tasks that can be considered “adjacent” to each other, so that they may be performed in groups, with tasks mapping to workcells whose object attributes include specific forms of assembly amenable to the particular group. Which tasks can be considered adjacent is a decision typically made by the human operator. Other task object attributes may be particular to a model-specific specific assembly process, and may include options—for example, “Gearing” for tasks involving assembly of bicycles with gears, as opposed to fixed gear; “Braking” for tasks involving assembly of bicycles with brakes; and “Luxury” for tasks involving high-end bicycles with, for example, a basket, headlights, or taillights, Col. 9 line 37-Col. 10 line 25) (Examiner notes the constraints for which the layout is to be optimized as the transformation of a precondition(s) into at least one postcondition);
outputting a machine-readable semantic pipeline representation based on the suggested semantic module pipeline, the machine-readable semantic pipeline representation usable to assemble or reconfigure the modular plant based on the suggested semantic module pipeline (Col. 3 lines 16-39 discussing the simulation and instructions for the layout; Col. 3 line 65-Col. 4 line 2 specifying inputs and outputs; see also Fig. 9-Fig. 10 showing optimal layouts that have been interpreted to the assembled module pipeline)
Sobalvarro does not expressly disclose wherein the abstract data comprises attributes encoded by an n-dimensional condition vector with numerical components representing aspects of the plant according to a predefined scheme; the abstract data describes attributes of the respective module not found in a standard description file for the module.
However, Wouhaybi teaches wherein the abstract data comprises attributes encoded by an n-dimensional condition vector with numerical components representing aspects of the plant according to a predefined scheme; the abstract data describes attributes of the respective module not found in a standard description file for the module (As indicated above, data models may be an essential component for use in IoT deployments such as SDIS implementations. Data models are abstractions of the data and the relationships of different structures and streams. Based on the implementation, a data model may be implemented with simple as on-the-fly tagging (such as used in Project Haystack, an open source initiative to develop naming conventions and taxonomies for building equipment and operational data) or with extensive definitions of the structures/classes and the flow of data (e.g., with such definitions commonly being established during the design phase and prior to the development of a system). The data model is important in many systems because provides a mechanism for developers, designers, architects, and deployment technicians to describe and find data sources, Wouhaybi ¶136; vector with a set of conditions and associated values, ¶154-¶163; encode/decodes commands, translates commands, ¶298).
Both the Sobalvarro and Wouhaybi references are analogous in that both are directed towards/concerned with organizing or optimizing factory or production facility layouts. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to use Wouhaybi’s method of dynamic modeling for industrial systems in Sobalvarro’s system to improve the system and method with reasonable expectation that this would result in a factory layout management system that is able to optimize layouts.
The motivation being that limited approaches have been investigated to utilize IoT devices and IoT frameworks even despite the technical advances that have occurred in industrial automation and systems. Further, industry has been hesitant to adopt new technologies in industrial systems and automation, because of the high cost and unproven reliability of new technology. This reluctance means that typically, only incremental changes are attempted; and even then, there are numerous examples of new technology that underperformed or took long periods of time to bring online. As a result, wide-scale deployment of IoT technology and software-defined technologies has not been successfully adapted to industrial settings (Wouhaybi ¶7).
As per claim 2, Sobalvarro and Wouhaybi disclose as shown above with respect to claim 1. Sobalvarro further discloses wherein the attributes of the module comprise one or more members of a group consisting of input/output attributes, module functionality, module parameters, process parameters, and calibration parameters (attributes specifying characteristics of, and parameter values associated with, the object. The simulator 145 instantiates specified objects and uses their associated methods and attributes to simulate operation of the elements that the objects represent, including interaction among elements. Frequently, an associated method is generic and, when instantiated, reads the attributes to obtain values for the method variables, Sobalvarro Col. 7 lines 5-51; Table 1 with requirements/attributes; constraints and requirements, Col. 8 line 65-Col. 9 line 36).
As per claim 3, Sobalvarro and Wouhaybi disclose as shown above with respect to claim 1. Sobalvarro further discloses wherein the semantic description further comprises collected usage data relating to prior use of the respective module in a modular plant (history, current and past iterates, Sobalvarro Col. 8 line 65-Col. 9 line 36).
As per claim 4, Sobalvarro and Wouhaybi disclose as shown above with respect to claim 3. Sobalvarro further discloses wherein the collected usage data relates to previously measured key performance indicators including one or more members of a group consisting of mean time between failure, module uptime, utilization rates of services and equipment, prior calibration parameters, frequent plant contexts, maintenance performed, materials/medium processed, application purpose and restrictions for chemical reactions, module availability schedule, and maintenance cycles/intervals (constraints and requirements, history, current and past iterates, that best satisfy the objective function for optimization, Sobalvarro Col. 8 line 65-Col. 9 line 36; Assembly sequence planning is one of the well-known combinatorial optimization problems in manufacturing. Once the assembly is represented by a precedence graph, the group objects and their attributes (including optionality), traditional methods of combinatorial optimization may be used to generate a large number of feasible assembly sequences and then find the optimal sequence according to the objective function. Once a precedence graph has been established, the groups are mapped to workcell objects corresponding to physical workcells with dimensions and locations on the factory floor. Suppose that the parts to be assembled are brought into the factory (as represented by a factory object, with attributes relating to workspace area, available utilities, physical dimensions, etc.) from the left and leave the factory, assembled, on the right as shown in FIG. 4. At the bottom of the factory is space for IMRs to queue. Each of the IMRs is represented by an IMR object with attributes specifying speed, payload, geometric format, battery life, etc. The initial mapping of groups to workcells (i.e., workcell objects) begins with the precedence graph as shown in FIG. 5. The next step is to optimize the number of workcells per group so as to optimize the objective function—e.g., maximize a profit function (for example, minimize cycle time) or minimize a cost function (for example, capital expenditures or occupied factory floor space). If, for example, group 5 (“Build Middle”) is a particularly lengthy step and is the cycle time bottleneck, a standard optimization algorithm may propose that the tradeoff between the layout of two group 5 workcells (including the cost of the workcell and labor, plus space utilization) would improve a profit function relative to only one group 5 workcell. This “de-bottlenecking” configuration is shown in FIG. 6, Col. 12 line 65-Col. 13 line 30).
As per claim 5, Sobalvarro and Wouhaybi disclose as shown above with respect to claim 1. Sobalvarro further discloses wherein the semantic description further comprises prior configuration data relating to a configuration of the respective module in at least one prior modular plant, the prior configuration data being usable for configuring the module for use in a further modular plant (constraints and requirements, history, current and past iterates, that best satisfy the objective function for optimization, Sobalvarro Col. 8 line 65-Col. 9 line 36).
As per claim 7, Sobalvarro and Wouhaybi disclose as shown above with respect to claim 1. Sobalvarro further discloses wherein the method further comprises selecting from the module library one or more semantic modules for inclusion in the semantic module pipeline on the basis of the module attributes contained in the semantic description of the selected semantic modules (The new layout generated with each iteration of the chosen optimization algorithm, which may reflect a new configuration of objects and/or modification of attribute values within the allowed ranges, must satisfy the work order. The performance of this layout is calculated and compared to the current layout. Iteration continues in accordance with the algorithm until the system reaches a termination criterion (step 240) indicating that the objective function has been sufficiently optimized. Operation of the layout subsystem 150 may be understood with reference to the following example, in which a bicycle is assembled pursuant to a series of defined tasks. The first step is to identify and list all of the tasks called for or implied by a work order and arrange them into groups as they may be performed in practice. This preparatory step is generally performed manually. A factory object is then defined for each of the tasks. Task object attributes include the task description, time to complete the task, physical and labor inputs required to complete the task, material and labor cost inputs, previous tasks that must or may be performed first (“precedent tasks”), subsequent tasks (“dependent tasks”), and whether the task is optional or specific to a particular finished product. Task object attributes may also include tasks that can be considered “adjacent” to each other, so that they may be performed in groups, with tasks mapping to workcells whose object attributes include specific forms of assembly amenable to the particular group. Which tasks can be considered adjacent is a decision typically made by the human operator. Other task object attributes may be particular to a model-specific specific assembly process, and may include options—for example, “Gearing” for tasks involving assembly of bicycles with gears, as opposed to fixed gear; “Braking” for tasks involving assembly of bicycles with brakes; and “Luxury” for tasks involving high-end bicycles with, for example, a basket, headlights, or taillights, Sobalvarro Col. 9 line 37-Col. 10 line 25).
As per claim 9, Sobalvarro and Wouhaybi disclose as shown above with respect to claim 1. Sobalvarro further discloses wherein the method further comprises determining, on the basis of functionality attributes of the semantic modules in the module library, a sequence of one or more modules to form the module pipeline whose functionalities combine to transform the at least one precondition into the at least one postcondition (The new layout generated with each iteration of the chosen optimization algorithm, which may reflect a new configuration of objects and/or modification of attribute values within the allowed ranges, must satisfy the work order. The performance of this layout is calculated and compared to the current layout. Iteration continues in accordance with the algorithm until the system reaches a termination criterion (step 240) indicating that the objective function has been sufficiently optimized. Operation of the layout subsystem 150 may be understood with reference to the following example, in which a bicycle is assembled pursuant to a series of defined tasks. The first step is to identify and list all of the tasks called for or implied by a work order and arrange them into groups as they may be performed in practice. This preparatory step is generally performed manually. A factory object is then defined for each of the tasks. Task object attributes include the task description, time to complete the task, physical and labor inputs required to complete the task, material and labor cost inputs, previous tasks that must or may be performed first (“precedent tasks”), subsequent tasks (“dependent tasks”), and whether the task is optional or specific to a particular finished product. Task object attributes may also include tasks that can be considered “adjacent” to each other, so that they may be performed in groups, with tasks mapping to workcells whose object attributes include specific forms of assembly amenable to the particular group. Which tasks can be considered adjacent is a decision typically made by the human operator. Other task object attributes may be particular to a model-specific specific assembly process, and may include options—for example, “Gearing” for tasks involving assembly of bicycles with gears, as opposed to fixed gear; “Braking” for tasks involving assembly of bicycles with brakes; and “Luxury” for tasks involving high-end bicycles with, for example, a basket, headlights, or taillights, Sobalvarro Col. 9 line 37-Col. 10 line 25).
As per claim 10, Sobalvarro and Wouhaybi disclose as shown above with respect to claim 1. Sobalvarro further discloses comprising an optimization component configured to: receiving data identifying a required module type to be assembled into a modular plant as part of a module pipeline comprising one or more modules; and executing, an optimization algorithm to select, from a plurality of semantic modules in the module library having the required module type, a semantic module representing a module for inclusion in the module pipeline on the basis of one or more predetermined optimization criteria (The new layout generated with each iteration of the chosen optimization algorithm, which may reflect a new configuration of objects and/or modification of attribute values within the allowed ranges, must satisfy the work order. The performance of this layout is calculated and compared to the current layout. Iteration continues in accordance with the algorithm until the system reaches a termination criterion (step 240) indicating that the objective function has been sufficiently optimized. Operation of the layout subsystem 150 may be understood with reference to the following example, in which a bicycle is assembled pursuant to a series of defined tasks. The first step is to identify and list all of the tasks called for or implied by a work order and arrange them into groups as they may be performed in practice. This preparatory step is generally performed manually. A factory object is then defined for each of the tasks. Task object attributes include the task description, time to complete the task, physical and labor inputs required to complete the task, material and labor cost inputs, previous tasks that must or may be performed first (“precedent tasks”), subsequent tasks (“dependent tasks”), and whether the task is optional or specific to a particular finished product. Task object attributes may also include tasks that can be considered “adjacent” to each other, so that they may be performed in groups, with tasks mapping to workcells whose object attributes include specific forms of assembly amenable to the particular group. Which tasks can be considered adjacent is a decision typically made by the human operator. Other task object attributes may be particular to a model-specific specific assembly process, and may include options—for example, “Gearing” for tasks involving assembly of bicycles with gears, as opposed to fixed gear; “Braking” for tasks involving assembly of bicycles with brakes; and “Luxury” for tasks involving high-end bicycles with, for example, a basket, headlights, or taillights, Sobalvarro Col. 9 line 37-Col. 10 line 25).
As per claim 11, Sobalvarro and Wouhaybi disclose as shown above with respect to claim 10. Sobalvarro further discloses wherein the optimization algorithm is configured to perform a local optimization for optimizing only the module pipeline (local optimization, Sobalvarro Col. 14 lines 25-41; decoupled level using local information, Col. 16 line 64-Col. 17 line 14).
As per claim 12, Sobalvarro and Wouhaybi disclose as shown above with respect to claim 10. Sobalvarro further discloses wherein the optimization algorithm is configured to perform a global optimization to select a plurality of semantic modules representing modules of the required module type to be assembled into respective module pipelines in the modular plant (centralized, Sobalvarro Col. 16 line 64-Col. 17 line 14; optimal layout of all cells to optimize the factory, Col ).
As per claim 13, Sobalvarro and Wouhaybi disclose as shown above with respect to claim 10. Sobalvarro further discloses wherein the predetermined optimization criteria comprise one or more member of a group consisting of product quality, throughput, capacity, resource/material efficiency, energy efficiency, energy consumption, time-to-service, uptime, equipment availability, mean time between failure, utilization rates of services and equipment, minimization of module usage (constraints and requirements, history, current and past iterates, that best satisfy the objective function for optimization, Sobalvarro Col. 8 line 65-Col. 9 line 36; Assembly sequence planning is one of the well-known combinatorial optimization problems in manufacturing. Once the assembly is represented by a precedence graph, the group objects and their attributes (including optionality), traditional methods of combinatorial optimization may be used to generate a large number of feasible assembly sequences and then find the optimal sequence according to the objective function. Once a precedence graph has been established, the groups are mapped to workcell objects corresponding to physical workcells with dimensions and locations on the factory floor. Suppose that the parts to be assembled are brought into the factory (as represented by a factory object, with attributes relating to workspace area, available utilities, physical dimensions, etc.) from the left and leave the factory, assembled, on the right as shown in FIG. 4. At the bottom of the factory is space for IMRs to queue. Each of the IMRs is represented by an IMR object with attributes specifying speed, payload, geometric format, battery life, etc. The initial mapping of groups to workcells (i.e., workcell objects) begins with the precedence graph as shown in FIG. 5. The next step is to optimize the number of workcells per group so as to optimize the objective function—e.g., maximize a profit function (for example, minimize cycle time) or minimize a cost function (for example, capital expenditures or occupied factory floor space). If, for example, group 5 (“Build Middle”) is a particularly lengthy step and is the cycle time bottleneck, a standard optimization algorithm may propose that the tradeoff between the layout of two group 5 workcells (including the cost of the workcell and labor, plus space utilization) would improve a profit function relative to only one group 5 workcell. This “de-bottlenecking” configuration is shown in FIG. 6, Col. 12 line 65-Col. 13 line 30).
As per claim 14, Sobalvarro and Wouhaybi disclose as shown above with respect to claim 1. Sobalvarro further discloses wherein the database is configured to provide search functionality to allow searching of the module library (queries, Wouhaybi ¶162).
As per claim 15, Sobalvarro and Wouhaybi disclose as shown above with respect to claim 1. Sobalvarro further discloses simulating of the operation of a module pipeline comprising one or more modules in a modular plant (simulation module, Sobalvarro Col. 6 line 32-Col. 7 line 3).
As per claim 15, Sobalvarro and Wouhaybi disclose as shown above with respect to claim 1. Sobalvarro further discloses wherein the one or more modules comprise at least one virtual module (simulation module executable by the processor, Sobalvarro Col. 3 line 64-Col. 4 line 7).
Conclusion
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to ANDREW B WHITAKER whose telephone number is (571)270-7563. The examiner can normally be reached on M-F, 8am-5pm, EST.
If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Lynda Jasmin can be reached on (571) 272-6782. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-
automated- interview-request-air-form
/ANDREW B WHITAKER/Primary Examiner, Art Unit 3629
Prosecution Insights